Rename "System - Cache" to "System - Browser cache"

[Daniel Dimitrov]

As the title says I'm thinking that it would be less confusing if we call the "System - cache" plugin "System - Browser cache" -> at the end this is what the plugin does.

Right now it give the impression that it is somehow connected to the global cache configuration & not having this plugin enabled would mean that no cache is generated, but that is obviously not the case.

Also something that is very common on the forums and in docs like here:
http://www.inmotionhosting.com/support/edu/joomla-25/caching/global-module-caching

Logged in users and cache Regardless of conservative vs. progressive caching, logged in users do not see cached module content.

I've said this myself in the past, but today I finally realised that I'm wrong. The "System - cache" plugin is really checking if the user is guest or not, but the build in cache mechanism in controllers, documentrenderers etc doesn't care if the user is logged in or not. (unless the developer has built in the logic in his controllers)

So anyway - simple propasal. Let's change the name of "system - cache" to "system - Browser cache". Any objections? I'll do a pull request if there is nobody against this.

[Hannes Papenberg]

Sorry, but that is not correct. The cache plugin does not enable some
browser caching, but it caches the whole page, regardless of any other
setting. This works great for static sites, but is horrible for dynamic
sites. While I agree that the name is misleading, "browser cache" is
equally wrong here. Browser cache to me implies that you can clear the
cache in your browser and the browser will fetch a fresh, updated
version of the page. That is NOT the case. This plugin stores the page
on the sever as a hard copy.

Hannes

Am 16.01.2015 um 21:54 schrieb 'Daniel Dimitrov' via Joomla! CMS
Development:

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cm...@googlegroups.com>.
> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.

[Chris Davenport]

"System - Full page cache" perhaps?

Chris.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--

Chris Davenport
Joomla Production Leadership Team

[brian teeman]

That sounds good to me Chris

[Youjoomla.com]

I think it should be simple as 

System  - Page Cache

"Full" implies that another cache other than "full" might be in existence and 

can create further confusion and unnecessary questions like  " is there half page cache ?" :) 

On Fri, Jan 16, 2015 at 11:21 PM, brian teeman <joom...@googlemail.com> wrote:

That sounds good to me Chris

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--

Best Regards
Dan Casky
Youjoomla Customer Service
1670 Southgate Mill DR NW
Duluth ,GA
30096
-------------------------------
www.youjoomla.com
Professional Joomla Web Design Services

[Chad Windnagle]

Page cache or full page cache is appropriate. 

From my experience 'full page cache' is an actual term in the caching world. Even if it is a tad ambiguous, it aligns closely with other projects' terminology. 

Regards,
Chad Windnagle

To post to this group, send email to joomla-...@googlegroups.com.

[吉田憲人]

Why do we need system-cache plugin if the plugin is not used for dynamic site like Joomla as Hannes says "This works great for static sites, but is horrible for dynamic
sites."?

I myself never turn it on.

Goyat

--

---
吉田憲人　Goyat LLC
Call 080-5178-9927

[Hannes Papenberg]

This was meant that it works great for static sites like for example a
company website done with Joomla that is completely static and does not
have stuff like a chat or random images etc. on it. You have a lot of
sites where you basically have static content and nothing else. Those
are still made with Joomla, since it is easier to manage, but the
content nonetheless is 100% static. In those cases the cache plugin is
okay.

Hannes

Am 17.01.2015 um 07:59 schrieb 吉田憲人 :
> Why do we need system-cache plugin if the plugin is not used for
> dynamic site like Joomla as Hannes says "This works great for static
> sites, but is horrible for dynamic
> sites."?
>
> I myself never turn it on.
>
> Goyat
>
> 2015-01-17 13:25 GMT+09:00 Chad Windnagle <drmm...@gmail.com

> <mailto:drmm...@gmail.com>>:

>
> Page cache or full page cache is appropriate.
>

> From my experience 'full page cache' is an actual /term/ in the

> caching world. Even if it is a tad ambiguous, it aligns closely
> with other projects' terminology.
>
> Regards,
> Chad Windnagle
>
> On Fri, Jan 16, 2015 at 5:43 PM, Youjoomla.com
> <youjoo...@gmail.com <mailto:youjoo...@gmail.com>> wrote:
>
> I think it should be simple as
> System - Page Cache
>
> "Full" implies that another cache other than "full" might be
> in existence and
> can create further confusion and unnecessary questions like "
> is there half page cache ?" :)
>
>
> On Fri, Jan 16, 2015 at 11:21 PM, brian teeman
> <joom...@googlemail.com <mailto:joom...@googlemail.com>> wrote:
>
> That sounds good to me Chris
>
> --
> You received this message because you are subscribed to
> the Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to
> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> Visit this group at
> http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Best Regards
> Dan Casky
> Youjoomla Customer Service
> 1670 Southgate Mill DR NW
> Duluth ,GA
> 30096
> -------------------------------

> www.youjoomla.com <http://www.youjoomla.com>

> Professional Joomla Web Design Services
> --
> You received this message because you are subscribed to the
> Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to
> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cm...@googlegroups.com>.

> To post to this group, send email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

>
> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cm...@googlegroups.com>.

> To post to this group, send email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> ---
> 吉田憲人　Goyat LLC
> Call 080-5178-9927

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cm...@googlegroups.com>.

> To post to this group, send email to joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

[Troy]

Can we get a better definition ( in the docs ) of what conservative vs progressive even means / does while your at it?  Thats always been vague to me.

Bear

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5645 / Virus Database: 4260/8940 - Release Date: 01/16/15

[klas berlič]

While conservative turns on global caching flag and component view caching, progressive mode also caches module rendering

Turned on here
https://github.com/joomla/joomla-cms/blob/staging/libraries/legacy/application/application.php#L304

and finnaly executed in
https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/document/html/html.php#L382

Regards,
Klas

[Troy]

ty klas.. very very misleading names.

Bear

Version: 2015.0.5645 / Virus Database: 4260/8946 - Release Date: 01/17/15

[Johan Janssens]

About System - Cache

System - Cache implies that this caching mechanism is implemented system wide. Hence why it's a system plugin. The name could be optimised a bit to System - Page Cache to make more clear what it does. A plugin does have a description specifically for this though. 

The system cache was originally design to be evolved into a browser cache solution that could send back 304 responses acting on modified since or etag headers. Early development version of the plugin actually did that but it was removed as we dodn't have the time properly finish it. 

About naming

Whatever you name it, it will never be 100% clear to an administrator. We see more sites that have caching off then have it on because administrators don't know how it works and the default setting is off by default when the site is installed. To understand how caching works you need intimate knowledge of Joomla, on top of that different extensions also cache in different ways etc.

The only real way to resolve this problem is to completely remove the cache settings and make caching a first level citizen of the architecture. Technically it's perfectly possible to determine if something can be cached and automatically purge the cache with a change is made.

At Joomlatools we use this technique. We do not adhere to the Joomla cache settings. We always cache, and we clean the cache dynamically when a change is made. 

Hope that can offer some inspiration.

Johan

[Troy]

+1 lovely :D

Bear

[klas berlič]

Not adhering to the global settings can mean you are either duplicating higher caching levels or interfeering with the users intent - if caching is OFF globally it should be also off in your extension (not so for ON - it depends on extension developer to implement it or not or how to implement it). 

Also,there are different caching layers and techniques and not all can be done in this way (without extensive changes to the architecture e.g. caching of system functions) and there are higher levels of cache than cover more that single extension - mentioned page/system cache is an example. Another example is module rendering cache, where process starts by parsing of template jdoc includes for modules (which is a very resource demanding process), without any observers to notify the system about the change. Speaking about this - parsing template for jdocs each time page is viewed is a horrible way to do templating in the light of performance.
 
But general - caching is meant to be used on sites with a lot of visitors, such sites should also have a knowledgable site admin that will learn about caching options. Default setting off is targeted at usuall John Smiths that receive 5 hits per day on their site and since don't need caching at their site.

Some time ago I wrote an article about Joomla caching basics, which as far as I'm aware still holds true http://www.bzzzz.biz/blog/joomla/joomla-1.6-caching-demystified-jennifer-series.bzzzz

Klas

P.S. and for the original topic of this thread: +1 for System - Page cache

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

[brian teeman]

I did a quick PR to change the name to System - Page Cache

https://github.com/joomla/joomla-cms/pull/5831

[Johan Janssens]

Klas,

Don't want to take this thread off topic, but I don't agree you your remarks that if caching is off it should be off in the extension too nor do I agree that caching is only for sites that receive a high amount of traffic and require a knowledgeable site administrator. This is exactly one of the pain points of Joomla to date, complexity is being pushed to the administrator, instead of solving it in the core. 

I will give you four examples how we optimise our extensions using various caching techniques transparently and dynamically that benefit all our users, on small or big sites without them knowing about it or needing to know about it :

1. We use a template engine in our extensions, our templates are compiled to PHP code and then cached on the file system. Our template engine is smart enough to know that when the original template file has changed the file needs to be recompiled and the result re-cached. 

The template system cache doesn't adhere to the Joomla cache settings, simply because in most if not all cases the template need to be compiled only ones. If it get's change, because the extension is updated the cache is updated too. 

As a sidenote : The template system we have build solves the view cache problems as you outlined in your blog post the point about "module & component view cache". We do dynamically invalidate the cache and we have solved the problems with injecting data into the page head without the need for workarounds. 

2. We use a more advanced database layer that inspects the database schema on the fly. It does this by executing SHOW queries to get the schema info from the database. The results of these queries are cached so they only need to be run once. Only when the database schema changes, aka because of an update the cache is cleared on the fly. 

3. We use a filesystem cache to speed up the rendering of files and folders in our extensions. We parse the file system and cache the result as JSON, we do this per folder. This way we do not need to perform very costly operations on the file system each time. The cache is refreshed automatically when new folder or file is added. This benefits greatly our administrator file management functionality in our extensions, which our users appreciate a lot. 

4. We serve our assets (image, css, js files) in such a way that they can be cached fully by the browser. When we release an updated version of our extensions, the URL's of our assets are rewritten by a template filter to include a unique hash and thus are re-cached in the browser. This makes sure that our users are always using the latest version of js and css files. 

Especially since some of our extensions make heavy use of js this is important. Older cached js files can sometimes result in unwanted errors. If we wouldn't dynamically and transparently deal with this, we would need to instruct our users to manually clean their browser cache after an extension upgrade. This is labour intensive and results to unneeded support overhead.

In all 4 examples the caching happens transparently from the user, and the cache is refreshed dynamically based on system behaviour. Cache rules and cache invalidation rules are part of the system and are not left up to the user to understand nor configure. 

The result are less settings, and a less complex but more responsive user interface which is what we aim to achieve.

Hope that helps.

Johan

On Tuesday, January 20, 2015 at 11:00:44 AM UTC+1, klas b wrote:

Not adhering to the global settings can mean you are either duplicating higher caching levels or interfeering with the users intent - if caching is OFF globally it should be also off in your extension (not so for ON - it depends on extension developer to implement it or not or how to implement it). 

Also,there are different caching layers and techniques and not all can be done in this way (without extensive changes to the architecture e.g. caching of system functions) and there are higher levels of cache than cover more that single extension - mentioned page/system cache is an example. Another example is module rendering cache, where process starts by parsing of template jdoc includes for modules (which is a very resource demanding process), without any observers to notify the system about the change. Speaking about this - parsing template for jdocs each time page is viewed is a horrible way to do templating in the light of performance.
 
But general - caching is meant to be used on sites with a lot of visitors, such sites should also have a knowledgable site admin that will learn about caching options. Default setting off is targeted at usuall John Smiths that receive 5 hits per day on their site and since don't need caching at their site.

Some time ago I wrote an article about Joomla caching basics, which as far as I'm aware still holds true http://www.bzzzz.biz/blog/joomla/joomla-1.6-caching-demystified-jennifer-series.bzzzz

Klas

P.S. and for the original topic of this thread: +1 for System - Page cache

2015-01-19 17:46 GMT+01:00 Troy <tr...@hallhome.us>:

+1 lovely :D

Bear
On 1/18/2015 11:53, Johan Janssens wrote:

At Joomlatools we use this technique. We do not adhere to the Joomla cache settings. We always cache, and we clean the cache dynamically when a change is made.

Hope that can offer some inspiration.

Johan

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

[Nathan Hawks]

"without them knowing about it or needing to know about it"

In my opinion, those users should use Wordpress, or something else soft with no sharp corners and no actual control. If someone wants to live their whole life with mittens on that's their problem; let's not put the rest of the users, effectively, in a straightjacket.

That said:

1. Sounds like Smarty, which is a good system. I wonder, however, at what point templates become too complex for a designer with no PHP skills. I think Smarty-like syntax, is a step too far for those people.

2. Anything that reduces redundant database traffic would be lovely IMO, but depending on use cases, wouldn't this be, for higher-traffic sites, just another query in the pipe for every page hit? Just asking.

3. Neat - faster and less wear and tear on the disk. However, I presume your rescan only occurs if a new file/folder is added via the UI; shells still exist. The fact that Joomla is used by many power users who can do things a billion times faster by typing, means shells see a fair bit of action.

4. It sounds like you've reinvented ModPageSpeed and ModHeaders.

In other words it seems like some of these suggestions have very narrow compatibility with use cases. How many power users does Joomla want to lose, in its quest to beat Wordpress at the pander-to-derps game?

[Johan Janssens]

Hi Nathan, 

Thanks for the reply.  Control and power are very subjective things. Us humans believe that because something has more settings and features we have more control over it, but is that really true ?

Many moons ago Mambo's tag phrase was power in simplicity. This is what attracted me to Mambo and made me help co-found Joomla, my goal has always been to create a powerful yet simple solution. 

1. Smarty served us well years ago, today it's resting in peace. We all agree that  PHP is a great template syntax, it's how PHP 2.0 was born. What we do is augment the PHP language by making use of the PHP's own tokenizer.  As a result you get a more brief and simple to understand PHP syntax in the templates. Less PHP and more html, which makes it easier to understand what the template does. 

Additionaly the engine has out of the box support for other template syntaxes, like Markdown, Mustache etc  It allows to use these syntaxes interchangeably in the same template. On top of that it provides additional html tags that are namespaced as <ktml>. This makes the engine future compatible with html5 which allows to define custom tags, through the web components spec. Right now these tags are parsed to native html4 to maintain compatibility. 

A nice example of the syntax you can find here : http://developer.joomlatools.com/framework/template-system.html In this template example we are making use of Functions,Helpers, Special Tags and Partials. Our components use all of these to keep our templates compact, segmented and thus reusable.

2. The query is only performed once, and then cached, that means in the lifecycle of the site (assuming the db schema is not updated) this query is run only once. 

Database queries are especially for high traffic sites a problem. They can introduce significant overhead. Reducing queries to a minimum is key. The less queries the easier also to spread database load in case of multiple slave setup. 

3. Actually our data shows the opposite, only 1% of our users installations have setups with CLI and shell support. Very few of those users know how to use this. We see this also as our specific CLI tools for Joomla gain only low traction. 

4. We do use mod_pagespeed for all our installations, and are big fans of it. Our demo site uses it and it's installed by default in our Joomla Vagrant box too : http://developer.joomlatools.com/tools/vagrant/introduction.html Works great. Problem being that I haven't encountered any Joomla hosts yet who support this. So we cannot rely on it. 

This is not a quest to beat Wordpress. Joomla from it's Mambo roots was years ahead of Wordpress in terms of both power and simplicity. Nor is this about power users. Joomla has never been focussed on being a system for power users and it still isn't.  

This is about the responsibility any developer bears to design good software. 

Any intelligent fool can make things bigger and more complex ... it takes a touch of genius to and a lot of courage to move in the opposite direction. - Albert Einstein

 Johan

[Nathan Hawks]

Many people capable of disabling usage reporting, certainly will do so -- meaning your usage data is skewed towards the less avid. ;)

I am in favor of cases where control fidelity can be improved by turning options into usage profiles, but I see the matter thusly - a beach full of sand is automatically a more flexible creation tool, than a pile of Legos. You simply can't control the shape of the Legos once they are molded. Anyone whose use case required greater granularity, gets cast aside, when that granularity isn't valued by developers. Loyal Joomla users are accustomed to granularity. This is my broken record, but I will spin it again: please implement these things with respect for those users who might think things are objectively better (sometimes in part due to costly investment into the status quo, in addition to cases where they've simply found advantages in the granularity) with granular control in place.

When you go from exposing a behavior-controlling variable for direct control, to obscuring or blocking direct control of it, you reduce functionality for the users with the most investment in your platform (otherwise they wouldn't be so dependent on those options) and simultaneously the most mobility to change platforms (by virtue of being savvy).

I presume the schema cache would be automatically deleted and refreshed each time Joomla or an extension was updated?

Still, it takes me only a couple seconds, to imagine use cases that give me pause here:

1. A site with a dedicated web staff charged with regularly introducing new features via a CCK - would this not be at odds with the schema cache?

2. Usage of Joomla as an application platform for programmers who might need to dynamically alter schemas for reasons you can't foresee.

Perhaps you already meant, to only apply these caches to tables which should never be modified except during a Joomla Update; in which case I just wasted a lot of knuckle juice. 

On the question of whether Joomla remains compatible for power users... if it takes me longer to do my clients' jobs, then it gets more expensive for those people to run sites based on Joomla. I definitely do not suspect your data is at all valid in the question of shell availability, per my opening sentence. Besides which, FTP counts as a shell, for this purpose; an alternative file manager app (including the file manager every hosting account comes with), counts as a shell, for this discussion; etc. An independent, dynamic script juggling content for whatever reason, also makes this asset caching scheme, a problem. I see a lot of major use case oversights on this item; I guess I'm just saying the behavior should be optional.

My other comments were not really concerns; telling users to learn how to deal with Apache modules if they want better performance, is a disservice, to many of them. I would hate to see design work become accessible to fewer designers, making prices for templates increase due both to additional training and the accompanying narrower field of providers - creep of features being reflected in new template syntax artifacts should be kept in check if avoidable - but some such creep is inevitable. 

Thanks for your time considering my concerns.

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/FPYu4XJ8CVc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[klas berlič]

Hi Johan,

 I was talking about things withing the constraints of current Joomla architecture. I certainly agree that in the next versions we should do this differently to minimize or even erradicate the need for end user intervention. But even in the future the global setting needs to kept for power users as you cannot forsee all the usage cases or the need for finer granularity as mentoned by Nathan. Related to this - we could gennerally simplify the interface by showing just basic options needed by everyone, then have a config file with all other power options like this one, for those that know what they are doing.

Just a comment on the 3 - this is effective when you are using harddisk based filesystem, but would slow down memory based caches (also doubt about the effect on SSD based filesystems where reads are much less expensive)

Regards,

Klas

To post to this group, send email to joomla-...@googlegroups.com.