I've got a fair amount of Drupal knowledge (5+ years) but I'm struggling to get my head around which parts of authcache is needed in my use case. I was hoping that someone could shed some light on it to make it easier for myself and others who might be experiencing similar difficulties.

Some background
The site is Drupal Commerce-based (thus, Authcache is very useful!). So far, I've gotten Authcache to work using the following modules:

  • Authcache
  • Authcache Builtin Storage
  • Authcache Form
  • Authcache personalization API

The site is fairly basic. The only user-unique elements are the shopping cart and a couple of menu links available for authenticated users.

I've solved the shopping cart by using the Commerce Ajax Cart module. It provides a JS function that i've called on each pageload, which triggers an ajax request that updates the cart to that of the current user's. It works very well.

I'm currently looking at solving the user-menu links by creating a custom module that utilizes hook_authcache_cookie() so that I can provide a cookie containing the users's UID which I'll use to alter the client-side markup to direct the links to their proper urls (the links all need the UID). I'm halfway there, so I think I've solved my two problems.

But. What I can't really understand, and that I was hoping that someone could clarify is this:

1. I noticed that I needed both Authcache Form and Authcache p13n for the caching to work for anonymous users. I have no idea why. I've glanced through the code from those modules, and from what I can tell, I'm not really using any of the functions they provide, but obviously I might be dead wrong.

2. I've tried most of the Authcache modules (menu, views, ajax, block) etc, but none of them seem to really do anything by default. I tried activating ajax / esi in the settings for a couple of blocks thinking that they would automatically load via Ajax if I did so - but they didn't. I also can't find any information as to what they actually provide. What exactly is an Ajax / ESI -enabled view? Will that alter its markup? Will the content load via Ajax?

3. I've understood that I probably should be using the form+ajax modules in order to personalize the form tokens, but activating the modules doesn't seem to do anything, and I found the settings difficult to understand. I'm guessing that form tokens will be replaced via JS (either via Cookie or Ajax request?) but they aren't. The ajax module's JS file isn't being loaded in head either from what I can tell.

I've read the documentation and found some useful readme files and examples in the modules and here on d.org, but nothing really explains what the extra modules do except that the descriptions read "Authcache support for the module".

Please lend me (and possible others with the same questions) a hand and see if we can't make Authcache easier to grasp by answering the questions above.

Comments

AdamGerthel’s picture

Issue summary: View changes
znerol’s picture

I guess you are aware of the Commerce Kickstart + Authcache tuorial">. That said, I'm sorry for the lack of in-depth documentation. I will need to catch up on it before releasing a stable version (and yeah, I also happily accept contributions).

A general advice for testing / exploring: Enable and configure Authcache Debug. It will show you whether a page was cached and if it wasn't it will display the reason for it.

  1. The commerce add-to-cart form is Ajax-enabled. Note that before Drupal 7.27 and Authcache 7.x-2.0-beta3 this was not working at all (#2171129: Ajax forms not working for anonymous users on cached pages). You are right that the primary responsibility of Authcache Form is to replace CSRF form tokens for logged in users (using either Ajax or ESI). The second thing it does is to extend the lifetime of cached forms (including Ajax forms) if the Cache Object API is installed. This is necessary when cached pages are to be stored for more than 6 hours (i.e. the default expiry time for cached forms). Otherwise they will simply stop working after that period.

    In short: The dependency on Authcache Form for anonymous users is debatable, the dependency on P13n for anonymous users is artificial. However, because most Authcache enabled sites need some sort of personalization, I think those dependencies are acceptable.

  2. Yes, the markup of Authcache-enabled Blocks and Views is replaced completely. When verifying this, make sure that you inspect the source code of the generated pages, do not use the DOM inspector / developer tools of your browser.
  3. Note that form token replacement is only necessary for logged in users.

Regarding the custom module for user-menu links. It also would be possible to leverage the information provided by the Authcache User module instead of implementing the cookie-method. Use the following JavaScript skeleton (taken from authcache_comment.js):

(function ($) {
  Drupal.behaviors.mymodule = {
    attach: function (context, settings) {
      if (settings.authcacheUser) {
        // find appropriate links here and inject '/user/' + settings.authcacheUser.uid and perhaps settings.authcacheUser.name
      }
    }
  };
}(jQuery));

Thank you for taking the time and reporting back your experience with the module. This is invaluable information for people actively working on the project.

AdamGerthel’s picture

Thanks for a swift and clear response!

Yes, I read the info regarding Commerce Kickstart + Authcache, but it wasn't very informative as to how the modules work. And the Commerce Authcache module isn't useful in my case either since we're using another cart solution.

1. Ok, thank you for that info - I don't think it was an issue because cache is cleared and rebuilt once an hour, but I've upgraded to Drupal 7.27 and Authcache Beta 3 (was using beta 2) in either case. The strange for me was that authcache didn't work at all without Authcache Field and Authcache p13n - i.e. I didn't get any cached pages until I activated those modules. Could it be because I have a global search form?

2. Ok - that makes sense. This site in particular has a pretty non-Drupalish theme. Most of Drupal's default classes, wrappers and ID's have been stripped from the template files which is probably the reason it wasn't working. The thing that made me confused in particular was that I didn't know if I needed the modules or not. The site uses Views and Blocks, and I wasn't sure if that meant that I would need the respective authcache modules. Now I know that I don't - since I don't have any user specific blocks or views (other than in the checkout etc. which is excluded from authcache anyway).

3. Ok!

Regarding the user links:

I've activated the Authcache User module (CC all etc.) but Drupal.settings.authcacheUser is not there - logged in or not. Time is of essence on this project so I'll probably go the custom module route for now but would gladly use the variables provided by Authcache user instead.

znerol’s picture

I didn't get any cached pages until I activated those modules. Could it be because I have a global search form?

Yes probably.

I've activated the Authcache User module (CC all etc.) but Drupal.settings.authcacheUser is not there - logged in or not.

Note that this is not Drupal.settings but the settings passed in to the attach function. In addition to the JavaScript, it is also necessary to tell the P13n module to load the setting (sorry, forgot about that).

You can use the following code for that:

authcache_p13n_add_setting(array('#setting' => 'user'));

There is also the helper function authcache_user_attach_property() which you can use to simply attach the necessary JavaScripts etc. to an existing element. See authcache_user_form_alter for an example.

AdamGerthel’s picture

Status: Active » Closed (won't fix)

Thanks for the help and clarifications. You can see it in action @ www.olssongerthel.se (just launched the site redesign, responsive etc.). The site used to be very slow once a user had put something in the shopping cart but now it's as fast with or without items in the cart.