MODX3 - Deprecations Log - Can they be fixed?

1

Hello, is it possible to fix the following errors?
i use MODX 3.1.0-pl on NGINX - 1.27.3 and 8.4.2

Screenshot_451
Screenshot_4511342×3203 365 KB

The site actually works, but perfectionism requires that there be no errors in the logs.
Thank you!

2

It’s quite unrealistic to get rid of all the deprecation messages (at this current time).

Most of these deprecation messages are (usually) generated by installed extras.
If an extra uses the same code/version for MODX 2.x and MODX 3, it’s generally easier to just use the deprecated class (that works for both versions) than always checking the MODX version first.

You could create pull requests (or issues) on Github for every occurence of a deprecated class name in a MODX extra, but that would be very tedious (and quite pointless).

What you could do, is to convert your own custom code (custom snippets, custom plugins, …) to MODX 3 syntax to make it future-proof (and avoid some of the deprecation log messages).

For example if you have a line like this:

$resoure = $modx->getObject('modResource', $id);

Change it to

$resoure = $modx->getObject('MODX\\Revolution\\modResource', $id);

or

use MODX\Revolution\modResource;

...
$resoure = $modx->getObject(modResource::class, $id);
3

You may not want to do this, but turning off the log_deprecated System Setting should give you a nice clean Deprecations Log.

1 Like
4

It’s a fair amount of work, but I’ve managed to get rid of the deprecation notices in all of my extras.

Basically, you do something like this:

$isMODX3 = $modx->getVersionData()['version'] >= 3;
$prefix = $isMODX3
    ? 'MODX\Revolution\\'
    : '';

$doc = $modx->getObject($prefix . 'modResource', 
     array('pagetitle' => 'myPage'));

Once you have the $prefix, you have to correct all calls to getObject(), getCollection(), getIterator(), newObject(), getCount(), newQuery, and new. There are separate prefixes for transport packages, media sources, and mail.

You also need to get rid of any calls to instanceof.

That’s not as difficult as it sounds if you have a good code editor that lets you search multiple files.

It gets significantly more complicated, though, if you have processors or classes that are subclasses of MODX objects.

In those cases, you need to create a phantom parent class something like this:

$v = include MODX_CORE_PATH . 'docs/version.inc.php';
$isMODX3 = $v['version'] >= 3;
$prefix = $isMODX3? 'MODX\Revolution\\' : '';

if ($isMODX3) {
    abstract class ExampleDynamicParentchunkgetlist extends MODX\Revolution\Processors\Element\Chunk\GetList {
    }
} else {

        $includeFile = MODX_CORE_PATH . 'model/modx/processors/element/chunk/getlist.class.php';
    if (!class_exists($prefix . 'modChunkGetListProcessor')) {
        require $includeFile;
    }

    abstract class ExampleDynamicParentchunkgetlist extends modChunkGetlistProcessor {
    }
}
class ExampleChunkGetlistProcessor extends ExampleDynamicParentchunkgetlist {
    public $classKey = 'modChunk';
    /* Your class code here */
}

Your call whether it’s worth the effort.