testing this with the same instructions as for testing #37123 and this also fixes the issue

I have tested this item ✅ successfully on 9b1e757

I have tested this item ✅ successfully on 9b1e757

under the same conditions of #37123

I have tested this item ✅ successfully on 434735e

I performed the test instructions on this PR and those in #37122 (where I explained why the approach we see in this here PR would be most preferable). SUCCESS IN BOTH CASES! WOOT!

Thank you so very much @Denitz for writing the code! Here's to hoping this will make it into 4.1.1 :)

@alikon @brianteeman Would either (of both) of you please redo the test here so it can become RTC?

I have tested this item ✅ successfully on 434735e

RTC

Addittionaly, instead of resetting AssetManager, can create temporary instance.

@Fedik This is bad architecture. The web asset registry and manager should be locked in the container (set once). Otherwise any extension can break the entire frontend of the application by messing around with the WAM which completely beats the purpose of having the WAM in the first place...

Okay, I fine with both way, but lock should not be resetable.

@Fedik It has to be if we want caching to work correctly. The other option is overengineering WAM to keep a log of actions (what I had originally proposed in my comments to you). It's far more complicated.

Any other solution would very likely require rethinking WAM but it's way too late for that. The best time to do that would have been around 3 years ago, before the Joomla 4 betas. We're well past that. So we have to work with what we have, even if it's a sad compromise.

Between the two evils, having reset() is the lesser evil. It's something that cannot be refactored out of Joomla without seeing it's used in the caching code which will (or SHOULD) trigger an alert in whoever is refactoring the code, find these issues and find a solution (or leave it alone). Setting a new WAM instance in the container would be refactored out without a second thought (it's such an obvious architectural mistake nobody will think twice) and we'd have a regression.

There is a way to have our pie and eat it too. We can rig the reset() method to only be callable by Cache descendants by using debug_backtrace and making sure one of the callers is a class which is identical to or extends Cache. This would make the method public but inaccessible to unauthorised callers. It should also be marked as @internal in the docblock to note that. This is a trick I am using in my security software after I saw a lot of third party software trying to abuse my .htaccess Maker model to add exceptions for themselves without asking the user.

It has to be if we want caching to work correctly.

I mean you can still use reset() if you like, but if manager is locked then it should not be possible to reset.
Even more, it should throw an exception when someone tries to reset "locked" manager.

Like in useAsset()

The reason I wrote a some comments ago

Any opinions on @Fedik comment?

@bembelimen You can do that, but we'd have to reset all tests and retest yet again. At this point besides me, a party affected by the Joomla caching bug and who has the technical experience to test patches like that, nobody else would test, this would never be fixed and Joomla would forever remain broken (and vulnerable!) when caching is enabled. That would be unacceptable.

Instead, why don't we merge this as-is and @Fedik can make a new PR to add the lock check in reset()? If you ping me I can provide the test for it. Between the three of us and possibly four (if @alikon is still interested in this saga) we can find a second test and merge his PR. This way all of us can have our pie and eat it too. Fair?

I thought about it and (yeah I hear y'all laughing in context of Joomla) we should not try to merge anything which has that obvious an issue we can resolve.

So I set this to an release blocker to show that I really intent to have this in 4.1.1. but only with the fix.

Additionally the following promise: if the fix is there till the 15th of march I will do everything so we get two proper and valid tests and it will be part in 4.1.1.

If after the 15th I still will try to get tests but can't guaranteed anymore.

Deal?

I thought about it and (yeah I hear y'all laughing in context of Joomla) we should not try to merge anything which has that obvious an issue we can resolve.

So I set this to an release blocker to show that I really intent to have this in 4.1.1. but only with the fix.

Additionally the following promise: if the fix is there till the 15th of march I will do everything so we get two proper and valid tests and it will be part in 4.1.1.

If after the 15th I still will try to get tests but can't guaranteed anymore.

Deal?

@Denitz Could you implement the changes suggested here #37139 (comment) ? Thanks in advance.

@richard67 Changes applied.

Back to pending.

@bembelimen Is is ok now?

@brianteeman @alikon @nikosdion Could you test again? Thanks in advance.

I have tested this item ✅ successfully on c5e26ed

I've tested with the test instructions on this PR as well as with those in #37122 .

@brianteeman @alikon @nikosdion One more test needed.

I have tested this item ✅ successfully on c59a414

@brianteeman @alikon @nikosdion Am still begging for a 2nd test.

I have tested this item ✅ successfully on c59a414

RTC

@nikosdion could you please quick check if you're still happy with the PR, then I would merge! Thanks.

I’m happy with this. Please merge. Thank you!

Thank you all!