User tests: Successful: Unsuccessful:
Pull Request for Issue # .
I was about to introduce it as a separate plug-in but there is no reason why this could not get into core. This PR make system cache a little bit smarter. Every time user is performing a task (like save, publish, delete, trash etc) plug-in will clear cache so users will get latest page version and administrator will not need to clear it by his own. Login and logout tasks are excluded.
Status | New | ⇒ | Pending |
Labels |
Added:
?
|
The app hasn't been routed yet in the onAfterInitialise event, so relying
on routing data here isn't advisable. Also, if I'm getting the gist of
this right, it will clear the entire cache any time a user performs any
task in the admin but login and logout (so the default display task causes
the cache to clear)? As is this just looks like it's defeating the whole
point of enabling the cache layers.
On Tuesday, April 12, 2016, Artur Stępień notifications@github.com wrote:
Pull Request for Issue # .
Summary of ChangesI was about to introduce it as a separate plug-in but there is no reason
why this could not get into core. This PR make system cache a little bit
smarter. Every time user is performing a task (like save, publish, delete,
trash etc) plug-in will clear cache so users will get latest page version
and administrator will not need to clear it by his own. Login and logout
tasks are excluded.
Testing Instructions
- Enable "System - Cache" plugin
- Go to your front page
- Go to menu "System/Clear cache" there should a an item called page
- Unpublish one of modules
- Go to menu "System/Clear cache" there should be no page item any more
You can view, comment on, or merge this pull request online at:
#9884
Commit Summary
- Clear cache when user is performing an admin task
File Changes
- M plugins/system/cache/cache.php https://github.com/joomla/joomla-cms/pull/9884/files#diff-0 (9)
Patch Links:
- https://github.com/joomla/joomla-cms/pull/9884.patch
- https://github.com/joomla/joomla-cms/pull/9884.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#9884
Category | ⇒ | Cache Plugins |
Labels |
Added:
?
|
Labels |
Removed:
?
|
@mbabker You're wrong. Please check the PR before you write an opinion. This clears only "page" group, leaves anything else untouched. Only tasks that are put into Input (post/get) will trigger cache clear. Display task does not exist in request so will not perform clearing.
Leaving aside the "talking down", IMO this PR is no good as is. Why should
the fact that a user on the admin side has executed the add or edit tasks
cause the page cache to be cleared? For what you're intending to solve it
should only refresh the cache after something changes, so on the save
task. It also should not clear the entire cache but only items relevant to
what's changed.
On Wednesday, April 13, 2016, Artur Stępień notifications@github.com
wrote:
@mbabker https://github.com/mbabker You're wrong. Please check the PR
before you write an opinion. This clears only "page" group, leaves anything
else untouched. Only tasks that are put into Input (post/get) will trigger
cache clear. Display task does not exist in request so will not performclearing.
This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/9884
https://issues.joomla.org/tracker/joomla-cms/9884.—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9884 (comment)
@mbabker Please test the code before you write opinions. First of all tasks like publish, unpublish feature, delete etc does change the page content. So cache should be cleared. There is no performance wise way to perform single item targeted cache clearing. So it is the best way it can be made without omitting custom extensions.
My main point is that not every task on the admin warrants a cache clean.
The fact that I click the edit button should NOT clear the cache. Unless
the fact that I've checked out an item is so important to the page cache
that it must be immediately updated. Also, tasks that aren't even related
to content (a user is created, install or update an extension, duplicate a
template) should not cause the page cache to be wiped out.
And I disagree with the notion that my creating a new article should
completely wipe out the page cache for the entire site.
Lastly, stop talking down to me just because I am challenging your pull
request's validity. I have raised several technical concerns and your only
response is "read the fine code". That's going to get you nowhere with me.
On Wednesday, April 13, 2016, Artur Stępień notifications@github.com
wrote:
@mbabker https://github.com/mbabker Please test the code before you
write opinions. First of all tasks like publish, unpublish feature, delete
etc does change the page content. So cache should be cleared. There is no
performance wise way to perform single item targeted cache clearing. So it
is the best way it can be made without omitting custom extensions.—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9884 (comment)
We can eliminate tasks that should not perform cache clear such as edit, creating user etc. Auto clearing cache is still better then leaving this as it is. If you are about to challenge that PR it would be honest to at least test the PR cause your first comments where far from facts. I have no time for pointless arguing. If you are one of those thinking that making Joomla! user friendly is not important good luck with beating Wordpress.
My stance is that Joomla shouldn't be accepting half baked solutions
because there are more than enough already in core that can't be fixed.
Refreshing cache after content updates is perfectly valid. Refreshing
cache because I click the add, edit, or cancel buttons isn't. Also cache
cleaning should be targeted to what contents are changed, if that isn't
practical then so be it.
As for beating WordPress ain't nobody gonna do it.
On Wednesday, April 13, 2016, Artur Stępień notifications@github.com
wrote:
We can eliminate tasks that should not perform cache clear such as edit,
creating user etc. Auto clearing cache is still better then leaving this as
it is. If you are about to challenge that PR it would be honest to at least
test the PR cause your first comments where far from facts. I have no time
for pointless arguing. If you are one of those thinking that making Joomla!
user friendly is not important good luck with beating Wordpress.—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9884 (comment)
BTW, I don't need to test to be able to point out issues (nor can I test
due to not having reliable internet at home right now). With that said, as
is I'm 99% sure this patch opens a hole for an outside source to easily
destroy a site's cache. A request to
/administrator/index.php?option=com_login&task=clearcache may clear the
frontend page cache and the user doesn't even have to be authenticated.
On Wednesday, April 13, 2016, Artur Stępień notifications@github.com
wrote:
We can eliminate tasks that should not perform cache clear such as edit,
creating user etc. Auto clearing cache is still better then leaving this as
it is. If you are about to challenge that PR it would be honest to at least
test the PR cause your first comments where far from facts. I have no time
for pointless arguing. If you are one of those thinking that making Joomla!
user friendly is not important good luck with beating Wordpress.—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9884 (comment)
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-04-13 13:46:50 |
Closed_By | ⇒ | artur-stepien |
I applied this patch and all I got was Not Found message at the top of every page in the frontend and admin. Nothing in the cache folder
I think it is also a good idea to add info about auto-clear function into plugin description. So every one will not it is not required.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9884.