I had a site running MODX 2.8.4 nicely on PHP 7.4. Now trying to upgrade to 3.0.1. Running setup immediately gives this error message: Site temporarily unavailable; missing dependencies.
Is there an exhaustive list somewhere of what these dependencies are? An online search takes us here:
Which gives us this list of extensions: zlib, json, gd, pdo, pdo_mysql, imagick, simplexml, curl, and mbstring
On my CPanel PHP extensions page curl, simplexml and zlib are not listed as possible extensions. But I imagine that that is not the problem because I have a website built from scratch (i.e. not an upgrade) with 3.0.0 running without them on the same server.
Memory limits in both cases are 256mb.
So if there are other dependencies I need to check, where is the list?
P.s. have emptied core/cache and tried to empty the browser cache, but to no effect.
IIRC, that error is shown when the core/vendor/ directory doesn’t exist.
That directory is usually provided within the download, and only more advanced methods of installing/updating (such as directly from git) require knowing about it and how to fix it (i.e. run a composer install in the project root).
How did you handle the upgrade? Any chance the uploads failed or you used a third party system that isn’t aware of these differences in 3.0?
Mark, Thanks for that. The upgrade is being handled in the old manual way, uploading zip files, unzipping, merging, etc. And when I expand the updated core directory I see the vendor folder with a lot of subfolders.
As I said, on the same server I have one 3.0.0 site running nicely on the same PHP setup and database, collation, etc. So I am at a loss to see why the upgrade from 2.8.4 to 3.0.1 fails here. BTW, tried 3.0.0 as well but got the same error.
Did this site perhaps have a moved core folder, and it’s looking in the wrong place? In MODX3, the core folder must be moved back to its standard location and can’t be renamed or moved outside the root anymore.
I just checked the code and this error is indeed specific to the core/vendor/ folder (if it can’t find core/vendor/autoload.php to be exact).
If it does exist, and it is in the proper default location of /core/, and the core/config/config.inc.php file and config.core.php file point to the default location as well… perhaps PHP isn’t allowed to access the core/vendor/ directory or core/vendor/autoload.php due to file permissions?
I seem to remember being told it was bad practice not to move the core folder outside the root. If I understand correctly, it must now NOT be moved away from the root.
Joking aside, I do think that page needs to go into a bit more detail because when you try to upgrade to 3.0.x things do start happening that you haven’t seen before. Like I have now hit a brick wall with the disappearing setup folder phenomenon. It goes like this: you try to import the old database contents into the new database created especially for 3.0.1 and so break the manager. To try to fix that you go back and try to rerun setup, but something has locked it. It tells you where to find the lock, but you can’t see it there. So you just delete the setup folder, upload a new zip file, and unzip, but the new unzipped file also has no setup folder. So how do you rerun setup as people like Bob have advised us to do in the past?
To unlock it, just remove the setup/.locked/ directory.
If that doesn’t show up in your FTP/file manager, you may need to check if you’re allowed to see “dotfiles” as some software will hide files and directories starting with a dot by default.
(IIRC that was also implemented somewhere in the 2.x series and not 3.0 specifically )
Anyway, have now succeeded (I think) with the upgrade from 2.8.4 to 3.0.1. The only remaining question concerns the location of the core folder, because now that it is in the root of the site, I am getting a warning in the manager that “this is not recommended and a security risk.” So which is it? Is it a security risk or is it a requirement of the setup procedure that the core folder must be in the root?
It is a security risk to not have any protection for it, though. You can lock it down easily with rewrite rules - the sample ht.access has a snippet in it that will lock down the core, and there are others in the documentation.
I faced this issue. That advance installation instructions need to be updated for v3 as it does still considers that you “may” place the core folder outside the document root.
)