modxcms
Update modX.[add|remove]ExtensionPackage to use new modExtensionPackage model
To preserve BC while introducing new features, I think the addExtensionPackage and removeExtensionPackage methods should be updated to prefer storing the data in a modExtensionPackage object instead of in the extension_packages setting.
The removeExtensionPackage method should check both the system setting and the database for matching extension packages. The addExtensionPackage should just write to the table.
If there's any potential issues that can come from having a package in both the setting and database, maybe the addExtensionPackage should also remove from the system setting to prevent duplicates, but I can't think of any issues off-hand.
This still seems like a good idea to me. The ClassExtender extra calls addExtensionPackage() and the result is still written to the system setting, and the modExtensionPackage table remains empty.
I also find that packages in the modx_extension_packages table don't seem to be loaded when $modx->initialize() calls _loadExtensionPackages(). They're retrieved with this call:
$cache = $this->call(modExtensionPackage::class, 'loadCache', [&$this]);
But $cache is empty after the call. In stepping through in the debugger, it looks like xPDO's call to $modx->getCacheManager() is failing in a way that prevents the $return variable from being set at all.
This issue has been mentioned on MODX Community. There might be relevant details there:
https://community.modx.com/t/trouble-with-extensionpackage-object-in-modx-3/5728/2
