Idea for converting extras to MODX 3

Development
1

I’ve been thinking hard about how to update my 40+ extras for MODX 3. The last thing I want is to create separate MODX3 versions and have 80+ extras to maintain.

It occurred to me that adding a simple method to the modX class would really help. It would return the new namespaced class specification in MODX 3. Something like this:

public function getClassPath($name) {
    $isModx3Plus = $this->getVersionData()['version'] >= 3;
    return $isModx3Plus? '\MODX\Revolution\\' . $name: $name;
}

So getClassPath('modResource') would return modResource in MODX 2, and MODX\Revolution\modResourcer in MODX 3. It might need a switch statement to handle edge cases for class files in other locations.

That would allow code like this, that would run in either MODX 2 or 3:

$doc = $modx->newObject($modx->getClassPath('modResource'));
$doc = $modx->getObject($modx->getClassPath('modResource'), $id);

// and

$cpath = $modx->getClassPath('modResource');
if ($doc instanceof $c) {
  /* Do something */
}

Obviously, the function could be included in all extras, but that would mean writing code to include it in hundreds of files (about 60 in MyComponent alone). It could be put in a class and autoloaded, but then every extra would have to register its own autoloader.

If it were in the modX class, I could update my extras with a fairly simple script that used preg_replace() to update the code so it would run equally well in MODX 2 and 3, without throwing a ton of deprecation notices in MODX 3.

This method, or a separate one, could update processor paths as well.

It would also be nice the same thing were done with the modX class in MODX 2.

Thoughts?

2

There’s a BC layer that allows $modx->getObject(‘modResource’) to work just fine - so I don’t see why you’d need something like this to achieve cross compatibility? The only one of my extras that has been challenging to make cross compatible is MoreGallery with a custom resource. Everything else so far has only needed fairly minimal tweaks.

Deprecations have also moved to a separate log to not clutter up the error log anymore.

1 Like
3

I’m aware of the BC layer, but the whole point of deprecation warnings is so people can fix things.

I’d rather do a permanent fix now than face the issue again when the deprecated code no longer works.