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?
<?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
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.
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?
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.
# 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
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 *
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.
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”.