I noticed the first reports of this problem starting from Joomla version 4.0.4 - 4.0.5.

Hi,

This is the offending file:

plugins/fields/repeatable/repeatable.php

...
JLoader::import('components.com_fields.libraries.fieldsplugin', JPATH_ADMINISTRATOR);
...

If you comment on the line and refresh the error page, then the installer shows the success page.

Best Regards

@anibalsanchez - this issue should be flagged as a bug because it occurs in the migration from Joomla 3.10 to Joomla 4. Just dis a simple 3.10.6 to 3.10.8 to 4.1.2 update that ended with the notorious Oops - 500 errors. Then managed to scramble through debugging and ended up here.

Joomla 4.1.2 does not have the plugin folder plugins/fields/repeatable but migrating from 3.10 to 4.1.2 does not remove that folder. errors are displayed and the Joomla update log is nowhere to be found.

Even if commenting the JLoader::import line allows the front end to load, the process is bad from UX viewpoint.

The upgrade from 3.10.8 to 4.0.3 successfully replaced the repeatable with a subform field but upgrade to 4.0.4 fails.

It looks like the error is caused by the changes in JoomlaUpdater ZIP extraction helper for Joomla Update
implemented in the update from Joomla 4.0.3 to 4.0.4.

The related pull request is here: #35388

Since this change the old FieldsPlugin in administrator/components/com_fields/libraries/fieldsplugin.php is not removed anymore. So now there are two FieldsPlugin classes and due to ClassAliases it runs into the class already declared error.

I have still same problem in upgrade from 3.10.9 to 4.1.3
I have the friendly URL turned off and deleted .htaccess during the upgrade

I can confirm bug is still present trying to upgrade from 3.10.11 to 4.2.4.

Hello, I have upgraded to Joomla version 3.10.11 - ‎4.2.5‎ and the problem remains, I can't save articles

Class "FieldsHelper" not found

OK. So I looked at it and figured out the reason of the error. When you update from Joomla earlier than 4.0.4 (before PR #35388 merged), the system uses administrator/components/com_joomlaupdate/restore.php to handle the update process. At the end of that process, it calls finalizeRestore function https://github.com/joomla/joomla-cms/blob/3.10-dev/administrator/components/com_joomlaupdate/restore.php#L5103 to do some clean up before handling the process to Joomla to do the rest.

The problem is that if if you update to 4.0.4 and newer versions, the function finalizeRestore is not available anymore. The function should be called now is finalizeUpdate https://github.com/joomla/joomla-cms/blob/4.2-dev/administrator/components/com_joomlaupdate/finalisation.php#L54

Since finalizeUpdate function is not called, file administrator/components/com_fields/libraries/fieldsplugin.php is not deleted before Joomla calling method uninstallRepeatableFieldsPlugin https://github.com/joomla/joomla-cms/blob/4.2-dev/administrator/components/com_admin/script.php#L221 and it causes fatal error

A quick fix for this problem would be removing this line of code https://github.com/joomla/joomla-cms/blob/4.2-dev/administrator/components/com_admin/script.php#L240 (it is not needed anyway because the class is already registered in extensions class map https://github.com/joomla/joomla-cms/blob/4.2-dev/libraries/extensions.classmap.php#L16). But that does not fix the root of this error. The right fix would be fixing restore.php to call the right function.

For the time being, if anyone has this issue, while waiting for official solution, you can get the file restore.zip , unzip it, upload the received file to administrator/components/com_joomlaupdate to your Joomla 3 installation and update will work well.

Ping @nikosdion in case you want to look at this issue.

@joomdonation I am a bit confused by the description.

The file administrator/components/com_joomlaupdate/restore.php was used before Joomla 4.0.4 to extract the update ZIP archive. At the end of the archive extraction we would load the file restore_finalisation.php and run its finalizeRestoration function.

After 4.0.4 we use the file administrator/components/com_joomlaupdate/extract.php to extract the update ZIP archive. At the end of the archive extraction we load the file finalisation.php and run its finalizeUpdate function.

The change from restore_finalisation.php to finalisation.php and the change in the function name was made to allow update from Joomla 4.0.0–4.0.3 to 4.0.4 and beyond while also allowing Joomla 4.0.4 and later to update to whatever is the latest version.

These files have NOTHING to do with administrator/com_admin/script.php.

Moreover, your solution does not make sense because uploading the file which already exists is unnecessary. When you upgrade from Joomla 3.10.0–4.0.4 (inclusive) the archive extraction takes place through restore.php. This file is there until it's deleted by the finalizeRestoration function called by restore_finalisation.php which is loaded by restore.php.

The only problem which could happen is if the update package includes the restore_finalisation.php which loads finalisation.php because the latter file does not declare a finalizeRestoration function.

So what should really happen is change the finalisation.php to declare a finalizeRestoration function which calls the finalizeUpdate function.

Does that make more sense?

Thanks for your reply @nikosdion

These files have NOTHING to do with administrator/com_admin/script.php

Not sure if I understand your reply correctly, but the finalizeUpdate function calls the below code, which is defined in administrator/com_admin/script.php, so it is related.

(new JoomlaInstallerScript())->deleteUnexistingFiles();

So what should really happen is change the finalisation.php to declare a finalizeRestoration function which calls the finalizeUpdate function.

That makes sense if we only have to worry about people update directly from old version to latest version (contains the propose change). I was thinking about changing restore.php because It helps solves the issue if users update to version 4.2.4 or older (before we implement the fix which is being discussed here). I'm unsure if it is needed, thought. So if it is not needed, then the change you suggested would be best and easiest to implement.

Also, just a note that finalizeUpdate function depends on clearFileInOPCache which is defined in extract.php, so if we add finalizeRestoration function to finalisation.php , we will have to define clearFileInOPCache in finalisation.php, too (of course with function_exists check). Not sure if I miss anything else ?

The \JoomlaInstallerScript::uninstallRepeatableFieldsPlugin method in the administrator/com_admin/script.php file is only even called from \JoomlaInstallerScript::update which is only ever called from \Joomla\Component\Joomlaupdate\Administrator\Model\UpdateModel::finaliseUpgrade which has absolutely nothing to do with restore.php, extract.php, the finalizeUpdate function, or the finaliseRestoration function.

After the archive extraction is complete and AFTER we call the preliminary upgrade code in the finalizeUpdate or finaliseRestoration function THEN AND ONLY THEN we redirect the user to /administrator/index.php?option=com_joomlaupdate&task=update.finalise. This calls the \Joomla\Component\Joomlaupdate\Administrator\Controller\UpdateController::finalise controller method which calls \Joomla\Component\Joomlaupdate\Administrator\Model\UpdateModel::finaliseUpgrade which loads the administrator/com_admin/script.php file and runs its \JoomlaInstallerScript::uninstallRepeatableFieldsPlugin.

If you are ABSOLUTELY SURE that the problem comes from the \JoomlaInstallerScript::uninstallRepeatableFieldsPlugin method THEN the problem is with loading /administrator/index.php?option=com_joomlaupdate&task=update.finalise. This can be something as simple as the autoload_psr4.php file not being loaded, a code cache (like OPcache) not having been reset despite us trying to (whether we can depends on whether the server has disabled the necessary OPcache functions…), or whether a third party plugin (typically a system, user, or actionlog plugin which will have loaded at this point) is doing something stupid.

The fact that the problem happens only for some users makes me believe that it might be related to either the server configuration (OPcache most likely) or a third party plugin. However, since I do not have an affected setup I cannot test it, just speculate. You can reproduce the issue, you should be able to tell me :)

The fact that the problem happens only for some users makes me believe that it might be related to either the server configuration (OPcache most likely) or a third party plugin

It is because only this fatal error issue only happens with users who has repeatable fields setup on their website as described in this issue #38909 . We can easily re-procedure the issue with a fresh Joomla 3.10.11, setup repeatable fields, add one article and upgrading to latest version

What is actually happening here is that after your PR #35388 , the finaliseRestoration function is not called anymore (because it does not exist, only finalizeUpdate available) . So files defined in https://github.com/joomla/joomla-cms/blob/4.2-dev/administrator/components/com_admin/script.php#L591 are not being deleted (like before) before the process is being redirected to administrator/index.php?option=com_joomlaupdate&task=update.finalise for Joomla to do the remaining works of the update itself.

Since the files are not being deleted as expected, the file administrator/components/com_fields/libraries/fieldsplugin.php which define FieldsHelper class is still there. The FieldsHelper class is already registered in our extension class map https://github.com/joomla/joomla-cms/blob/4.2-dev/libraries/extensions.classmap.php#L16 and then being registered again here https://github.com/joomla/joomla-cms/blob/4.2-dev/administrator/components/com_admin/script.php#L240 and it causes this fatal error. We can remove the call here https://github.com/joomla/joomla-cms/blob/4.2-dev/administrator/components/com_admin/script.php#L240 to avoid fatal error, but it does not address the root of the issue

What we need to address here is making sure finaliseRestoration or finalizeUpdate function need to be called before redirecting to administrator/index.php?option=com_joomlaupdate&task=update.finalise for further clean up.

I hope It is clear now. I understand the issue and where it comes from, but might be difficult to explain it a clear way.

Sorry, I've had one hell of a day, fighting a massive Chinese DDoS which eventually took down the entire US infrastructure of my host (despite managing to mitigate 99.49% of the peak traffic with CloudFlare). My brain is a bit fried as a result.

The correct solution would be what I said earlier:

So what should really happen is change the finalisation.php to declare a finalizeRestoration function which calls the finalizeUpdate function.

This would make sure that no matter which Joomla version you are migrating from the extraction script —be it the legacy restore.php or the new extract.php— will call the preliminary code which removes files.

Since you've figure out the problem please do a PR and at-mention me so I can check it (tomorrow, after getting a full night's sleep!). Please do write repro steps starting with Joomla 3.10 so I can reproduce it and verify the fix.

Thank you in advance and sorry for confusing you!

OK. I will prepare a PR and ask you to check when it is ready. Thanks for discussing and suggesting (the better) solution !

I made PR #39245 to address this issue. Please help testing. Thanks !