Modx Cloud - cannot initialize Modx

Hello, I’m trying to run a script (ChatGPT generated as my PHP is not good enough), but I keep getting stuck on something that seems to be as standard as can be…

<?php
require_once '/www/config.core.php';
require_once MODX_CORE_PATH.'model/modx/modx.class.php';
$modx = new modX();
$modx->initialize('web');

This throws a 500 and I cannot figure out how to isolate the problem. Or does Modx Cloud prevent me from doing this?

Thanks & cheers --Mike

If you are using MODX 3, try the code from here instead:

https://docs.modx.com/3.x/en/extending-modx/modx-class/loading-externally

Did exactly that (checked the paths):

<?php require_once '/www/config.core.php'; require_once MODX_CORE_PATH . 'vendor/autoload.php'; $modx = new \MODX\Revolution\modX(); $modx->initialize('web'); Fails already on the third line... Any way to get some logging or somesuch? Or should I contact Modx Cloud people? Thanks & cheers --Mike

Did you check the PHP/server error log?

Thanks, I did now - this is the last one:

[06-May-2024 17:42:20 UTC] PHP Fatal error:  Uncaught Error: Call to a member function setProcessingElement() on null in /www/core/src/Revolution/modScript.php:116
Stack trace:
#0 /www/core/src/Revolution/modParser.php(508): MODX\Revolution\modScript->process()
#1 /www/core/components/pdotools/src/Parsing/Parser.php(276): MODX\Revolution\modParser->processTag()
#2 /www/core/src/Revolution/modParser.php(221): ModxPro\PdoTools\Parsing\Parser->processTag()
#3 /www/core/components/pdotools/src/Parsing/Parser.php(73): MODX\Revolution\modParser->processElementTags()
#4 /www/core/src/Revolution/modResource.php(521): ModxPro\PdoTools\Parsing\Parser->processElementTags()
#5 /www/core/src/Revolution/modResource.php(469): MODX\Revolution\modResource->parseContent()
#6 /www/core/src/Revolution/modResponse.php(72): MODX\Revolution\modResource->prepare()
#7 /www/core/src/Revolution/modRequest.php(154): MODX\Revolution\modResponse->outputContent()
#8 /www/core/src/Revolution/modRequest.php(138): MODX\Revolution\modRequest->prepareResponse()
#9 /www/core/src/Revolution/modX.php(1499): MODX\Revolution\modRequest->handleRequest()
#10 /www/index.php(63): MODX\Revolution\modX->handleRequest()
#11 {main}
  thrown in /www/core/src/Revolution/modScript.php on line 116

Thanks --Mike

setProcessingElement() is a method of the MODX parser class, which for some reason is not being loaded (the reference to the class is null).

This may be related to PdoTools, which installs its own parser, probably without that method. The error message is confusing, though, since the pdoTools parser should inherit that method from the MODX parser.

As a test I did an uninstall of PdoTools but the error persisted.

Any suggestion on a next step to try?

Thanks & cheers --Mike

Does the error log still show recent lines with “pdoTools” in them?

If so, install the CacheClear extra and run it after removing pdoTools, then see if the error is still there.

  • Uninstalled PdoTools
  • Ran Cacheclear
  • Still got the error:
[07-May-2024 05:40:42 UTC] PHP Fatal error:  Uncaught Error: Call to a member function setProcessingElement() on null in /www/core/src/Revolution/modScript.php:116
Stack trace:
#0 /www/core/src/Revolution/modParser.php(508): MODX\Revolution\modScript->process()
#1 /www/core/src/Revolution/modParser.php(221): MODX\Revolution\modParser->processTag()
#2 /www/core/src/Revolution/modResource.php(521): MODX\Revolution\modParser->processElementTags()
#3 /www/core/src/Revolution/modResource.php(469): MODX\Revolution\modResource->parseContent()
#4 /www/core/src/Revolution/modResponse.php(72): MODX\Revolution\modResource->prepare()
#5 /www/core/src/Revolution/modRequest.php(154): MODX\Revolution\modResponse->outputContent()
#6 /www/core/src/Revolution/modRequest.php(138): MODX\Revolution\modRequest->prepareResponse()
#7 /www/core/src/Revolution/modX.php(1499): MODX\Revolution\modRequest->handleRequest()
#8 /www/index.php(63): MODX\Revolution\modX->handleRequest()
#9 {main}
  thrown in /www/core/src/Revolution/modScript.php on line 116

Thanks for your efforts --Mike

That tells us that pdoTools is not the problem.

It’s very strange, because the modResource.phpand modScript.php files seems to be loading fine with the same path.

Try opening your browser’s dev. tools window (Ctrl-shift-i) and watching the network tab as you load your script page. You can click on individual lines in the grid and look at the headers and response tabs to see if there are any clues there.

Watching the dev tools window didn’t reveal anything more.

I have another Modx website https://whichbachcantata.be (Rev 2, also Modx Cloud based, moved there a couple of months ago from a previous hosting provider), so I tried the snippet there (but in Rev 2 form):

<?php
require_once '/www/config.core.php';
require_once MODX_CORE_PATH.'model/modx/modx.class.php';
$modx = new modX();
$modx->initialize('web');

And that also failed, with the following in the error log:

[09-May-2024 05:28:36 UTC] PHP Fatal error:  Uncaught Error: Call to a member function setProcessingElement() on null in /www/core/model/modx/modscript.class.php:104
Stack trace:
#0 /www/core/model/modx/modparser.class.php(537): modScript->process()
#1 /www/core/model/modx/modparser.class.php(251): modParser->processTag()
#2 /www/core/model/modx/modresource.class.php(546): modParser->processElementTags()
#3 /www/core/model/modx/modresource.class.php(498): modResource->parseContent()
#4 /www/core/model/modx/modresponse.class.php(62): modResource->prepare()
#5 /www/core/model/modx/modrequest.class.php(138): modResponse->outputContent()
#6 /www/core/model/modx/modrequest.class.php(122): modRequest->prepareResponse()
#7 /www/core/model/modx/modx.class.php(1461): modRequest->handleRequest()
#8 /www/index.php(54): modX->handleRequest()
#9 {main}
  thrown in /www/core/model/modx/modscript.class.php on line 104

Important to note is that this site NEVER had pdoResources installed - I use getResources here.

Wouldn’t there be something in Modx Cloud’s setup, maybe wrong rights on a certain file or directory?

Thanks again & cheers --Mike

Is there maybe an .htaccess file either at the root or in the core directory that protects the core directory against .php files being run there? Otherwise, I’m stumped.

Here’s the .htaccess file of the Rev3 site:

# MODX supports Friendly URLs via this .htaccess file. You must serve web
# pages via Apache with mod_rewrite to use this functionality, and you must
# change the file name from ht.access to .htaccess.
#
# Make sure RewriteBase points to the directory where you installed MODX.
# E.g., "/modx" if your installation is in a "modx" subdirectory.
#
# You may choose to make your URLs non-case-sensitive by adding a NC directive
# to your rule: RewriteRule ^(.*)$ index.php?q=$1 [L,QSA,NC]

RewriteEngine On
RewriteBase /


# Prevent rewrite the .well-known directory used by LetsEncrypt by rules below of this rule
RewriteRule "^\.well-known/" - [L]


# Prevent dot directories (hidden directories like .git) to be exposed to the public
# Except for the .well-known directory used by LetsEncrypt a.o
RewriteRule "/\.|^\.(?!well-known/)" - [F]


# Rewrite www.example.com -> example.com -- used with SEO Strict URLs plugin
#RewriteCond %{HTTP_HOST} .
#RewriteCond %{HTTP_HOST} ^www.(.*)$ [NC]
#RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
#
# or for the opposite example.com -> www.example.com use the following
# DO NOT USE BOTH
#
#RewriteCond %{HTTP_HOST} !^$
#RewriteCond %{HTTP_HOST} !^www\. [NC]
#RewriteCond %{HTTP_HOST} (.+)$
#RewriteRule ^(.*)$ https://www.%1/$1 [R=301,L] .


# Force rewrite to https for every host
#RewriteCond %{HTTPS} !=on [OR]
#RewriteCond %{SERVER_PORT} !^443
#RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]


# Redirect the manager to a specific domain - don't rename the ht.access file
# in the manager folder to use this this rule
#RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
#RewriteCond %{REQUEST_URI} ^/manager [NC]
#RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]


# The Friendly URLs part
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]


# For servers that support output compression, you should pick up a bit of
# speed by un-commenting the following lines.
#php_flag zlib.output_compression On
#php_value zlib.output_compression_level 5

Thanks --Mike

Oops there’s another one in /core and this one seems more suspicious, no?

# deny access to _all_ files in the core, including changelog.txt and error.log
# original borrowed from owncloud

# line below if for Apache 2.4
<ifModule mod_authz_core.c>
    Require all denied
</ifModule>

# line below if for Apache 2.2
<ifModule !mod_authz_core.c>
    deny from all
    Satisfy All
</ifModule>

# section for Apache 2.2 and 2.4
IndexIgnore *

Thanks --Mike

Can you maybe explain exactly what you are doing?

You are loading MODX externally. I assume in a .php file somewhere outside of MODX.
What else do you do after loading MODX?

In your error log stack trace modX->handleRequest() is executed in the index.php file. This is a normal MODX request and not your external .php file! I’m confused. How is this error log output connected to the code where you load MODX externally?

@halftrainedharry I wanted to create a snippet to update a template variable in a bunch of resources (of which I have the resource ID and alias). So I asked ChatGPT to create that snippet for me… I can mostly read and understand PHP, but I’m not good enough to write code, that’s why. And I certainly do not know the ins and outs of Modx in PHP.

ChatGPT started the snippet with the external load. Is there another way? Then that could be the solution.

The error log entries occured when I loaded the snippet, so I was assuming that they are related? They do not occur if I load another page.

Thanks again & cheers --Mike

If you run a snippet inside MODX, then MODX is already loaded and you don’t have to load it again. Just use the variable $modx in the snippet to access the MODX functionality.

Don’t do this. These AI tools are just guessing. They’re not “intelligent”.

@halftrainedharry OK thanks, I won’t load it again!

Well ChatGPT already created a few snippets for me that worked fine… But I know they cannot (currently) be perfect.

Thanks for all your help --Mike