@swiffer Have you used the Joomla Update Component to upload and update? Or have you uploaded and unpacked the zip manually?

I've used the update component

@nikosdion Is this right here? https://github.com/joomla/joomla-cms/pull/36042/files#diff-14bdb875e42e40282bacd45f20f1b1895c2d2cd786c526d9e8c1d4d91a986b2cR20

Update: Hmm, seems to be all right.

i removed the plugin entry from the #__extensions table and added it again from the current install sql script. now it's working fine again for me.

INSERT INTO `#__extensions` (`package_id`, `name`, `type`, `element`, `folder`, `client_id`, `enabled`, `access`, `protected`, `locked`, `manifest_cache`, `params`, `custom_data`, `ordering`, `state`) VALUES
(0, 'plg_system_cache', 'plugin', 'cache', 'system', 0, 0, 1, 0, 1, '', '{"browsercache":"0","cachetime":"15"}', '', 3, 0)

maybe because of the manifest_cache? can this in general be refreshed ?

The manifest cache of each extension is refreshed with the entries from the XML file at the end of an update.

Looks like the Update didnt completely Run through. Also had a warning regards Out of Date core Database Schema.

@richard67 Yup, it is right, this is the class of the extension plugin object returned.

Looks like the Update didnt completely Run through. Also had a warning regards Out of Date core Database Schema.

@swiffer Have you used the “Fix database structure” button (with the row of the CMS core selected)? If so: Did it help?

Yes, i did that and it helped (for the alert of outdated DB Schema).

And the class not found error was shown after that?

Am asking because when using the fix button, it also refresh the manifest caches of extensions at the end.

And what is shown in the update log "administrator/logs/joomla_update.php"?

No, it was shown directly after the Update and solved by removing the Mainfest Cache Data From #__extensions Table. Afterwards i was able to visit the Admin again and noticed that also DB Schema was outdated. Both together let me assume the Update wasn't completely successfully executed (4.2.0-alpha2 -> 4.2.0-alpha3). Now everything ist fine.

Well if everything is fine and we could be sure that the problem was not caused by a bug in our code, we could say let’s close this issue. But as long as we don’t know what the problem was, we can’t really be sure. What does the update log show?

2022-05-24T18:23:42+00:00 INFO Ip.Ip.Ip.Ip update Neue Version wird jetzt installiert.

Thats all.

Close and reopen If someone Else ist experiencing this as Well?

2022-05-24T18:23:42+00:00 INFO Ip.Ip.Ip.Ip update Neue Version wird jetzt installiert.

Thats all.

That looks indeed incomplete.

Close and reopen If someone Else ist experiencing this as Well?

Not sure yet. I‘d at least like to try to reproduce it, but I‘m off desk at the moment.

oh my... Im going to say that this is probably the same cause as the Joomla 4.2 fiasco ... that the update is not deleting autoload_psr4.php and allowing it to be regenerated.

delete the /administrator/cache/autoload_psr4.php when you get the error message Class "Joomla\Plugin\System\Cache\Extension\Cache" not found and I bet it then magically works

for a 4.2.x to the 4.2.x this #37990 merged in June would have fixed this persons issue reported in May.

However this was the WARNING you needed to prevent the Joomla 4.2 upgrade fiasco we see today

This issue should be closed as it will be fixed by regenerating the namespace map as the changes to Cache by @nikosdion were merged in Alpha3 and so would indeed need a new namespace map to be generated after update, but the code to do that was not added in com_joomlaupdate until after ....