Tweet
The number of queries that run on every CMS page is still a big issue to many people, and one of the causes is the lack of virtually any template caching.
On an average page (in my test systems) I see anything between 20 and 40 queries run simply to get uncached templates. This amounts to something like 30% on some pages.
So, with the release of 4.1.11, we have added a simple mechanism which should more or less eliminate this entirely. The problem with the CMS is that you cannot do the same thing that has been traditionally done, just cache the templates that will be used, because its actually very difficult to determine (at the point the caching is done) which CMS templates will actually be used.
The quickest and most obvious answer is simply to cache them all - this is the ultimate "Sledgehammer to crack a nut" approach, but will actually work.
The best solution would be some way to know exactly which template will be used, and only cache them - however, this simply isn't possible with the way the CMS works.
Therefore what I have gone for is an in-between system, where we can predict which groups of templates will be needed (i.e. editor templates, widget templates, grid templates, comment based templates) and thus load smaller groups based on this. Its rather like a small hammer to crack the nut, not a sledgehammer, and not a precise nut cracker.
The result is basically that we predict what groups will be needed and load them - this will (and does) mean that we load more templates that are necessary, but in the end, we are trading about 30 extra queries for one extra query, and some php memory. Its far from an ideal or perfect system, but I believe the trade-off is worth it, saving up to 30% of query resources in some cases - which in turn should mean faster rendering pages, and less stressed servers.
When a template is used in code, the view object is used.
$template = new vB_View('templatename');
The template isn't fetched from the DB at this time (until render() or toString() are called).
Further down the line, more view objects are created, again delaying the fetching of their template from the DB.
All the while, each view object should add its template to a static list in the view class, $cache_templates.
When a template finally needs to be rendered (ideally after all view objects needed for the page have been created, in theory this would happen at the end of execution) it will read all templates from the DB that appear in the $cache_templates list and empty the list.
One fetch, fetches all templates for the page, no need to guess which will or will not be used in the page.
I have a feeling this was the original plan for the view controller, but wasn't possible because of legacy code (I'm thinking header, footer, navbar, notifications, etc.).
I thought uncached templates is a main problem in the current VBCMS
and maybe if you go for all, you will figure out more about
how to help improving the CMS in the sense that its' nothing compared with
something like the free wordpress.
anyways, you did extremely great job and I'm happy with the outcomes.
since you joined the development team, more optimized system of vbulletin become