![]() ![]() Some of them should never be cached at all. Some elements on the page actually need to be cached separately, on a per-user basis. One cache for every user, just like anonymous users get. Apart from the handful of page components which Authcache can detect and handle out-of-the-box (which we’ll get to in a moment), everything is just being statically cached. This is because all we’ve done so far is enable caching for authenticated users. And once one user creates a node, and it is listed in the “Your posts” quicktab, that node is listed for EVERYONE in the “your posts” quicktab. For starters, that “random post” quickab is serving the same post every time. If you try logging in as yet ANOTHER user, you’ll start to notice some things which are a bit odd. My work here is done! You’re caching content for authenticated users! Customizing content for cached, authenticated users On that reload you’ll see Cache Status “HIT”, and a few helpful statistics about the page’s normal render time (460.17ms for me) vs its cached render time (3.85ms). Visit the frontpage as your test user, and note that it goes yellow (meaning it’s cacheable, but it wasn’t in cache yet), and then green on a reload. Once you’re logged in as a user who SHOULD be seeing cached content, that Debug block will start coming in handy. So in order to test this properly, you’ll have to create another user account to keep open in a separate browser window. If you’re logged in as admin, you’ll notice that it says the page has been excluded of cache, because “Caching disabled for superuser”. This is Authcache Debug: a helpful little block which tells you if the page was delivered from cache, or if an element on there is still preventing the page from being cached. !(/images/authcache-debug.png” width=“300) ![]() We have to go through each element which could be customized to a user, and set an authcache policy on it.Īs we proceed, you will notice a little red button which has appeared in the top left corner of your browser window. Panels with Views and Quicktabs, including several blocks which are unique to each user. The front page of the demo Drupal site you downloaded is a reasonably complicated one. Unlike Anonymous user caching, in order to cache content for authenticated users we actually need to let our caching system know a little bit about the various components of a given page. Now that you’re set up to deliver cached content to authenticated users, we can get to the fun part: configuring. Now comes the first scary bit: disable Drupal’s built in page caching from admin/config/development/performance. Now your site is prepared to deliver cached content to authenticated users. $conf = 'sites/all/modules/authcache/modules/authcache_builtin/authcache_' ![]() Add these two lines to your settings.php to let Drupal know about the Authcache backend: When you enable the modules, you’ll get a message complaining that you don’t have the cache backend configured yet. This is complicated stuff, and the less of it you have to enable, the better! That’s a lot of modules, because znerol has done a great job of compartmentalizing functionality. Install the Authcache module per usual, along with the following other modules: The caching-relevant portion of settings.php in a separate file called.A bunch of other handy modules for generating a faux-frontpage.(Make sure your environment has memcached set up!) Note that this is a rather large site I like to generate 16,000 nodes or so so I can really feel the difference between a cached return and a live one. You can also use this ready-to-go drush archived Drupal site. You can set up your own vanilla D7 site to work with - just create some devel content, an interesting panels-and-views based frontpage, and set up memcached. Set up an environment for Drupal 7 with memcached running. Install Authcacheįirst you will need to set up a local installation to follow along. By the end of this post, we’ll have a frontpage which loads for authenticated users without ever hitting the database. Whenever possible, the placeholders will be filled from browser cache or data stored in memcached. The user’s browser will make a second call to the web server for the content that belongs in those placeholders. We will serve pages out of Drupal’s own page cache, with placeholders for any content which could be customized to the logged in user. Our goal is a simple authenticated user caching system based on Authcache’s AJAX implementation, with a Memcached backend. If you haven’t read it yet, I strongly recommend you check out my last post, Authenticated User Caching Concepts in Drupal 7. We will be using the Authcache suite of modules. This post is a walk through for caching content for authenticated users in Drupal 7. So you have authenticated user traffic you want to cache? Good - you’re on the right post. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |