MODX_CORE_PATH is invalid

So as of the weekend it looks like I am a new MODX convert!

. . . hammering away at my first install, it occured to me I should see how badly I can break it. [Pretty badly, it turns out, but that's OK -- I firmly believe in always breaking ones "toys" before becoming reliant on them so you can see whether they are repairable! ;-) ]

So, I renamed the MODX site DB (using MariaDB as replacement for MySQL) and moved the core.

I then edited ALL relevant config files.

Result: MODX site broken!

Solution(?) Reinstall with "proper" MODX package (then one I had used was NOT the advanced one)!

1. So I nuked all directories without custom content (i.e. I left my CSS and images so that I don't have too much to fix)

2. Unziped the ADVANCED install package (modx-2.3.1-pl-advanced.zip) and separate the core (THREE levels up i.e. from mydomain/public/www/core to mydomain/MODX/core )

3. rerun MODX setup

"Solution" derailed:
Keep getting "ERROR: Your MODX_CORE_PATH is invalid; please specify the correct path in the field above and click Submit."

SO . . . I put the core BACK at mydomain/public/www/core and get the SAME error on setup

ALL of these directories are read+writable by the www-data user


Please note: I HAVE edited the DB table modx_workspaces to reflect the desired path (recommended in another post somewhere) which is interesting since it seemed to contain what looked like a VARIABLE, "{core_path}"

What witchcraft is required to get this reinstalled?


BTW, in the DB, table modx_site_content shows all my content is there. Other tables similarly indicate everything is all right.

Finally, this is all hosted on an Nginx if that makes a difference. [Could rewriting rules be messing something up? ]

Thanks in advance for your help

I "dumbed down" my Nginx config to stop URL rewriting and MODX still doesn't recognize any valid /core path I throw at it.

A plain vanilla (i.e. "traditional") install of MODX looks like it would work, but I am very hesitant to point it at an existing database since "upgrade installation" is not available (remember, I nuked most of the original installation's folders).

I never have any trouble moving the core and editing the four config files afterwards. You just have to be sure that the location where you put it has permissions for PHP to read/write the files and read/write/execute the directories, and have the correct path. It has nothing at all to do with nginx or rewites; these files are included not requested via URL.

The path must be a full file path from the server root, with a leading /. For example, if I do this on my localhost, it will be something like /Applications/MAMP/cores/site1_core/

Thanks for your response:

So, I have checked phpinfo() and it reports
that _SERVER["USER"] is www-data [I assume this is the system user under which PHP operates -- and nothing PHP-related has changed since I had a working system a number of hours ago . . . ]

For the moment, ALL folders and files having ANYTHING to do with MODX at the URL in question are set to read/write/list and those folders and files are owned and grouped to www-data


I note from your example path that MODX does not care that the /core folder is "close" (for example up one level) to the sites document root. And yes, I have included the FULL path from the root,
i.e. /home/8_Websites/Clients/blah/blah/MODX/core

At one point my folder had a dot in it, at other points NOT. Same result in each case. How does MODX deal with dots in folder names? Does it seem to care?

Am I missing something basic here?

Is there anything else any MODX guru can point to?

By the way, does field in DB table modx_workspaces need to reflect the desired path (recommended in another post somewhere) or will it work when it contains (as it does not) what looks like a VARIABLE, "{core_path}"

It seems to me MODX /setup/ should handle this issue in either case, but maybe not.

I have tried it both ways (although not with path in braces {/path/to/core} ) the two ways I tried obviously did not work.

Quote from: fbachofner at Sep 15, 2014, 05:46 PM

For the moment, ALL folders and files having ANYTHING to do with MODX at the URL in question are set to read/write/list and those folders and files are owned and grouped to www-data

I meant to say ALL USERS have full access (i.e. 777) . . . unsafe in production, but acceptable for the moment.

Famous last words, but I doubt this one is a permission problem.

Again, you need a PATH, not a URL. URLs are related to where the web root is; this is specified in your web server configuration. A path is related to the server's file system. PHP files including other files don't care about your web root or URLS, they operate with file system paths. So forget about nginx and URLs. They have nothing at all to do with where MODX will look for its core files.

It doesn't matter where you put the core files, as long as the PHP user can access them. With nginx and PHP/FPM this may or may not be the same user. More than likely with that kind of setup .php scripts are run as their owner's user - probably your FTP or SSH user. The entirety of MODX is run from the index.php file, or in the case of the Manager, the /manager/index.php file. Everything else is included or required and does not pass through the web server.

The variable {core_path} comes from the MODX system settings, and if you've moved it from the default location and/or renamed it, you have to tell MODX where that is, either on installation with an advanced installation, or by editing the four config files.

It's possible your PHP is configured to restrict where 'include' and 'require' and other file handling functions can go to access their files.

Hi Susan:

When I said "URL in question" I was just referring to the address at which MODX is being invoked by a browser, not the path I put into the "MODX_CORE_PATH" form field.

Because I was having such extreme problems trying to get it working on a remote host, I made a virtually identical installation here at home (LinuxMint 17 vs Ubuntu 14.0 -- for all intents identical when using as a server, but the remote host is a VPS).

Guess what? MODX 2.3.1 Advanced actually gets through the path selection process and the complete install here at home.

Like on my remote server, installation FAILS if I choose utf84mb character sets and collation (hopefully a MODX developer is taking note of this problem), but works fine with latin1.

My "shifted" core works on this machine.

OK, now I trust version 2.3.1

And now . . . Just tried it again on the remote server and guess what? It works with NOTHING HAVING CHANGED in the folders, files, etc. since struggling with this a couple days ago. The same exact thing that did not work Monday, works now. EXCEPT that I had enabled TUN/TAP on the server and also rebooted.

Grrr. It may be difficult to track down this issue, but at least I know 2.3.1 works as advertised! ;-)

Now I'll have to "break" it again on the remote host to trust I can fix it quickly in a pinch (necessary for confidence in production).

I'll report back.


Felix

Quote from: fbachofner at Sep 18, 2014, 05:06 AM

I'll report back.

I'm futzing with a couple new MODX installs over the past days . . .

Note to self and others:

when entering a custom core path, it MUST have not just a leading slash (per Susan above) but also a trailing slash! [Susan's example further up in the thread ( /Applications/MAMP/cores/site1_core/ ) shows it but does not call it out]

Without the trailing slash, Linux thinks it is a file (not a directory) and keeps complaining that the directory is invalid and doesn't allow you to proceed.

Sorry I didn't report back earlier, I forgot this thread was open.