Answered is it safe to upgrade straight from 2.2.13-pl

Hello I forgot to upgrade a legacy site.... and I now see that I'm about 7 releases behind ( 2.2.13-pl -> 2.3.3-pl)!

all Server requirements are met (PHP, MYSQL, Apache versions ) but I still ask:

Is such a jump 'safe', any known issues that might brake the install ?

BTW I have an hardened install with renamed/moved Core, Manager and Connectors directories.


Thanks, Luca

Should be fine but check your addons are compatible with 2.3 ( not sure if this is kept up to date ) and do a full backup prior to upgrading.

https://github.com/modxcms/revolution/issues/11630

the udate went fine, no hickups -site is working

BUT

Addons are listed in the menu Extras manager menu, but Installer/Package Management is empty, Processor not found: getList
(I did move all packages from the old core), the providers tab is also empty and trying to create a new one for http://rest.modx.com/extras/ returns a 'Processor not found: create'

There's a wrong path somewhere ... ? will look into it tomorrow


ciao

It could be a wrong path or URL in core/config/config.inc.php, though if the connectors or processors path is wrong, the Manager shouldn't work at all.

Paths in config.inc.php look correct, while in the Error log I find many things like



for getlist.php and others php files.

Looking inside the '/var/www/myHiddenCore/model/modx/processors/' directory I don't see any php files, but just a list of 8 more directories:

• browser
• context
• element
• resource
• security
• source
• system
• workspace

I checked the before upgrade Core directory and it looked the same, but the addons page worked perfectly, so I don't think the update skipped some parts.

Typically, the processors are called with a string like 'resource/getlist', 'security/user/update'. Any call to a getList processor should have one of those directory names you list above between 'processors/' and 'getlist'.

In many cases, those strings are sent as data in an Ajax call, so you might turn on Firebug or something similar and check the console for JS errors.

That said, I can't think of any way the filename part of the string would get through without the first part.

Because of that, I wonder if you have one or more corrupted or missing files in your install. It's fairly common if you transfer the files individually with FTP.

I try not to push it here, because it's not free, but SiteCheck will check all the paths and URLs for you (among other things) and at least eliminate (or identify) an incorrect path as the problem.

It also occurrs to me that disabling all your plugins would be something to try (in the modx_site_plugins table in the DB if necessary -- just change the 'disabled' field from 0 to 1). You may have a plugin that hasn't been updated to run in the newer version. Delete all files in the core/cache directory after the change and before testing.

[ed. note: BobRay last edited this post 11 years, 5 months ago.]

Sorry I did not get (or see) the notifications from this thread and had been busy on other issues all week;
I still have no time to test for today, but I 'll paste in here the content of 2 log files created during the upgrade that I found in '/config/cache/logs'


file install.config.20150415T183132.log

[2015-04-15 18:31:32] (ERROR @ /setup/index.php) Error 42S22 executing statement:
Array
(
[0] => 42S22
[1] => 1054
[2] => Unknown column 'modContext.name' in 'field list'
)

file install.config.2015-04-15T18.31.32.log

[2015-04-15 18:31:32] (ERROR @ /setup/index.php) Could not prepare context: mgr

[2015-04-15 18:31:32] (ERROR in xPDOManager_mysql::addIndex @ /var/www/epos.bo.ingv.it/eposModXcore/xpdo/om/mysql/xpdomanager.class.php : 329) Error adding index cache_refresh_idx to modResource: Array
(
[0] => 42000
[1] => 1061
[2] => Duplicate key name 'cache_refresh_idx'
)

looks like I should try to fix the SQL tables and then reinstall ??

The first one suggest that one of the upgrade steps did not occur. The modx_context table got a 'name' field (I think in 2.3.0). It looks like yours didn't.

You might try restoring the older version and applying the intermediate upgrades, one-by-one. You could just add the 'name' field to the modx_context table, but there may be other upgrade tasks that didn't occur.