Jump to content

* * * * *

What can I cache?

IP.Content allows you to cache pre-compiled pages and blocks, either temporarily or until the page or block is edited. While caching pages and blocks can net enormous performance benefits, it is important to understand how caching works, and when you should not use it.

When you cache a block or a page, the entire pre-compiled output is stored in the database and immediately served (assuming the cache is not expired, in which case it is rebuilt and stored for the next request). You should understand the implications of this - the permissions of whoever is viewing the page (or triggered the block to recache) will be used when building it this time, and then the content will be cached. For example, if you have a block using the plugin "Welcome block", it is designed to show a login form to a guest, and information about the logged in user if you are logged in. If a guest visits the page and the block is set to cache, it will store the login form as the cached HTML in the database. When you, as the administrator, visit the page, that cached output will be shown to you, however this is clearly not desired.

Similarly, if pages have HTML logic to show one thing to guests and another thing to users, caching the page will result in all users seeing the same thing.

As a general rule, you should not cache the following:
  • Pages with HTML logic. The logic is executed on display in order to show dynamic output, however if you cache the page, the entire compiled page will be served to everyone based off of who viewed the page when it was last cached.
  • Plugin blocks. Most plugin blocks are dynamic and should show different content to different users.
  • Feed blocks that are designed to show dynamic content to users should not be cached. For instance, a feed block of a user's friends can be useful on a given page, but it will be much less useful if that block is showing someone else's friends (or none at all, if a guest caused the block to recache for instance).
  • You should never cache pages with databases embedded.

Caching pages that have databases embedded should never be done. The page HTML that is generated is cached, and will be served every time the page is requested, even if arguments are passed. This means every time you view the page, the database index is shown, regardless of what link you click. For instance, if you visit the page (and the index is shown, because that was what was stored in the cache), when you click on a link to an article, it will continue to show the database index, because it is serving the cached HTML for that page.

Caching is a powerful tool that can offset resource usage inherent with extremely dynamic software, however you should be careful when considering the implications of caching what should be dynamic, or what might be sensitive, data.
  • Marcher Technologies and Mikey B like this


Ryan Williams
Jan 04 2014 06:54 AM

Is there a way to clear the cache? For example, it'd be pretty useful to be able to cache an intensive block that shows a comment count, but clear it whenever a new comment is posted. Most caching mechanisms have some kind of facility for clearing in such cases.

Developer Docs · Error Codes