What templates are blank exactly Jim_O? (You put 'xxxxx' in your post).

In either case, the php error is caused by the xcache script because it didn't anticpate for blank variables, you could probably edit the script and change htmlspecialchars to @htmlspecialchars on line 4.

1.2.0 working like a dream on 3.7.4 with xcache

There are probably 200-300 of them. Here are a sampling:

• vbactivecache_template_12598
• vbactivecache_template_12882
• vbactivecache_template_3675
• vbactivecache_template_12523
• vbactivecache_template_12527
• vbactivecache_template_12815
• vbactivecache_template_12819
• vbactivecache_template_12747
• vbactivecache_template_12679
• vbactivecache_template_12895
• vbactivecache_template_13045
• vbactivecache_template_12820
• vbactivecache_template_12824
• vbactivecache_template_8110

Pretty much anything that starts with "vbactivecache_template_" is empty.

When there is what appears to be an intentionally blank cache, such as "vbactivecache_phrase_calformat2override_1" it shows the following data:

"{_______VB_ACTIVE_CACHE_BLANK_______}"

These others are simply blank.

Many have multiple hits and "sizes" as large as 15K.

FWIW, if you are interested in system info, I am using XCache 1.2.2 which I compiled from source and run php 5.2.8 as a fastcgi using php-fpm as a controller, also compiled from source. The web server is nginx 0.7.27. No other scripts are accessing XCache and the system seems to be running fine although volume is very light at this moment with people out Christmas shopping or whatever else that they might be doing this time of year.


That eliminates the warning but not the hundreds of blank caches.

Jim_O - Where you see the numbers, run this query:
[sql]select * from template where templateid = xxx[/sql]

You'll probably need to put your table prefix before "template". My guess is you've uninstalled templates, but mods are still trying to run them. But if I'm wrong let me know the result of your query, and if the template in your database actually has any information.

Nope. Those queries return lots of data.

For instance:


select * from vb_template where templateid = 8110:


select * from vb_template where templateid = 13045


So these are some fairly standard templates it would seem.

I do have styles that are unavailable for users to select, but enabling them, flushing the cache and looking again made no difference on the empties. Like I said, all template caches appear to be empty. :confused:

For some reason the template content isn't being cached. If you turn on vB debug mode, does vB optimise tell you it's fetched templates from cache, or that it needs to query them to cache?

If unsure where vB Optimise messages are, it's the bottom drop down menu on your pages after enabling debug mode, which can be done like so by adding this in config.php:

It says that it got 86 templates from the cache and 0 fetched from the database so it seems to be working.

Maybe it's best I ignore what XCache is telling me (?), though it seems odd, and it only appears with this product.

Another suggestion Deceptor

vblog could probably do with one of your great optimizations ^^

When vB Optimise is active, when clicking the save button after editing a post, the revised data is saved into the database, but the screen is left at the editor mode instead of refreshing into a normal post display.

shlomot I tried quick and advance edit in 3.7.4 and the edit box went away and the post was updated correcty