Every upgrade from 2 to 3 ends in a disaster

Nope. This is the full error message, nothing else.

I tried now to install the 3.0.3 version again (and a third time). No I can log into the manager. Seems that there was a fault with data transfer? Tomorrow I will look at the system, install the extras and than I can see if it works as expected.

This stress is not intended for an old man :sunglasses:

Are you doing an overwrite upgrade? Have you upgraded all the Extras on the site prior to upgrading to 3.x? How are you getting the new version files onto the server? Are you using SFTP or SSH? Ideally, uploading the intact zip to the server and unzipping and overwriting it to the correct directory is the best way to do it to avoid data corruption. How are you moving the files into the correct directory?

I’ve done a few of these and, fortunately, I’ve not had issues of full breakage but I’m also leveraging the upgrade button inside MODX Cloud. I’ve definitely made sure to upgrade the Extras and disable any custom Manager themes (these were sketchy before 3.x). I’ve disabled any custom Dashboard Widgets (mainly because when they 500 few of them fail gracefully, they’ll hose the entire Manager).

I’ve also heard net positive reports about UpgradeMODX to upgrade the sites.

1 Like

It’s unlikely that you need to uninstall all your extras. It’s almost always plugins that cause trouble with the new version (and as Jay says, Dashboard widgets).

Disabling all your plugins (by right-clicking on them in the tree), removing all widgets from the default dashboard, and then manually clearing the site cache by deleting all the files in the core/cache directory should be enough.

I also recommend that you install the Upgrade MODX extra, and not delete that widget from the dashboard. Perform the other steps above in your MODX 2 version, then use UpgradeMODX to upgrade to MODX 3.

Also, when things go south after an upgrade, try visiting the site with your browser in incognito or private mode. Sometimes stuff in the cache or cookies will cause trouble after an upgrade.

Another good tool in these situations is the Chrome extension, Classic Cache Killer, which will take the browser cache out of the equation.

1 Like

Ok, step by step.

@smashingred Yes it’s an overwrite upgrade at a shared hosting. Alll extras are up-to-date but I deinstalled all of them to avoid problems. The new files are going to the server via SFTP (I never tried SSH). This way I don’t have an option to de-zip files on the server. And I never used custom manager themes. Only standard dashboard widgets were active.

@bobray Will try only deactivating the extras (plugins) next time. And I will remove all dashboard widgets.
I always clear the cache manually in core/cache every time. (And the cache killer extension is one of my favorite extensions in Chrome, this browser is sometimes so stubborn with the cache.)

I have two other upgrades wating and for these I will try the UpgradeMODX extra.
Wish me luck … and thanks for your help.

1 Like

Are you going straight from 2.8.* to 3.3 ?

if so try upgrading to 3 and then 3.3

Look at this post: Which 3.0.X version from 2.8.3/2.8.4? - #2 by markh
@markh wrote that an upgrade directly to 3.0.3 should be ok.

To verify the process I will run the whole upgrade process from start again via a clon from 2.8.3 to 2.8.4 and then the upgrade to 3.0.3 in consideration of all tips above.

@smashingred UpgradeMODX doesn’t work from 2.8.x to 3.0.x. There is no option for such an upgrade.

There is a system setting (ugm_show_modx3) that has to be changed.
It’s to avoid accidental upgrades to MODX 3.

1 Like

Nice to know, thanks!

Now tried exactly the way described above. Cloned the 2.8.3 via SSH. Installed the Extra UpgradeMODX. Created writable directories setup and ugmtemp (otherwise I got errors).

Upgraded to 2.8.5: result shows version 2.8.3??

Changed setting ugm_show_modx3. Tried to upgrade to 3.0.1 …

Error 503

Site temporarily unavailable; missing dependencies.

And yes: every time I cleared the cache manually. And all plugins are deactivated. config-file is ok. No other dashboard widgets then the UpgradeMODX widget.

Tried another time: Upgrading from 2.8.3 to 2.8.5 works but shows 2.8.3 further in the head.
Then trying upgrade to 3.0.1 crashes after clicking the button of UpgradeMODX with a 503. Calling the Manager-URL shows the 2.8.3 version … seems that nothing happens. MODX error-log is empty.

Does core/vendor/ exist? It sounds like new files aren’t getting put in place. File permissions?

Can you grab your setup log from core/cache/logs/?

Did you only change path settings in core/config/config.inc.php
or also in the other config files in /, connectors/ and manager/ ?

@markh Tried another time manually transfering the zip file of modx 3.0.3 to the server. Then de-zip via SSH and moving all directories/files into the target directory. Checked all permissions. (@raffenberg all paths are ok)
Started the setup. First steps worked. Now I’m at the summary. Says that the config file has wrong permission (that’s ok, must set by me). All other descriptions are green except the last.
Because I use the german setup it says:

  • Fehler beim Löschen der Flash-Datei für die ‘In die Zwischenablage kopieren’-Funktion.

Button “try again” => error 500

In core/cache/logs there are two log files with same time stamp. One is 1 KB the other has 562 KB

This is the content of the smaller file

[2023-03-30 15:22:41] (ERROR @ /is/htdocs/.../core/vendor/xpdo/xpdo/src/xPDO/Cache/xPDOCacheManager.php : 327) PHP warning: chmod(): Die Operation ist nicht erlaubt
[2023-03-30 15:22:41] (ERROR @ /is/htdocs/.../core/vendor/xpdo/xpdo/src/xPDO/Cache/xPDOCacheManager.php : 324) PHP warning: mkdir(): Keine Berechtigung
[2023-03-30 15:22:41] (ERROR @ /is/htdocs/.../setup/includes/modinstall.class.php : 661) Beim Versuch der Sperrung des Setups ist ein Fehler aufgetreten. Das Unterverzeichnis '.locked' konnte im Setup-Verzeichnis nicht angelegt werden.
[2023-03-30 15:22:41] (ERROR @ /is/htdocs/.../setup/includes/modinstallsettings.class.php : 164) PHP warning: fopen(/is/htdocs/.../core/cache/setup/settings.cache.php): Failed to open stream: Datei oder Verzeichnis nicht gefunden

The other log contains many PHP unlink warnings.
Then many of these:

… core/vendor/xpdo/xpdo/src/xPDO/Transport/xPDOObjectVehicle.php : 227) Could not load vehicle!
… core/vendor/xpdo/xpdo/src/xPDO/Transport/xPDOTransport.php : 268) PHP warning: Undefined array key "guid"

The last is
… core/vendor/xpdo/xpdo/src/xPDO/Cache/xPDOCacheManager.php : 509) PHP warning: rmdir(/is/htdocs/.../core/cache/logs/): Das Verzeichnis ist nicht leer

Maybe I have the wrong provider … ?

The code tries to delete the file manager/assets/modext/_clipboard.swf but can’t. Maybe delete it manually.

As this error is not critical and the “summary” is the last step, are you able to log in to the manager?

Maybe check if something gets logged in the server error log.
500 errors usually are not logged in core/cache/logs/error.log.

No, can’t log in to the manager, same error 500.

Server error log has no relevant info, only this:
AH01630: client denied by server configuration: /is/htdocs/.../core/docs/changelog.txt

I’m now back in 2.8.3 – next try :sob:

I don’t know what exactly the problem is, but there seem to be many problems with permissions. You don’t have permissions to create/delete files/directories.
Maybe make sure all file permissions are correct, before you start the upgrade process.

Seems that the most problems depends on the permissions. Have to contact the support and hope that they can help.

Typically, permissions for all folders should be set to 0755 and all files to 0644.

Also, if in your earlier attempts, you changed paths and URLs in config.inc.php or the three config.core.php files, and any of them are incorrect, that will keep UpgradeMODX (and any other method) from working.

1 Like

Ok, now I have some questions. I have installations on different providers (Hosteurope, netcup, dogado, Strato, IONOS), older 2.8.x and new 3.0.x

A new 3.0.3 installation works at Hosteurope with standard permissions 750 and 640. Seems that this is ok instead of 755/644? Or do I have to change the permissions?
For assets, core/cache, packages and some other directoriess I have to change the permission to 777, otherwise I get an error during installation. Of course the config.inc.php gets a 777 during installation, after that I return to 644.

Even though the core/config.inc.php is ok, all config.core.php at Hosteurope installations are:

define('MODX_CORE_PATH', dirname(__FILE__) . '/core/');
define('MODX_CONFIG_KEY', 'config');

These configs at other providers show a long path. Why at Hosteurope this configs are unchanged after installation?

Hosteurope has a restricted server management for shared hosting. In the file management section I can change permissions system wide and I can set user and group permissions for directories and files. Standard is ftp permission for the user and server permission for group.

Is this ok or should I change any permissions?

Do your files have different file owners? For example, when you upload a file with FTP is the file owner different than when you create a new file in PHP?

The same user should probably own all files do avoid such additional complications during installation.

1 Like