Hi,

I am using authcache to great effect and now I have a very specific problem to solve and I am wondering if there is a "correct" way to tackle this with authcache.

When a user does a search I store info about their specific search in a session variable. The user can have more than one live search at any one time by using multiple tabs.

The search results are generated on the fly and node hyperlinks all contain an ID to identify which specific search has resulted in the user landing on the node page, eg node/123?sid=abcdfeg

The node pages are cached using authcache.

Embedded in the page is a component that allows the user to move to the next/prev result from the users search that led them to this page, so they don't need to go back to the search results page to see what is next.

Is there a neat way for me to have the sid query string parameter sent as part of the AJAX fragment request? Because the pages are cached per role, but the sid is user specific, I cannot inject from the server side so I have been looking for a javascript solution but so far have not identified a clean solution.

It is fairly easy to solve if I use my own AJAX calls, but I wonder if there is an authcache solution?

Many thanks

Graham

Comments

graham.roberts created an issue. See original summary.

znerol’s picture

znerol CreditAttribution: znerol commented

What exactly do you attempt to deliver with the AJAX fragment? A block? A view? What are the contents?

In general if you set the cache granularity of the fragment to per page, then the original path and query parameters are restored inside the authcache front controller before rendering the fragment.

graham.roberts’s picture

graham.roberts CreditAttribution: graham.roberts commented

Thanks for the quick update.

It will be a block. If setting granularity to per page will ensure the query string parameters are visible in the frontcontroller, that sounds like the perfect solution to me.

Just thinking out loud though, based on a quick review of the javascript earlier, I don't recall seeing anything in the javascript that would pull the SID query string parameter to pass back to the front controller, and I can't rely on server side code to put the URL with query string into Drupal.settings because when the page gets cached the SID cannot be embedded because it is user specific.

I will have a play and any further thoughts would be much appreciated.

Thanks

Graham

graham.roberts’s picture

graham.roberts CreditAttribution: graham.roberts commented

..I should have added, the contents of my block is a list item, eg:

<ul>
<li><a href="node/1?sid=abcedfg">Prev</a></li>
<li><a href="searchresults?sid=abcedfg">Back to search</a></li>
<li><a href="node/3?sid=abcedfg">Next</a></li>
</ul>

znerol’s picture

znerol CreditAttribution: znerol commented

The page cache will respect a query string when saving/retrieving cached pages. I.e. node/123?sid=abcdfeg and node/123?sid=uvwxyz are treated like different pages. If I'm not completely misinterpreting the case, it should not make any difference if your sid parameter is per user or not. The only problem you have is that this will blow up your cache with a gazillion variants of the same page (each with a different sid) each of them saved on behalf of different users.

If you enable per page granularity on a fragment, then the o parameter of the fragment URL stored in Drupal.settings.authcacheP13nAjaxFragments is basically set to $_GET of the page it is rendered on. In the front-controller, the o parameter is then restored into $_GET (See authcache_p13n/includes/frontcontroller.inc authcache_p13n_frontcontroller_prepare_request().

graham.roberts’s picture

graham.roberts CreditAttribution: graham.roberts commented

Thanks znerol, that is very useful, and leads me to a slightly different question - is there a way to tell authcache to ignore a specific query string parameter, since I do not want a cached page for every SID?

If the answer is yes, then I guess I will be back at my original problem, since then I won't be able to pull the SID data from Drupal.settings.authcacheP13nAjaxFragments

Thanks again for your input

graham.roberts’s picture

graham.roberts CreditAttribution: graham.roberts commented

Answering one of my own questions, I am going to say, no, I cannot bypass a query string param because I see that the $cid is generated by appending request_uri(), which includes the query string. Time for a rethink on this one.

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan as a volunteer commented

I ran into the same requirement as @graham.roberts and created this issue #2666356: Allow altering request URI used for cache ID.

znerol’s picture

znerol CreditAttribution: znerol commented
Status: Active » Fixed

A possible solution would be to simply drop the request parameter using a rewrite rule for requests directed towards the authcache front controller. Use this SO post as a starting point.

Closing this issue, please reopen if you find a better solution.

Status: Fixed » Closed (fixed)

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