If you can supply a pagecache plugin for testing it will really speed things along.

This PR introduces a new plugin group pagecache which is used by the System - Cache plugin

Do you mean a new plugin pagecache "Folder"?
So the plugins inside that pagecache "Folder" will only run when plugin system cache is enabled?

@andrepereiradasilva I actually do mean "group" but, yes, plugins in that group will be have their own folder just as every plugin group has its own folder. You have the right idea.

@brianteeman Yes, I should certainly do so.

Imho, this gets a bit overly complex for a cache plugin of 3k size.
If you need a different key, why not just copy the plugin and adjust it?
You can even put an extended cache plugin on JED so others can use it.

Sounds like a better approach to me.

I agree that this is not the solution I'd like to see; for example there's an event call from the constructor, which basically makes it impossible to have for example a system plugin with the event.

I'm happy that Joomla 3.5 has finally added option to disable page cache by menu item, but what I'd like to see is to add event to disable page cache from a component (or even from module and plugin).

Here is a test plugin:
https://github.com/okonomiyaki3000/plg_pagecache_test

This plugin is rather pointless except to illustrate how such plugins may work. It generates a random integer between 1 and 3 to be used as part of the cache key. As a result, each page, if loaded a few times, will eventually have up to three separate cache entries. So, to test this:

1. install the test plugin
2. activate the System - Cache plugin and the PageCache - Test plugins
3. clear your page cache (/cache/page/ should be empty)
4. load a page (/cache/page/ should have one cached file in it)
5. reload the same page a few times (/cache/page/ will surely have 2 or 3 cached files in it)

This is just a dumb example. As I mentioned above, there are better uses for such a thing.

@mahagr - Being able to control when to actually cache at all is another useful feature that this plugin group could have. We'd need a different event, maybe something like onPageCacheCacheable or something. Then you'd simply have a plugin with such a function that returns false when specific components are in use. That would be sufficient to tell System - Cache to skip caching of the current page.

Thanks for doing that

This change is mainly in response to @mahagr's comment.

First of all, it removes the event call from the constructor and does it at a later time. So, yes, you should now be able to put these events in system plugins as well.

Second, it introduces two new events which give more control over which pages get cached an under what circumstances those caches are used. These may seem a little redundant but they really just extend the way the plugin works now and it sort of makes sense.

onPageCacheIsExcluded helps to determine if a particular page should be excluded from caching. This is the event you'd use if you wanted add functionality similar to the built-in exclude_menu_items option. You could, for example, check if the current component is on a list of excluded components and, if so, return true.

onPageCacheSetCaching helps to determine whether an existing cache should be used. As it is now, an existing cache will only be used if the user is a guest and the request method is GET. These rules are still in effect but now in addition, if a plugin returns false this event, the cache will not be used.

? I quickly checked the code and it looked good.

Looks good to me, I would just change:

app->input->getMethod() == 'GET'

to

app->input->getMethod() === 'GET'

for a more strict check.

@tonypartridge You're right. I don't think it would ever make the slightest difference here but it was using strict comparison in the previous version so it should not be changed.

@mahagr @tonypartridge "looks good" mean i can alter it as successfully Tests?

I just did code review, didn't test the change. But yeah, it looks good to me.

@brianteeman code review isn't enough for successfully test?

It hasn't been enough before.

Anything I can do to help with testing?

I have tested this item ✅ successfully on 8aeec80

Without the patch, the supplied plugin created a single cached file on pageload and no additional files on refresh.
With patch files were added as stated.

@N6REJ Thanks! I'm glad to see this is moving along.

I have tested this item ✅ successfully on 8aeec80

Before applying the patch, the plugin only created one cache file regardless of page loads. After the patch was applied and the page was reloaded several times, there were 3 cache files. https://www.screencast.com/t/wQ51uXWi

RTC after two successful tests.

Rebased to fix conflicts

Done code review and tested
Code looks good and it is working, and this PR is useful
but i have a question

we always call

$results = JEventDispatcher::getInstance()->trigger('onPageCacheSetCaching');

but if user is not guest or if method is not GET
https://github.com/okonomiyaki3000/joomla-cms/blob/5ea3e05b813e282ef4c7f56f82f8a0d7995e8173/plugins/system/cache/cache.php#L120-L123

then the $results will not be used

is it because we expect that the plugins having this method will also do "other", extra work besides saying if caching should done ?

I have tested this item ✅ successfully on 5ea3e05

@ggppdk The point you're referring to is not new in this PR.

We only use the cache when the user is a guest because other user types may see content that is specifically meant for them. Guests only see content that is meant for all guests. Basically, we would not like to cache a page with a message that says "Welcome back, Georgios!" and then show it to everyone. Also, we may be sending private information to the user over a secure connection. If that's the case, we should not also store that information in an unencrypted file on the server. We should not store it at all so we don't.

The reason only GET requests are cached is that (until now and still typically) the cache key is just the url of the page. If the request is GET, the content of the page should be based on the url so such a key is probably safe. If the request is POST or some other, the content of the page may be based on data that was passed to the server in the body of the request and not just the url. So we can't trust that cached content based only on the url is correct.

This PR adds the ability to use other criteria to decide not to use the cache. It does not allow you to use cache in these special cases. They are always off-limits for caching. However, an improvement to this plugin might be to take those special cases out and implement them as pagecache plugins. This would allow them to be switched off (unwise) or have their own special configurations (like what?) or be replaced by 3rd party or custom plugins that might handle these situations with some kind of specific logic.

Does that make sense?

@ggppdk Ah wait... I think you were asking something very different. You mean that maybe we shouldn't check the cache plugins at all until after we check the basic caching criteria. Well, this is a good point. Honestly, since it was a while ago that I wrote this, I can't remember exactly what was going through my head. It might have been zero or more of the following:

1. Allow the plugins to do things other caching (unwise)
2. Add these new features with minimal modification of existing code
3. Make it simple to cut the existing criteria out and move it to plugins
4. I was drunk

I have tested this item ✅ successfully on 15d22f9

I have a question. I am not sure if I can post it here or not though. I have some pages where a module is loaded. But this module should never be cached. Whenever I have used different kinds of caching options, the page did not work correctly (I mean the module) With this new plugin, is it possible to disable the caching for spacific pages? Or specific pages that use a specific module? (The module is loaded within the content as loadposition)

Kind regards.

Why not just set caching to disabled in the module? Under its advanced tab?

--
Tony Partridge

On 22 September 2017 at 08:07:13, hakanara (notifications@github.com) wrote:

I have a question. I am not sure if I can post it here or not though. I
have some pages where a module is loaded. But this module should never be
cached. Whenever I have used different kinds of caching options, the page
did not work correctly (I mean the module) With this new plugin, is it
possible to disable the caching for spacific pages? Or specific pages that
use a specific module? (The module is loaded within the content as
loadposition)

Kind regards.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10551 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVglpkLVbwjlfWjMLlrKqzSYry5XSxfks5sk1yhgaJpZM4Ih3vD
.

@hakanara Yes. If you want to do this, just create a plugin in the pagecache group. Something like plg_pagecache_modfilter or whatever. Your plugin only needs one function: onPageCacheSetCaching which should check if the module in question is enabled on the page (JModuleHelper has functions that can tell you this). Then simply return false if the module is on the page or true if it isn't.

@tonypartridge That disables caching the module's code but does it disable pagecache?

@tonypartridge , I don't know why it does not work that way but the module on the page does not function correctly if I disable caching from the advanced tab of the module settings.

@hakanara

This PR is about making page caching more flexible
only if you would create a new plugin of plugin group 'pagecache'
only then maybe you could be posting in this PR

If you have enable page caching (joomla system plugin)

• then disabling cache in advanced TAB will not solve anything !

The above is because the full HTML of the page is cached !

In your case you are better off disabling the cache plugin and instead

• use Joomla 's View caching and Module caching (enable conservative / progressive caching in global configuration)
• then disabling caching from the advanced tab of the module settings, will have an effect

For more i think this is a good article
https://www.joomlart.com/tutorials/joomla-tutorials/joomla-cache-from-inside-out

you can search internet / joomla docs for more information
you can post at Joomla forums

your question is a usage question , not appropriate for posting here