Thread Starter
Arash
(@john25)
Also noticed that the following code only works once.
<?php if(wp_cacheblock_start('my-content')) : ?>
//the content you want to cache
<?php endif; wp_cacheblock_end(); ?>
So if there are different blocks you want to cache, like header, footer and parts of sidebar. Then that does not work. You get the same data in all 3.
Hi John,
1. What object cache implementation are you using? WP Cache Block doesn’t store any data in a /tmp file. It uses WordPress’ built in caching to store the output of the section. If this isn’t getting cleared, it is the caching plugin you are using.
2. You can set the cache time out per section. The second parameter of the wp_cacheblock_start() function takes an array of settings. So if you need the cache to be for 30 seconds instead of the default 5 minutes use:
`wp_cache_block_start(‘my-content’, array(‘expires’=>30))
3. See #2
4. See #1
5. The code is only working once because you are using the same blockname for each block. The first parameter of the wp_cacheblock_start() function should be unique per piece of content. So instead of using ‘my-content’, change it to something more descriptive like ‘left-sidebar’.
Thread Starter
Arash
(@john25)
Thank you I am going to try that.
I have applied this to some simple rotating javascript banner, and I would like to apply it to other php files. Do I use the same descriptor (my-content etc) if it is the exact same code, but just in a different location (php file)?
thanks!
Only use the same block-name if you want the same cached output for the other blocks where you call the same code.
Do the cached blocks get automatically re-freshed upon a new post being published? What are the triggers that force a refresh on the cached blocks?
No, since the block you may be caching might have nothing to do with posts, the cacheblocks timeout at 5 minute increments by default. If you need to clear the cache after a post is saved, you could add a hook to ‘save_post’ that will call back to WP_Cache_Block::GetInstance()->clear_cache();
ok, so we could basically cache our main page also which basically shows an image and excerpt for the last 20 or so posts, and add a hook to clear the cache upon a ‘save_post’ ?
Would that be what you would recommend?
prettyboymp:
I successfully added a hook to clear the cache in the event of a new post. As such, wouldn’t it make sense to lengthen the expiration period of the cache blocks?
Is there any reason not to extend it to 20 minutes or so? Would it help performance?
I’m not caching comments so its all static content except when a new post is created which is taken care of by the hook.
Truthfully, if you’re clearing the cache when you save a new post and there is no other source of new content on the homepage that would need to otherwise be refreshed, you could set the expire argument to 0. This would keep it from ever clearing from cache except when you save a post.
i wonder that where the cached bloks are stored? To the disk or memory(ram)?
prettyboymp:
Does the plugin use the wordpress options table to store data? Does it use records such as _transient_XXXXXXXXX?
My wordpress options table has gotten extremely bloated and I’m trying to clean it out and am trying to find where the records came from.
Let me know if you have any feedback. Thanks so much.
kduffy:
The plugin uses WordPress’ transient api, which is the built in caching wrapper for WordPress. If you’re not running a separate object cache, then yes, these items get stored in the options table with option names of _transient_xxxxxx.
Ok thanks.
I think you should know that as a result, I’ve got 250,000 records in my options table now all with that transient prefix and it has killed my CPU usage b/c the options table gets read in by wordpress w/ each page view.
Is this an error w/ the plugin or did I set it up wrong?
Is there an easy way to delete these records with the plugin or do i need to do it manually in the database?
