I almost have this working....

I'm using ESI succesfully to display a dynamic poll block for anonymous users on a D6 (pressflow + varnish 2.1) site.

It works fine (voting and displaying dynamic data), except for one thing, when I vote, the form submits to:

and the user is left with a white (unstyled) screen only showing the result html.
I also tried using ajax_poll, but with no effect.

The poll block ESI setting is "do not cache but use ESI". When I disable ESI it works fine. So I guess something gets lost when the block is created using ESI/varnish? Any ideas?

#5 esi-PerPageBlock-1440094-4.patch406 bytescmlara


cmlara’s picture

I can +1 on seeing this.

I looked through the code of login block which has the same issue.

It is a function of how the modules like poll and login use to determine the base url for the SUBMIT callback.

If the block is set to 'global' or 'do not cache' there is really no way to reference the page the user was on since the submit URL is suppose to reference the same page the poll is submitted from. If

Per page blocks could have some code worked around into ESI possibly.

The simple method would be to hard code the callback URL in the polls module to the root of the site but this will cause you to be redirected away from your content at least then they will see a stylized page instead of the blank page.

I have just for the time being have settled for using blocks that submit data as not using ESI until I have time to look at this part of the code.

askibinski’s picture

So, let me get this clear:

The problem:
The ESI block is loaded through Varnish, but has no clue in which content it is placed? The block itself does not contain any information about the url which is actually used for the end-user, and this url should be used as the callback url?

cmlara’s picture


What normally happens is the form action= line is the same as the page the user is on so that the form is 'submited' to the same page as the user is on at the time.

When ESI is not in use the form can see that user is on /node/221 for example because q=node/221

When ESI is in use however on GLOBAL blocks q=esi/block/etc..

Even if you used 'per page' blocks we still has q=esi/block/etc but we do have extra data in the URL (base64 encoded node/221 for example) but the poll module doesn't know how to use this

It is a function of how action= is generated by the Drupal code/module code.

ESI may be able to pass on the node/yada to q= with some code edits as I said but I haven't looked how this would be done. The block would NEED to be "per page" then which is VERY inefficient for caching but is better then needing to reload it on each page.

Varnish does not currently support variables however SQUID does.

If we code a solution for this that uses ESI variables(would need to be a 'select option' between squid/varnish) one could do forms as a block with global context gaining efficiency.

cmlara’s picture

Funny thing.

The code I talked about for q= already exists. This is similar to another bug report I have open.

Change in esi.module:

  $items['esi/block/%'] = array(
    'title' => 'ESI handler',
    'page callback' => 'esi__block_handler',
    'page arguments' => array(2),
    'access callback' => TRUE,
    'type' => MENU_CALLBACK


  $items['esi/block/%'] = array(
    'title' => 'ESI handler',
    'page callback' => 'esi__block_handler',
    'page arguments' => array(2,3),
    'access callback' => TRUE,
    'type' => MENU_CALLBACK

Will file a patch shortly

DOC NOTES: the block must be at least PER PAGE for this to work correctly.

cmlara’s picture

Title:Poll with ESI and Varnish 2.1 on Pressflow 6.x » Blocks that vary per page do not render correctly
Category:support» bug
Status:Active» Needs review
new406 bytes

Patch to enable blocks that render different per page (Such as Login block, Poll block, any block with a form submission, etc)

Code is already in place just an array element needed to be passed.

Note to commiter:
Similar to my patch in #1059036: ESI blocks don't appear when they are added to regions using context.

mikeytown2’s picture

Status:Needs review» Fixed

This patch has been committed! Thanks :)

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.