MODX3 nightly — installed now manager displays error

I just installed the latest nightly of MODX 3 (upgraded from previouse test version) on my test site, and now going to the login screen generates this error:

Fatal error : Uncaught Error: Class ‘modManagerRequest’ not found in /core/src/Revolution/modX.php:1490 Stack trace: #0 /manager/index.php(58): MODX\Revolution\modX->getRequest() #1 {main} thrown in /core/src/Revolution/modX.php on line 1490

Any ideas? I’ve cleared all caches, deleted all files in the Cache folder, etc.

OK, just deleted my whole test installation, copied in my current website (2.7.2), then uploaded the new MODX3 alpha and installed that. I can log in now, and the site displays fine, but NOTHING shows up in the resources tree! Yes, I’ve cleared all caches completely.

Anything in the MODX error log? Or the console in your browsers’ developer tools?

No errors in the MODX log, no error_log files on the server. Browser console shows this error:

VM398:1 Uncaught SyntaxError: Unexpected token ‘<’
at doDecode (ext-all.js:21)
at Object.decode (ext-all.js:21)
at MODx.tree.TreeLoader.processResponse (modx.tree.treeloader.js:24)
at MODx.tree.TreeLoader.handleResponse (ext-all.js:21)
at (ext-all.js:21)
at f (ext-base.js:21)
at m (ext-base.js:21)
at ext-base.js:21

That error suggests there’s markup where there should be JSON. In the response of an AJAX request.

Open browser dev tools and watch the network tab when doing a refresh. Then look through each of the AJAX requests, and see which one of them responds with HTML (likely a PHP error formatted as HTML). Then report back with both the request (in particular the action, which you can see in either the URL or on the Request tab in the parameters section) and the response.

Then we should have what we need to identify the problem :slight_smile:

Here’s the request:\Revolution\modContext

And the response:

Fatal error : Cannot declare class modDriverSpecificProcessor, because the name is already in use in /home/rainbowt/modx3/core/model/modx/modprocessor.class.php on line 378

Found out the problem. There is a Collections resource in the tree, and while the class_key for standard MODX resources got updated to “MODX\Revolution\modDocument”, the Collections resource was still “CollectionContainer”. I updated that to “MODX\Revolution\CollectionContainer” and the tree works now.

Oooh. Well, it doesn’t QUITE work. The tree shows up now, but Collection Containers are not listed!

Collections will most definitely need an update to work on MODX 3 due to the resource changes. I know @theboxer already spent some time on that, but I’m not sure if that was released.

Do you still see a lot of files in core/model/modx/? If so, there’s already a PR that makes sure they are removed when upgrading. I’m guessing the modDriverSpecificProcessor error pops up because Collections is requiring old processor files, which includes that specific class, and that must be happening more than once for some reason.

Yes, there were tons of files there. I’ve deleted those.

I guess Collections just isn’t going to work for a while.

John (theboxer) already has a working version of Collections for MODX 3; doesn’t look like it’s published anywhere yet that I can find, but I do know he worked on it and had it functional.