User tests: Successful: Unsuccessful:
Issue:
When caching is enabled, changes to administrator modules require manually clearing cache before the change is applied.
Underlying Cause:
The /administrator/components/com_modules/models/module.php file uses an overridden cleanCache function which tries to guess whether the front-end or admin com_modules cache should be cleaned. That function calls $this->getClient() which uses a private variable ($_clientId) which is never set. Therefore, the local cleanCache always clears the front-end module cache even if an administrator module is being edited.
Fix:
Remove the erroneous and otherwise unused getClient function
Update the cleanCache function to always clear the front-end and administrator com_modules cache.
Possible improvements:
Since the front-end modules are primarily what users edit, this adds a little overhead to clear admin modules everytime. However, it should have no impact on the site overall. The code could be implemented to properly determine the module type being edited and only clear that cache, but I wanted this change to be as surgical as possible.
Testing:
Enable caching in the Global Configuration - I was using File / Conservative, but I believe any caching will exhibit this problem
Edit an admin module - Title, published state or any setting
The changes should be immediately visible
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_modules |
Labels |
Added:
?
|
1st of all thank you for your 1st pr
i would like to clean the cache selectively i.e if i'm updating an admin module then only the admin module cache should be cleaned and viceversa
1st of all thank you for your 1st pr
i would like to clean the cache selectively i.e if i'm updating an admin module then only the admin module cache should be cleaned and viceversa
I agree that would be 'better'. The reasons I didn't is because it's more difficult to get that right and test. For editing/saving one module, it's not terribly troublesome since we can ask "Are you an admin or front-end module" and simply clear that.
When you add in batch copying/moving or group publishing, then we need to loop over each module and set a flag for if any were front-end or admin. Definitely do-able, but I don't have the time to implement that and test right now, so I put this in.
The current method is 100% broken though and goes back to how this file was updated in 2011.. so this is an improvement :)
As noted above:
Let me know. If this can't be integrated as-is, I can gladly investigate the improvements, but I don't know when they'd be implemented.
I tried PR with Joooml!'s default modules 3.9.21.
I don't find any problem in changing the features of the modules with active cache.
The cache is not full, I have enabled it for this PR.
I tried PR with Joooml!'s default modules 3.9.21.
I don't find any problem in changing the features of the modules with active cache.
The cache is not full, I have enabled it for this PR.This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30565.
Thanks for testing! I'm glad to hear this PR worked for you.
Every time you do this (which makes no sense to me anyway) hundreds of people get notifications and that's annoying. So please stop it and if you don't want to contribute any longer I sorry for this but can't change it.
So please don't flood us with unneeded notifications.
Labels |
Added:
?
Removed: ? |
@sourcecoast I'm sorry that it took that long to come back to this but I will take this here into 3.10.11 (after drone passes) so after a few days more than usually (:D) that issue is finally fixed. Thanks
I have put more thourth into this and decided to not merge this change into the very last 3.10 release and will limit it to the absolute required changes nessesarry.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-08-03 18:44:10 |
Closed_By | ⇒ | zero-24 |
Issue #30492