PHP 8.1.2 Modx 2.8.3 Manager content/navigation doesn't work

Support
1

Modx 2.8.3-pl
PHP 8.1.2
Apache 2.4.52
Platform: Debian GNU/Linux 12 (current)

After upgrading to php 8 on my dev system, my local modx manager only shows the top nav bar, and the main manager dashboard section, all other sections have only the top navigation. Clicking on things like clear cache does nothing. The resources left tree bar never appears. All site pages work fine, no issues.

https://forums.modx.com/thread/104516/in-manager-left-column-resources-list-fails-to-load-and-a-ghosted-empty-error-box-over-control-panel

Iā€™ve cleared core/cache repeatedly.

Following the above link, checking the Chromium debugger, there are js errors:

Unchecked runtime.lastError: The message port closed before a response was received.
ian/:1 Unchecked runtime.lastError: The message port closed before a response was received.
ian/:1 Unchecked runtime.lastError: The message port closed before a response was received.
lang.js.php?ctx=mgr&topic=topmenu,file,resource,trash,welcome,configcheck&action=:2 Uncaught SyntaxError: Unexpected token '<'
uploaddialog.js:1456 Uncaught ReferenceError: _ is not defined
    at uploaddialog.js:1456:10
(anonymous) @ uploaddialog.js:1456
modx.layout.js:113 Uncaught ReferenceError: _ is not defined
    at MODx.Layout.Default.getWest (modx.layout.js:113:24)
    at MODx.Layout.Default.buildLayout (modx.layout.js:64:26)
    at MODx.Layout.Default.MODx.Layout [as constructor] (modx.layout.js:35:22)
    at new MODx.Layout.Default (layout.js:6:48)
    at Object.create (ext-all.js:21:133120)
    at MODx.load (modx.js?v=00eb0b9e:85:38)
    at (index):52:10
    at ext-all.js:21:2438
    at b (ext-all.js:21:19924)
getWest @ modx.layout.js:113
buildLayout @ modx.layout.js:64
MODx.Layout @ modx.layout.js:35
MODx.Layout.Default @ layout.js:6
create @ ext-all.js:21
load @ modx.js?v=00eb0b9e:85
(anonymous) @ (index):52
(anonymous) @ ext-all.js:21
b @ ext-all.js:21
setInterval (async)
e.delay @ ext-all.js:21
(anonymous) @ ext-all.js:21
fire @ ext-all.js:21
b @ ext-all.js:21
modx.grid.user.online.js:12 Uncaught ReferenceError: _ is not defined
    at new MODx.grid.WhoIsOnline (modx.grid.user.online.js:12:12)
    at Object.create (ext-all.js:21:133120)
    at MODx.load (modx.js?v=00eb0b9e:85:38)
    at (index):64:14
    at ext-all.js:21:2438
    at b (ext-all.js:21:19924)
MODx.grid.WhoIsOnline @ modx.grid.user.online.js:12
create @ ext-all.js:21
load @ modx.js?v=00eb0b9e:85
(anonymous) @ (index):64
(anonymous) @ ext-all.js:21
b @ ext-all.js:21
setInterval (async)
e.delay @ ext-all.js:21
(anonymous) @ ext-all.js:21
fire @ ext-all.js:21
b @ ext-all.js:21
modx.grid.user.recent.resource.js:12 Uncaught ReferenceError: _ is not defined
    at new MODx.grid.RecentlyEditedResourcesByUser (modx.grid.user.recent.resource.js:12:16)
    at Object.create (ext-all.js:21:133120)
    at MODx.load (modx.js?v=00eb0b9e:85:38)
    at (index):71:10
    at ext-all.js:21:2438
    at b (ext-all.js:21:19924)
MODx.grid.RecentlyEditedResourcesByUser @ modx.grid.user.recent.resource.js:12
create @ ext-all.js:21
load @ modx.js?v=00eb0b9e:85
(anonymous) @ (index):71
(anonymous) @ ext-all.js:21
b @ ext-all.js:21
setInterval (async)
e.delay @ ext-all.js:21
(anonymous) @ ext-all.js:21
fire @ ext-all.js:21
b @ ext-all.js:21
modx.searchbar.js:8 Uncaught ReferenceError: _ is not defined
    at new MODx.SearchBar (modx.searchbar.js:8:21)
    at (index):95:17
    at ext-all.js:21:2438
    at b (ext-all.js:21:19924)
MODx.SearchBar @ modx.searchbar.js:8
(anonymous) @ (index):95
(anonymous) @ ext-all.js:21
b @ ext-all.js:21
setInterval (async)
e.delay @ ext-all.js:21
(anonymous) @ ext-all.js:21
fire @ ext-all.js:21
b @ ext-all.js:21

I should have debugged/reported this issue before starting the process of testing moving core from below document root to /core, but I forgot to do that, but as far as I recollect, this issue existed before I moved core/ to /core.

The live site is running Modx 2.8.3-pl on PHP 7.4.28, Apache 2.4.41, and everything works as expected.

My normal policy is to update the dev site to make sure everything is working, then update the live site, but at the moment, Iā€™m running PHP 8 to catch bugs and failures in our code/modx before the live site is upgraded to PHP 8 so Iā€™m a bit ahead of the live site.

I believe this issue hit as soon as my dev system upgraded to PHP 8, but as noted, I forgot to verify this before testing the move of below root core to above root core today.

Iā€™d like to get my local system back into good shape, I see the js errors, but I have no idea what to do about them.

I also tried reinstalling 2.8.3 as well, but the results did not change, thatā€™s using the same connectors directory. My modx upgrade script moves core and manager to a backup location, so those are always fresh when I do an upgrade.

I do NOT want to start testing Modx 3.0 until I get this local issue resolved for modx 2.8.3 on php 8, I noticed it while preparing to switch to using /core above doc root location.

Thanks

2

An update: because 2.8.4-pl just came out, I decided to give that a try, updated live and local site, both updates worked fine, but the issue with the local PHP 8 manager not working remains.

I forgot to note a few things:

  • A small part of the manager navigation works, I can log out. I cannot update Add-ons because the page is blank when I try to access it on the local system. As far as I can tell, logging out is the only navigation feature that works, the drop menus appear, but nothing happens when you click in them. I assume the logout works because itā€™s not loading the manager, itā€™s sending you to the login page, which is not broken.
  • I did also try disabling all plugins in local system following the advice in the link:
update modx_site_plugins set disabled=1;

This made no difference, still broken.

  • I updated the local core path in the db as well, to make sure:
UPDATE modx_workspaces SET path='/path/to/core/' WHERE id='1';

This step by the way might be added to the upgrade instructions, though the db for the update probably updates that by itself. This also made no difference.

The live PHP 7.4 site works fine, no issues, upgrade worked fine, everything is fine. The PHP 8.1 site manager doesnā€™t work, except for letting me log out. The site works, but I canā€™t do anything with it since the manager doesnā€™t work, it shows only the default main manager left Dashboard content, but not the resources left bar, and the menu items fail to do anything.

This is everything that I could find to resolve this issue, so Iā€™m stuck now. I have to suspect there is a PHP 8 issue somewhere, PHP 8 is MUCH more strict about errors and sloppy coding, Iā€™ve been finding and fixing small oversights in our own codebase for a while now.

I did note one thing locally, a lot of the deprecated code errors appear to have been cleaned up in modx 2.8.4, I only see those a few places now.

Manually opening /core/cache/logs/error.log shows the following, which seems to lock down that the issue is somewhere in the PHP for the menus. Note I manually cleared the cache, then reloaded the manager page, so this is from one single load of the manager, this is the updated to 2.8.4-pl modx, these errors have been there consistently:

[2022-04-28 21:10:43] (ERROR in modMenu::getSubMenus @ /path/to/site/core/model/modx/modmenu.class.php : 148) modAction support is deprecated since version 2.3.0. Support for modAction has been replaced with routing based on a namespace and action name. Please update the extra with the namespace core to the routing based system.
[2022-04-28 21:10:43] (ERROR in modMenu::getSubMenus @ /path/to/site/core/model/modx/modmenu.class.php : 148) modAction support is deprecated since version 2.3.0. Support for modAction has been replaced with routing based on a namespace and action name. Please update the extra with the namespace quip to the routing based system.
[2022-04-28 21:10:43] (ERROR @ /path/to/site/core/xpdo/cache/xpdocachemanager.class.php : 335) PHP warning: mkdir(): File exists
[2022-04-28 21:10:43] (ERROR @ /path/to/site/core/xpdo/cache/xpdocachemanager.class.php : 340) PHP warning: mkdir(): File exists

Running the same test on the live PHP 7.4 site returns zero errors for a fresh error log and a refreshed manager page load.

Note that the ā€˜coreā€™ directory has been replaced now completely in each test, so this canā€™t be legacy code, this I believe must be related to something someone has not caught in PHP 8.1, I canā€™t see any way itā€™s not caused by PHP version, maybe you can?

3

Whatā€™s the response of that request? It seems thereā€™s an error in there, and thatā€™s breaking all the javascript in the manager.

4

Good question, I neglected to double check after the 2.8.4 update, this is the new js errors, still has the undefined ā€˜_ā€™ and the

Unchecked runtime.lastError: The message port closed before a response was received.
ian/:1 Unchecked runtime.lastError: The message port closed before a response was received.
ian/:1 Unchecked runtime.lastError: The message port closed before a response was received.
lang.js.php?ctx=mgr&topic=topmenu,file,resource,trash,workspace,namespace&action=workspaces/namespace:2 Uncaught SyntaxError: Unexpected token '<'
uploaddialog.js:1456 Uncaught ReferenceError: _ is not defined
    at uploaddialog.js:1456:10
(anonymous) @ uploaddialog.js:1456
modx.layout.js:113 Uncaught ReferenceError: _ is not defined
    at MODx.Layout.Default.getWest (modx.layout.js:113:24)
    at MODx.Layout.Default.buildLayout (modx.layout.js:64:26)
    at MODx.Layout.Default.MODx.Layout [as constructor] (modx.layout.js:35:22)
    at new MODx.Layout.Default (layout.js:6:48)
    at Object.create (ext-all.js:21:133120)
    at MODx.load (modx.js?v=03040b7f:85:38)
    at ?a=workspaces/namespace:52:10
    at ext-all.js:21:2438
    at b (ext-all.js:21:19924)
getWest @ modx.layout.js:113
buildLayout @ modx.layout.js:64
MODx.Layout @ modx.layout.js:35
MODx.Layout.Default @ layout.js:6
create @ ext-all.js:21
load @ modx.js?v=03040b7f:85
(anonymous) @ ?a=workspaces/namespace:52
(anonymous) @ ext-all.js:21
b @ ext-all.js:21
setInterval (async)
e.delay @ ext-all.js:21
(anonymous) @ ext-all.js:21
fire @ ext-all.js:21
b @ ext-all.js:21
modx.searchbar.js:8 Uncaught ReferenceError: _ is not defined
    at new MODx.SearchBar (modx.searchbar.js:8:21)
    at ?a=workspaces/namespace:72:17
    at ext-all.js:21:2438
    at b (ext-all.js:21:19924)

Had to dig into it a bit more, the raw php error on load of that page is:

MODx.lang = {
Fatal error: Uncaught Error: Call to undefined function each() in /path/to/site/connectorsErt5hb/lang.js.php:24 Stack trace: #0 {main} thrown in /path/to/site/connectorsErt5hb/lang.js.php on line 24

Iā€™ve been cleaning up stray ā€˜each()ā€™ functions in legacy PHP code for a while now, that explains it, itā€™s in connectors, which doesnā€™t get updated during upgrades as far as I know, thatā€™s useful, I wasnā€™t looking in there.

This may be enough to fix it, Iā€™ll keep the thread posted, each() are a major issue in legacy PHP with 8.x, since they finally dropped support for that after having it be deprecated for a long time. each() are somewhat horrifying constructs, and require great care to manually correct.

5

Thatā€™s been fixed since 2.7.2, 2019 - why arenā€™t your connectors being updated exactly? That should definitely happen with a standard upgrade.

6

lang.js.php:24:while (list($k,$v) = each ($entries)) {

there it is, sitting, waiting, to blow up, lolā€¦

luckily this is the easiest each() construct to correct:

foreach ($entries as $k => $v ){

that was it, thanks for asking the right question, I hadnā€™t checked the actual php error on the file.

Looking at the stuff in connectors however, Iā€™m unclear why I was not upgrading that along with manager, I think I had thought there was something in there that couldnā€™t be upgraded, but it doesnā€™t look like it to me.

7

i agree with your question, I believe I was operating under a false and incorrect assumption about the function of the connectors directory, Iā€™ll modify my upgrade script to handle that.

Many thanks for another set of eyes on this, thatā€™s all that was needed to expose the issue.

Iā€™ll do a test on the upgrade script after correcting the connectors failure to change it on upgrade, that was the actual bug in this case, thanks again.

1 Like
8

This topic was automatically closed 2 days after discussion ended and a solution was marked. New replies are no longer allowed. You can open a new topic by clicking the link icon below the original post or solution and selecting ā€œ+ New Topicā€.