After enabling esi_blocks all the blocks immediately disappeared. Tried a couple of times clearing caches etc.

Comments

pounard’s picture

Assigned: Unassigned » pounard

Thanks for reporting. I will try and see that. Do you have any more information about your configuration, core version, how did you configure the cache handling, anything about your blocks, and how did you configure the ESI API module itself?

john_b’s picture

OK page cache on the relevant site was set to use Varnish module in settings.php as per instructions on Varnish module page. APC module also installed. Restarting Varnish, which in theory is a quick way to clear the varnish cache (in RAM in my setup), did not fix the problem. Cache pages and cache blocks was set in performance settings. Disabling css aggregation and clearing the database caches did not fix it either. This does not happen on enabling esi_api alone, but only when enabling esi_blocks, as soon as it is enable, with all settings to default. I did try tweaking a couple of block settings, which made no difference.

pounard’s picture

It gives me a configuration where to start! I will update as soon as I at least reproduced it. Thanks a lot.

pounard’s picture

Status: Active » Postponed (maintainer needs more info)

Ok, I followed this procedure:

  1. I did a fresh Drupal 7.9 core install, no modules, standard profile.
  2. Installed Varnish module, as described in the documentation.
  3. Enabled ESI API module alone.
  4. Enabled ESI Block module: at this point, my blocks still are showing up, except they are loaded by parallel AJAX requests.
  5. Enabled page and block cache: still working, even in anonymous (tested Chrome and FF).
  6. Swtiched to Full ESI mode, blocks disappeared (which is the normal behavior since I'm not behind a real ESI gate such as Varnish).

I'm trying to debug the rendered HTML, I found this inside:

<!--esi
<esi:include src="/esi/block/search%3Aform/5b4748ef2eb42089a4a2819581f2bcfa" maxwait="5000"/>
--><!--esi
<esi:include src="/esi/block/system%3Anavigation/5b4748ef2eb42089a4a2819581f2bcfa" maxwait="5000"/>
--><!--esi
<esi:include src="/esi/block/user%3Alogin/5b4748ef2eb42089a4a2819581f2bcfa" maxwait="5000"/>
-->

All my blocks ESI tags are generated as they should.

When I hit the generated URL, the framework gives me my block as expected.

I'm going to see on your site (c.f. your mail) and check your configuration.
Do you have any other useful information to share?

pounard’s picture

I see on your site that blocks seems OK, am I wrong? Ho the module isn't enabled...

pounard’s picture

Status: Postponed (maintainer needs more info) » Active

I enabled the module on your site, and notice some weird behaviors:

  1. AJAX downgrade was working, but isn't anymore (WTF?), it seems that now it's doing recursive AJAX calls (it's probably a bug of my code). I cannot spot where this bug comes from, even debugging the JS step by step... I need a way to reproduce it on my local site.
  2. Varnish does not seems to read the ESI tags: from Varnish documentation it seems that you need to tell it to search for ESI tags for pages where you need it.
  3. It happens that some of your blocks actually really disappear when requested with AJAX, and I guess it's because it's missing contextual information for them. The problem is doing a generic module I cannot guess what information actually is missing, I have to fine an elegant way to solve this.
john_b’s picture

Thanks for your efforts. This is clearly important for Drupal, even if it is not important for a small low traffic site like mine!

On point 2. I do not understand this well. I have included this in my VCL on this server.

// Strip any cookies before an image/js/css is inserted into cache.
sub vcl_fetch {
  if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
    // For Varnish 2.0 or earlier, replace beresp with obj:
    // unset obj.http.set-cookie;
    unset beresp.http.set-cookie;
  }
// Added to provide ESI
  elseif (req.url == "http://www.hsmevents.co.uk") {
        esi;  /* Do ESI processing */
// This block was copied from https://www.varnish-cache.org/trac/wiki/ESIfeatures
// With change to beresp.ttl for Varnish 2.1 https://www.varnish-cache.org/docs/2.1/reference/vcl.html
        set beresp.ttl = 24 h;
    } else {
        set beresp.ttl = 1m;
    }
}

If this has to be set on a per site and per URL basis, it is clumsy.

My understanding is that this is placing the object in the cache with ttl = 24 hours.

There is something else I do not understand: with Drupal we usually pass all authenticated requests directly to the backend with (for Varnish 2):

sub vcl_rcv { ...
if (req.http.Authorization || req.http.Cookie) {
    /* Not cacheable by default */
    return (pass);
  }
}

. Am I right to think that this part of the VLC will need to be changed, if logged in users are going to take advantage of ESI?

However the immediate problem is that blocks disappear for both logged in and anonymous users.

pounard’s picture

Status: Active » Closed (won't fix)

I'm closing all issues for this module, please look at the ESI module which is now being maintained.