PHP 7.4 Modx 3.0.1 resources > web doesn't show

1

I’m finding some issues with my upgrade to 3.0.1.

On my local php 8.1 system, 3.0.1 (advanced cli installed) the resources > web shows the pages fine, but on the live site, php 7.4, it never loads, and shows this error in debugger of Chrome:

VM1591:1 Uncaught SyntaxError: Unexpected token '<'
    at doDecode (ext-all.js:21:49686)
    at Object.decode (ext-all.js:21:51149)
    at MODx.tree.TreeLoader.processResponse (modx.tree.treeloader.js?mv=301pl:24:24)
    at MODx.tree.TreeLoader.handleResponse (ext-all.js:21:474445)
    at Ext.data.Connection.handleResponse (ext-all.js:21:47767)
    at f (ext-base.js:21:17840)
    at m (ext-base.js:21:18302)
    at ext-base.js:21:8604

That’s in manager/assets/ext3/ext-all.js

Since the javascript is condensed and impossible to read, I can’t even locate where the error is occuring, but I’ve tried uploading the same file from my working local dev system and it doesn’t change anything, so it’s not something wrong in the file.

I assume there’s some subtle difference, or maybe some file is shooting bad data to the ext-all-js file, I don’t know.

It would have been nice, to put it mildly, if the upgrade instruction page for 3.0 had made it crystal clear that some key extensions won’t work, like Quip, I read through everything before doing the upgrade and was fairly unhappy to discover that quip is broken again on 3.0 due to the changes in the function/class naming etc.

I thought by waiting a few months to upgrade these types of weak spots would have been ironed out, but unfortunately that was not the case.

Using this page, which I discovered too late on another modx forum post about web resources failing to load, I got this information about our extensions:

https://sitedash.app/extras

Breadcrumbs: ?
CacheMaster: ?
getPage: yes
getResources: yes
Quip: no
RecaptchaV2: ?
Wayfinder: yes

As you can see, that page was pretty much completely useless since it didn’t even list Recaptcha2 as tested and working (it works, just fyi, so you can update that). Breadcrumbs and cachemaster I think also are working fine.

However, given the web resources tree loads fine on php 8.1 system, I assume there is some other code interfering somewhere.

Given the unclear status of extensions, even core ones like quip, I clearly made a mistake not waiting about 1 year to update to 3.0.x, and to make sure all extensions that needed upgrades had a new version before doing the upgrade. When I tried as a test to downgrade to 2.8.4 that didn’t work at all, and our site pages failed to load, so I had to go back to the not yet ready for gold release 3.0.1 version, which is really not good as a strategy in my opinion.

Should have been an extension tester or something that warned it was not compatible, but hopefully this is the only breaking update we’ll have to deal with before we all quit this project and move on with life, 10 years or so, that is, so I’ll consider my lesson learned and never do another major version upgrade.

There is one difference I just remembered, the dev site doesn’t block core/ since it doesn’t matter locally, but the live site has it blocked in .htaccess per the instructions.

2

I remember having trouble with Articles (which uses Quip) with .htaccess blocking the core directory.

Seeing the Unexpected token '<' message often means a PHP error (possibly due to PHP 8) in a call to a processor. You can get a look at it by turning on Dev. Tools in Chrome (Ctrl-shift-i) and watching the Network tab as you load the page. You can click on the call to the connector and “drill down” to see the response. The PHP error will be there (in the midst of a crapload of HTML formatting). Sometimes it helps to paste the code into an .html file and view it in a browser.

More details on the process here.

3

I have to suppress my absolute horror at the mess manager code is, and focus on the issue, but it’s very difficult to ignore that mess.

What is happening is very hard to track down, it’s not a PHP error, but that was a good hint.

First: dev local site, php 8.1, works. live site, php 7.4, does not work, but does use some redirects. Even the fact that you believe php 8.1, which is CURRENT STABLE php, could be a cause, is truly terrifying to me, and is a massive red flag. But it’s not, so we can ignore that.

On the working local dev site, clicking the resources item loads the web tree, which then displays, there are no errors.

On the dev site I believe this is the link in question:
http://dev-site/connectors/index.php?action=Resource/GetNodes&id=web_0&type=MODX\Revolution\modContext

which returns the expected json tree html blob.

On the live site, clicking on the resources tab fails to preload the tree blob, and when I click on the ‘web’ thing, it goes into the endless ‘loading’ and the live site reports that the page has been 301 redirected. I am unable to find any redirect rule that should impact this url so far, but I’ll update when / if I do, assuming it’s not some horrible internal thing modx itself is doing.

In other words, on the live site, something is redirecting that request, for unknown reasons, and due to the horrific mess that is the manager js / php codebase, tracking down such failures is far more difficult than it should be.

The inital ‘resources’ click works:
https://www.live-site.com/connectors/index.php?action=Resource/GetNodes&id=root
but fails to actually get the web node, and when the web item is clicked, it returns the redirect, which is very hard to track down.

The above js error is coming, as you suspected, because it’s receiving html, not json, but the cause is not a php error, it’s an errant redirect somewhere. I’m trying to track it down.

4

I should also mention the live site is going through cloudflare, but we’ve never had any issues related to unwanted redirects with cloudflare.

5

I’m carefully comparing live to dev, looking for where the actual failure happens.

The failure is coming in earlier, the above javascript failure message is caused by the earlier failure I believe, and the 301 redirect may be a symptom of the earlier failure as well.

A vanilla manager home page load results in the page building, and the tree automatically generating via an ajax query then being delivered back.

This process is failing already on the first page load on the live site, and the manager home page builds, it gets the data for the left bar headers, same on live/dev site, then the web html is supposed to load, but fails. The direct cause of this is the absurd js ajax junk getting confused by something or other, and of course, being ajax, being also almost impossible to debug or trace further issues in.

Even trying to track this down with a known good vs failing example is absurdly difficult.

The sequence is:
connectors/index.php
{"success":true,"message":"{\"modx-leftbar-tabpanel\":{\"activeTab\":0},\"modx-resource-tree\":[\"\\\/root\"],\"modx-tree-element\":[\"\\\/root\",\"\\\/root\\\/n_type_chunk\",\"\\\/root\\\/n_type_plugin\",\"\\\/root\\\/n_type_chunk\\\/n_chunk_category_21\"],\"source-tree-1\":\"\\\/Filesystem\",\"undefined-sort-default\":\"pagetitle\",\"undefined-sort\":\"pagetitle\"}","total":0,"data":[],"object":[]}

connectors/index.php?action=Resource/GetNodes&id=root
[{"text":"web","id":"web_0","pk":"web","ctx":"web","settings":{"default_template":"1","richtext_default":"0","hidemenu_default":"0","search_default":"1","cache_default":"1","publish_default":"","default_content_type":"1"},"leaf":false,"cls":"tree-pseudoroot-node pedit pnew pdelete pnewdoc pnew_modDocument pnewdoc pnew_modSymLink pnewdoc pnew_modWebLink pnewdoc pnew_modStaticResource pqcreate","iconCls":"tree-context","qtip":"The default front-end context for your web site.","type":"MODX\\Revolution\\modContext","pseudoroot":true}]

connectors/index.php
{"success":true,"message":"","total":0,"data":[],"object":["-",{"cls":"tree-new-resource","tooltip":"Create Document","handler":"new Function(\"MODx.createResource({\"context_key\":\"web\",\"parent\":0});\");"},{"cls":"tree-new-weblink","tooltip":"Create Weblink","handler":"new Function(\"MODx.createResource({\"class_key\":\"MODX\\\\Revolution\\\\modWebLink\",\"context_key\":\"web\",\"parent\":0});\");"},{"cls":"tree-new-symlink","tooltip":"Create Symlink","handler":"new Function(\"MODx.createResource({\"class_key\":\"MODX\\\\Revolution\\\\modSymLink\",\"context_key\":\"web\",\"parent\":0});\");"},{"cls":"tree-new-static-resource","tooltip":"Create Static Resource","handler":"new Function(\"MODx.createResource({\"class_key\":\"MODX\\\\Revolution\\\\modStaticResource\",\"context_key\":\"web\",\"parent\":0});\");"},"->",{"id":"emptifier","cls":"tree-trash","tooltip":"Go to the trash bin manager and manage up to 5 deleted resources","disabled":false,"handler":"new Function(\"this.redirect(\\\"?a=resource\/trash\\\");\");"}]}

This is the same on live and dev site. The ajax has built the visible menu for the resources/elements/files structure.

However, this is where it ends, on the dev site, the next ajax is:
connectorsindex.php?action=Resource/GetNodes&id=web_0&type=MODX\Revolution\modContext
with the content being the resources > web tree html in json megareturn.

On the live site this doesn’t happen, instead, the next ajax call is to index.php alone:
connectors/index.php
with the Dashboard content HTML.

Given the extreme difficulty of debugging this type of over the top extreme ajax, I have no idea what to do next.

We can’t leave modx cms because we’ve invested far too much in it, but this stuff is to me extremely concerning, this is the opposite of what I want to see in terms of high quality reliable and debuggable code.

The more visible failures are I believe the outcome of the initial failures

The js failure is because of the redirect to the site home page, but that is not the cause of the initial web resource tree load failure, that has already happened on the live site. The redirect failure I believe may come because the data does not exist, which is why it failed to load initially.

When the live site’s ‘web’ resource is clicked, which of course, having failed to load the tree in the first place, makes some request to something that doesn’t exist, I believe, which is why the tree load failed in the first place. But I can find no way to track down why it failed in the first place.

The direct actual cause of this is serial and massive abuse of ajax to generate stuff that doesn’t need ajax at all in the first place, leading to super difficult to debug and diagnose failure cases.

6

Giving up on the ajax, went back to PHP errors.

Initially thought it might be related to Articles, which Purge Old Packages in Installer fails to remove, it fails to remove any of the non used non installed packages by the way, and gives zero meaningful report of what it is doing.

I was getting a missing core/components/Articles/models error because I’d deleted that Articles folder to see if that was causing any issues, on the live site, but after uploading it to get rid of the php error, the situation remains.

However, it does make me wonder, why was Articles being looked for in the first place? It’s not installed, it’s been removed using the package manager. I’m glad we dumped articles after a brief test, but it appears it failed to remove itself completely.

This is just total guessing, which is what you are reduced to when dealing with such … anyway, I’m just guessing at this point, the issues are largely undebuggable, which is a very major bug itself.

I’m at a loss, Articles ‘may’ be involved, and it ‘may’ be related to some difference between php 8.1 and 7.4, but it’s all total guesses at this point.

A few things are clear: the Purge old packages features is NOT working, and needs fixing since it’s failing to do that. The articles package failed to uninstall itself correctly, and is leaving traces in the code, for reasons impossible to figure out. Since the purge old packages feature isn’t working, there’s no obvious way to check this.

If this wasn’t my job to take care of, I’d walk away from modx today, to be honest, because I’m seeing nothing but huge red flags wherever I look in the code.

7

Just to chip away:

  • Set core/ to be 404 non web accessible like the live site on dev site, web resource tree still loads fine, no issues.

  • Set other security type redirects to be same on dev/live, no change.

  • Checked something a similar issue re web resources vanishing/failing to load had suggested and which was reported to work when changed, Use compressed javascript compress_js: No; compress_js_groups: No. I already had these as no in the settings, so unrelated.

  • Set global site file compression to be off, tested, no difference.

  • This leaves the more grasping at straws stuff, like trying php 8.1 on the live server. Tried that, no change, 7.4 and 8.1 are the same, so it’s not PHP related.

  • clicking directly on the resources > web item then checking php error logs shows no new errors appearing after refresh. So nothing is failing per se. Reloading the Dashboard which then has the web resource tree failure shows no php errors either.

8

Articles and Quip are notoriously difficult to remove. I’ve had to go into the DB and search for “Quip” and “Article” to remove the pieces. Also, check the extension_packages System Setting to make sure any uninstalled packages have been removed from the setting.

BTW, did you upgrade Articles and Quip to the latest version after upgrading MODX to version 3?

Is your core directory in the web root (e.g., public_html)?

9

I always update installed packages to latest version before doing a modx update, I do that before the update. Articles is not installed, but has pieces all over. Quip is installed. Quip by the way is partially working, I removed their remote spam call, which was causing total fatal failure in the quip code so that users wouldn’t see those errors and have a crashed page, but the actual quip database is getting updated, but most of the rest is not working, the web interface component is not working, the emaler is not working, but the write to database on new posts and other stuff like that is working.

Yes, I had to move core to web document root, which I did early, 2.8.3 > 2.8.4, which really annoyed me because that is just bad engineering to require that, but I did it early to make sure that piece was all working and debugged.

I consider requiring core to be above doc root to be major regression, pretty much a bug in any real sense since requiring the total full site code to be above doc root is… very bad. It’s actually one of the main reasons I originally went with modx, way back when, they were on the only cms that did this right out of the box.

I could try installing Articles again, then removing it, in faint hope that it does something or other different, but with this badly done code, I have no trust in any tests like that, I already knocked the live client site offline yesterday for over an hour due to some other changes I did not know about, so I have very little trust in 3.0 at all currently, If I could roll back to 2.8.4 and never go to 3.0 until it’s actually ready for real use, and all its extensions work etc, I would, since I"m losing my entire weekend from this absurd situation.

10

Testing Articles install, it complains about quip, but will see.

11

I know you won’t like this suggestion, but double check your core/config/config.inc.php file, especially the connectors path and URL. Also, all paths and URLs should end with a slash.

I’d also suggest disabling all plugins, manually clearing the core/cache directory, and then visiting the site with your browser in private or incognito mode.

FYI, requiring the core to be under the web root was done for Composer compatibility. I’m not crazy about it either.

If you’re desperate enough, you could “upgrade” the site to version 2.8.4, either manually, or with the UpgradeMODX extra. You’d have a bunch of leftover 3.x files, but you’d be back at MODX 2.

12

I already tried downgrading it to 2.8.4, that was one of my first reactions once I realized what a mess 3.0 was, it was a total failure, our site pages totally failed to load, so I had to reinstall 3.0.1.

This totally sucks, to be honest, I consider this a full on fail by modx, and proof positive that 3.00 is beta at best, and should be pulled immediately as a stable branch for normal upgrade installs, or at least create a true test suite that verifies extension support PRIOR to install and upgrade.

Moving core to document root to satisfy a script kiddie piece of php junk like Composer is likewise nothing but a huge red flag warning sign to me.

I’ve triple checked my paths in config.

I’m getting permissions errors on install, which I’ve been getting fairly consistently with this move of core to doc root, I keep fixing them, but I keep getting new ones, the Articles install spits out a bunch, I’ll have to debug those too now.

It does show that those other extensions were part of Articles:
archivist
getresources
getpage

which I was wondering where they came from.

I’ll fix those permissions things.

I have no idea what has happened with this 3.0 stuff, everything that was working for a decade in 2.x modx is giving issues left and right for me, I’ve wasted days on what should have been a seamless smooth transition if it had been designed and implemented right, but it wasn’t. And I read ALL the docs, over and over, carefully!!

Again, I can’t disable a live working client site, that’s not real advice, unless you have no users, that’s not something I can do and expect to explain to my clients why modx is that screwed up to require such an extreme measure.

Also, I am fully aware of the issue with using extensions, so I always avoid them like the plague, we use only the barebones minimum required to make the site run, but for 3.0 to not have fully handled core extensions like quip before release as stable is inexcusable, same for Articles etc, those were release blockers, and were ignored by modx, which screws over the users totally, which is another huge red flag to me.

13

lol, I hate modx 3. I hate the new left nav thing, which is just dumb and harder to use than the old simple clean nav stuff.

Tested with Articles, first had a nasty scare, but realized it was another annoying 3.0 thing hiding something that had never been hideable before.

If we weren’t looking at 10s of thousands of dollars to move our site to a new cms, and also, if modx actually was picked because it works the way I want a cms to work, when it works, I would contact my clients and tell them we need to find a new cms, this stuff is terrifying and scary, the opposite of what I want a cms to be.

14

Look in the modx_site_content database table.
Check the class_key column.

If you see any called ArticlesContainer, change that to Articles\Model\ArticlesContainer.
Any with the value Article should be changed to Articles\Model\Article.

That should fix the resource display issue (if Articles is installed).

1 Like
15

Will try that, thanks.

Also tried installing Articles on live site, then uninstalling it using the full uninstall all versions option, but same result. Also uninstalled dependencies getpage, getresource, taglister, archivist.

That also made no difference, just as a datapoint.

Also, the first installs I did gave permissions errors, but the second reinstalls and uninstalls did not, which suggests there is something wrong with how modx is doing directory permission handling.

16

Database doesn’t have anything for Articles in database table modx_site_content.

We had removed Articles almost immediately after installing it since it didn’t do what we needed, I don’t think we ever made any pages with it, if we did, we deleted them I think.

I’m seeing errors all over the place, trying to install getpage or getResources says they aren’t there, and when I try reinstall, it says that it can’t download them because it doesn’t have an installer/downloader tool like curl or whatever, when I just installed something else and downloaded it.

17

I’m seeing a lot of permissions errors, these are caused by modx, not me I realized, for example, trying to download extension getpage resulted in error saying no downloader was enabled, which is absurd since I just did a download, but removing it, deleting, then downloading it again, worked fine.

These are all big warning signs to me of very bad code running, that was not tested nearly enough before stable release, and I’m seeing these issues almost everywhere I look.

Note that for clients to be unable to edit or view the site resource manager totally nullifies the entire point of using a cms, for this to be this fragile… bad engineering, I can’t really see any other cause for such failures to even be possible from my point of view. I mean, yes, obviously, way way way too much ajax is the obvious real cause.

I’ll keep chipping away at this, but ajax issues are almost totally impossible to debug unless they make php throw an error, which is not happening.

18

Further checklists:

  • config.core.php in connectors and core has right paths for core: check
  • config.core.php paths end with ‘/’, check.
  • connectors have right path, check.
  • doc root config.core.php has correct core path ending in /, check.

Known realities that are specific to one install, but not to another, running very similar systems, tested with php 8.1 on both to verify:

  • on Dashboard load, live Resources Elements Files menu loads, but the actual contents of the Resources > web fails to load. Nor is its load event even called on page load. On the working dev site, the load event is called. Something is making the load ajax query fail to execute.
    In other words, the page runs this:
    siite/connectors/index.php?action=Resource/GetNodes&id=root
    to build the primary left column navigation for top, which is then supposed to fire the sub builder:
    site/connectors/index.php?action=Resource/GetNodes&id=web_0&type=MODX\Revolution\modContext

but this is not triggered on the failing page.

Trying to force it by clicking on the ‘web’ link under the ‘Resources’ top menu item then trips the javascript error, and also the page redirect error, which I believe must be coming from modx core? I looked for a 301 on connectors/index.php but none is there, so the redirect must be originating in modx core, not connectors.
That’s this class:

$connectorRequestClass = $modx->getOption('modConnectorRequest.class', null, \MODX\Revolution\modConnectorRequest::class);
$modx->config['modRequest.class'] = $connectorRequestClass;
$modx->getRequest();
$modx->request->sanitizeRequest();

if (!$included) {
    $modx->request->handleRequest();
}

The failed request never gets to that point, and instead just starts making the rest of the page, without any error indications at all.

When the request is forced, by clicking on the web item, the javascript error in first post appears, but no php errors appear.

While I can’t fully understand this, I believe it appears because the data is empty or null or not defined, and so creates the 301 html page return, which redirects to the site home page, which is HTML, and thus trips the > in code error, since that was supposed to be json data, not an html page. Because ajax is almost impossible to debug, I can’t confirm that the 301 redirect is coming from modx core, but I believe it is, since it makes little sense otherwise. I first thought it was coming from something on my htaccess, but that was a red herring, it’s generated by modx core almost certainly, without any actual errors or messages about the event.

That’s as far as I can get after 2 days…

Articles has been installed, uninstalled, and the database table checked for stray articles, and none is present.

I consider the true bug here to be the godawful impossible to debug js ajax page constructors, because if this was clean basic php, it would take only a few minutes to find the bug cause and fix it.

There must be a js ajax event that is supposed to fire off the request for the web resources html json data, and that event is failing to fire, but of course, since this is a huge ball of unreadable and undebuggable js, finding out why is next to impossible.

No JS errors are reported on page reload, no php errors, which means this is essentially a pure guessing game, which is bad code, bad logic, and very terrifying to me.

19

Next, I tried fully removing:
Archivist
Articles
getpage
getResources
taglister

which are the set that installing Articles pulls in. The uninstall went ok, except for some errors about stuff missing that the install just installed, which was not missing.

this did not change anything either.

Because the event that is failing to load the web html json request must itself be triggered by the real failure, and that failure is somewhere in far too many lines of impossible to read or decipher javascript, I will have to now give up.

I will experiment to see if I can reinstall 2.8.4 without disaster and with pages loading, if that fails, I don’t see any forward path for modx and our company unfortunately at this point, and I can’t spend forever trying to track down causes of such failures, though I will spend a while on it since I am very stubborn, but I have to draw a line somewhere.

Years ago I was given the correct advice about which cms to use, which was to write my own, and I should have followed that advice, but sadly I opted for the convenience, and modx really was quite good for a long, long time. But this ajax bs is really silly and creates this issue, and makes it difficult to debug, if not near impossible.

20

Retested, downgrading to 2.8.4 fails, it doesn’t work. It’s a 1 way thing. I don’t know if it’s extensions or what, and can’t take the time to figure out that issue.

But when loading a page, just to give people an understanding that the 3.0 codebase is BAD, and poorly done:

**Deprecated** : trim(): Passing null to parameter #1 ($string) of type string is deprecated in **site/core/src/Revolution/Filters/modOutputFilter.php** on line **66**

**Deprecated** : strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in **site/core/src/Revolution/modParser.php** on line **420**

The fact these errors even exist at all in 2022 should make you run from 3.0 as quickly as you can. Those types of errors fill the codebase, and I wish I’d realized this before updating.

I’ve alerted my clients about this issue, and we’ll have to think about what to do next, I clearly can no longer trust modx unfortunately, which is a real drag, I really liked modx, have for almost 20 years, almost since it came out.

I’m praying we can figure out what the relevant difference is between my dev version and the live version, right now it’s looking like the only major thing I can think of is cloudflare and some change in how modx does stuff, and totally inadequate testing mixed with radically overambitious refactoring of an entire codebase.

Be warned anyone thinking of updating to 3.0.1, it’s not ready, and there may be no help for failures.

I again recommend pulling 3.0 totally until you can actually debug failure cases and issues, and have removed all the deprecated php code.

Our site runs, but we just can’t update it. Techniically I could update my local version, then import the database reverse to the live one, and do it that way, but that’s absurd, that just means it’s time to find a new cms in my opinion unless we can get this figured out.

Technically there is no hurry until we need to add or update pages, so we have maybe a few weeks to figure this out, but no more.

Worst case I can rewrite quip, but given modx is now a commercial project, you have to pay me to do that, the refactor should not be difficult overall I think, it should have been done already by someone familiar with modx. My clients won;'t pay for that either.