/JROOT/cli
folder/JROOT/cli
No error like described below.
Finish all jobs from /administrator/components/com_admin/script.php
Script stops working at:
$result = $jUpdate->finaliseUpgrade();
Command: php5-56STABLE-CLI update.php --core
Fatal error: Class 'JExtensionHelper' not found in /PATH/administrator/components/com_admin/script.php on line 383
Command: php7-70STABLE-CLI update.php --core
Error displaying the error page: Class 'JDocument' not found: Class 'JExtensionHelper' not found
Command: php7-71STABLE-CLI update.php --core
Error displaying the error page: Class 'JDocument' not found: Class 'JExtensionHelper' not found
• Tried to update different < 3.8.1 versions to 3.8.1 with same result
• Used PHP 5.6, 7.0 and 7.1 with different error results
• Apache
Line with JExtensionHelper
committed here:
2474c3c#diff-e3c745afdbb43914c4f183a8c1587346
System use current Joomla! version after updating but not all jobs from /administrator/components/com_admin/script.php
are done.
Labels |
Added:
?
|
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-10-12 12:00:16 |
Closed_By | ⇒ | mbabker |
Thanks for the fast reply.
Please allow me one question to make sure I do not get it wrong...
Joomla! ist already updated by the script.
The script then is using $jUpdate->finaliseUpgrade();
what is calling the file /com_admin/script.php of the current J3.8.1 – but it is also available in the source version.
And then the error is happening because JExtensionHelper
is not available in this file of 3.8.1.
In my understanding this seems to be a 3.8.1 thing.
Even if it is one process the helper should be available from the old or new version, tho?
Or do I miss something?
Thanks for any further info on this. I still want to get more into and understand all this. Thanks.
The process starts using whatever old version you're coming from (presumably any non-3.8 release will hit this). So in memory Joomla is loaded using the old version of the API, no part of which loads JExtensionHelper
automagically. Because the file with that class was moved because of the library namespacing work done in 3.8 and because the CLI process doesn't know it needs to load an aliasing layer, it fails trying to find classes that were namespaced but haven't been loaded into memory prior to the filesystem cleanup operation.
Roger that. Thank you.
So what's the solution?
It's an issue that will have to be addressed with that script, not a core error that can be fixed.
The problem is the update runs as one single PHP process. So the CMS environment is bootstrapped to the old version platform and in the middle of the update to 3.8 many files have been renamed and inherently removed. The script errors out after running the "delete old files" step because the class it relies on no longer exists as a "real" class and the class aliases are not loaded.