Got the same error and after deleting the administrator/cache/autoload_psr4.php it tells its version 4.2.0 now. Is that true or is it now a 4.1.2 with a wrong version display?

It will be 4.2.0 - the upgrade completes fine, its just that the autoload_psr4.php is not regenerated...

Okay, good :) Thank you!

related @joomdonation #37990

could someone correct the title please

could someone correct the title please

Sorry. Changed now

Here the update from 4.1.5 to 4.2.0 went fine. Maybe it happens only with PHP 8.1? I was on 8.0. Or maybe it happens only when updating from an older version than 4.1.5?

Another report https://forum.joomla.org/viewtopic.php?t=995736&p=3667485

Here the update from 4.1.5 to 4.2.0 went fine.

That is only one of many upgrade paths that should be tested. Joomla 4.2.0 upgrade it offered to all Joomla 4 versions as an upgrade and even to Joomla 3.10.x versions. All should have been tested.

Maybe it happens only with PHP 8.1? I was on 8.0.

Unrelated.

Or maybe it happens only when updating from an older version than 4.1.5?

Older versions of Joomla 4 have no code in finalise (as far as I can see in com_joomlaupdate) to regenerate administrator/cache/autoload_psr4.php after an upgrade. #facepalm

@PhilETaylor Code could be in the database model of the installer. Forget it, there is nothing.

Hello @PhilETaylor Thank you for the issue.

So I ran a couple of upgrades using PHP 8.1.0

• 4.1.0 -> 4.2.0
• 4.1.2 -> 4.2.0
• 4.1.5 -> 4.2.0

They all finished normally. After that I had a backup of a user who encountered this issue with 4.1.5 to 4.2.0. So I tested it with the users backup locally from 4.1.5 -> 4.2.0 also without issues.

Do you happen to have any more information on how this could be reproduced? I am going to do some more testing but would be helpful to get an idea of how to reproduce it reliably.

let me trawl the code history of a project I no longer contribute code to, for you...

d66de71

So, the above commit, It was not until 4.0.5-rc1 that Joomla Recreated namespace map on Joomla! update #36094

So basically any upgrade from < 4.0.5 will fail for sure.

It was "fixed" again here #37990 but again, code released before that date

Whether you can replicate or not, the multiple reports from multiple people indicate there is a real issue still to be resolved.

My own docker based Joomla 4 test container is Joomla 4.0.0 with PHP 8.0.18 with nginx. But the php/nginx is irrelevant. I click Start Update, wait, and then get the error at the end of the update - every single time.

Im just the reporter. I have no solutions.

joomla/update.joomla.org#261 Is totally the wrong solution - making users do multiple updates is not the correct approach

joomla/update.joomla.org#261 Is totally the wrong solution - making users do multiple updates is not the correct approach

It was not intended as solution but as workaround until the patches have been deployed as mentiond within the PR ;)

Whether you can replicate or not, the multiple reports from multiple people indicate there is a real issue still to be resolved.

I never said that there is no issue.

Im just the reporter. I have no solutions.

Was just asking for more info, not solutions.

So basically any upgrade from < 4.0.5 will fail for sure.

Thank you.

And on that note I'll unsubscribe. Have fun.

So, we have for now removed the update to 4.2.0 being offered while we are looking into the reports of sites failing the update and see how we can fix this as soon as possible.

So, we have for now removed the update to 4.2.0 being offered while we are looking into the reports of sites failing the update and see how we can fix this as soon as possible.

But you did not test that "fix". It "fixes" nothing. It workaround nothing. It just leads to the same root problem with a different error message and the same solution - removing the map file.

It was not intended as solution but as workaround until the patches have been deployed as mentiond within the PR ;)

@zero-24 Congratulations - now the upgrade to 4.1.5 from 4.0.0 is also SCREWED UP #38486

Im going to bed.

Its almost like someone gave you a massive heads up and warning about this... #37881 and then @joomdonation worked on #37990 after that but no one thought about what would happen to sites upgrading from prior versions...

All the warnings were there... todays fiasco could have been averted so so easily :(

#38486 (comment)

I have a failed update from 4.1.5 -> 4.2 - same taggable error displays. I deleted 'autoload_psr4.php' with no change. The deleted file is replaced on reload. Debug info:
0 Class 'Joomla\Plugin\Behaviour\Taggable\Extension\Taggable' not found
Call stack

Function Location

1 () JROOT/plugins/behaviour/taggable/services/provider.php:37
2 class@anonymous/home1/jeffer/public_html/test/plugins/behaviour/taggable/services/provider.php:20$1ab->{closure}() JROOT/libraries/vendor/joomla/di/src/ContainerResource.php:182
3 Joomla\DI\ContainerResource->getInstance() JROOT/libraries/vendor/joomla/di/src/Container.php:96
4 Joomla\DI\Container->get() JROOT/libraries/src/Extension/ExtensionManagerTrait.php:177
5 Joomla\CMS\Application\CMSApplication->loadExtension() JROOT/libraries/src/Extension/ExtensionManagerTrait.php:94
6 Joomla\CMS\Application\CMSApplication->bootPlugin() JROOT/libraries/src/Plugin/PluginHelper.php:235
7 Joomla\CMS\Plugin\PluginHelper::import() JROOT/libraries/src/Plugin/PluginHelper.php:193
8 Joomla\CMS\Plugin\PluginHelper::importPlugin() JROOT/libraries/src/Application/CMSApplication.php:736
9 Joomla\CMS\Application\CMSApplication->initialiseApp() JROOT/libraries/src/Application/SiteApplication.php:709
10 Joomla\CMS\Application\SiteApplication->initialiseApp() JROOT/libraries/src/Application/SiteApplication.php:224
11 Joomla\CMS\Application\SiteApplication->doExecute() JROOT/libraries/src/Application/CMSApplication.php:278
12 Joomla\CMS\Application\CMSApplication->execute() JROOT/includes/app.php:63
13 require_once() JROOT/index.php:32

delete the file administrator/cache/autoload_psr4.php
problem solved

As I stated, I deleted the file administrator/cache/autoload_psr4.php numerous times but problem is not solved and re-occurs repeatedly.

it is supposed to re-appear

Thanks Brian but I think you misunderstand me. I understand that the file is supposed to re-occur and it does that. The problem is that the error still occurs even after deleting the file multiple times.

I have the same problem as kp-martin. 4.1.5 to 4.2.0 upgrade (using Zip file method). The site is bricked with the error 0 - Class 'Joomla\Plugin\Behaviour\Taggable\Extension\Taggable' not found on front and back ends.

I deleted autoload_psr4.php but this did not help. I made sure that my host's edge caching was disabled. Don't know what else to try.

Update: I never found out what was wrong, but I managed to restore the site from a backup, version 4.1.5. Panic over.

@jeff-bronks

Update: I never found out what was wrong, but I managed to restore the site from a backup, version 4.1.5. Panic over.

Can you please deploy that site to a backup and try to update to 4.2.1-rc2: https://github.com/joomla/joomla-cms/releases/tag/4.2.1-rc2

I have the same problem as kp-martin. 4.1.5 to 4.2.0 upgrade (using Zip file method).

Please tell us what this "zip file method" is. Please be informed that updating it by just replacing the files will always fail. you have to use the updater component via install & upload or via update server (on the backup site you can also go to the testing update server)

OK, I deployed 4.2.1-rc2 to my backup site. It worked fine, and now it says 4.2.1-rc2 in the status bar. Thanks!

You correctly guessed what my Zip file method is: upload the file using the server's file manager and unpack it. I used to do it that way with my Joomla 3 site because the Joomla admin update page didn't work. I never found out why - it was something about an AJAX error. The Zip file method always worked for me with Joomla 3.

When I updated to Joomla 4 the admin update page worked so I used it. I only used the Zip method yesterday because the Joomla update page didn't offer the 4.2.0 update. Now I know why - you had discovered this bug and so you pulled the update. I am now schooled and I shan't use the Zip file method again!

Just to let you know that is not a supported update method its even not supported for J3 and never was supported for J4.

The problem is that there are more than just one step happening on the upgrade like updating the database and deleting files that nolonger exists as well as the autoload files. When you need to reset the files please use the "Reset core files" via the Updater to make sure your site will not break.

Understood. Thanks for all your help. I've been using Joomla since 1.5 and perhaps unzipping was a permitted method back then. I was lucky that I got away with it in J3 but my database was probably a mess!

It was allowed / used back than thats right but within modern Joomla version it is not supported and can lead to issues like this

Update: I never found out what was wrong, but I managed to restore the site from a backup, version 4.1.5. Panic over.

I have the same error. I have deleted the file administrator/cache/autoload_psr4.php numerous times and still the same problem.

I have tried to restore a backup from a day before. I STILL HAVE THE ERROR!! even though it is a file and db backup from a day before the update. Isnt't that crazy? It is not only the backend, the website is crashed as well.

Update: I never found out what was wrong, but I managed to restore the site from a backup, version 4.1.5. Panic over.

I have the same error. I have deleted the file administrator/cache/autoload_psr4.php numerous times and still the same problem.

I have tried to restore a backup from a day before. I STILL HAVE THE ERROR!! even though it is a file and db backup from a day before the update. Isnt't that crazy? It is not only the backend, the website is crashed as well.

@carlosdiaz2017 Have you used an empty database to restore the backup, or used Akeeba Kickstart? If not, your database might still contain stuff from after the failed update.

I am also facing the same issue. I just changed the 'administrator/cache' folder permission to 777 its working fine

I am also facing the same issue. I just changed the 'administrator/cache' folder permission to 777 its working fine

@Pream-webapps If you need 777 because 775 does not work for you, then something is wrong with your webserver configuration.

the problem is solved by deleting the administrator/cache/autoload_psr4.php file. THANK YOU

Same Error when i wanted to move my site from my local site wampserver to my host site on debian server.
the problem is solved by deleting the administrator/cache/autoload_psr4.php file
THANK YOU!