Blocking 'Ajax Only TXP Section' URLs.

joebaich · 2014-10-07 15:44:55

On a site I am working on right now, I place AJAX calls on individual articles, a description of articles for sale, to display them in a modal over a page that lists many such items. So the call might go to mysite.com/forsalesection/itemname to populate a modal. How can I stop that, and all the others, being available at mysite.com/forsalesection/itemname as normal web page too?. I don’t want to mess with the way AJAX calls are made because I rely on the ‘out of the box’ facility that comes with Zurb Foundation Reveal modals.

There must be a simple solution but it eludes me

etc · 2014-10-07 16:18:25

joebaich wrote #284588:

I don’t want to mess with the way AJAX calls are made because I rely on the ‘out of the box’ facility that comes with Zurb Foundation Reveal modals.

I don’t understand what that means, but you can try to craft the AJAX section page this way:

<txp:etc_query data="{?HTTP_X_REQUESTED_WITH}" globals="_SERVER">
...page stuff...
</txp:etc_query>

Chances are Zurb sends this header for ajax calls, but I’m not sure.

joebaich · 2014-10-07 22:31:01

etc wrote #284589:

I don’t understand what that means, but you can try to craft the AJAX section page this way:

<txp:etc_query data="{?HTTP_X_REQUESTED_WITH}" globals="_SERVER">...

Chances are Zurb sends this header for ajax calls, but I’m not sure.

Many thanks Oleg. Essentially, I am reworking an older site and so there are many links to urls in the form mysite.com/forsalesection/itemname in the wild already and many of them are still extant.

The sites owner is not an ‘IT’ person but needs to add to the sales notices from time to time using the write tab. I call these from mysite.com/forsalesection/itemname via the ZF Reveal modal to the single page at mysite.com. However when the visitors invokes mysite.com/forsalesection/itemname from, for instance, a Google search result, we need the visitor to be directed to mysite.com or an error page. Currently he/she goes to an unstyled version of the page.

Last edited by joebaich (2014-10-07 22:31:38)

etc · 2014-10-08 07:51:13

That’s what I have understood, the obscure point was I don’t want to mess with the way AJAX calls are made. :) Most of js frameworks (not sure for ZF) send a X-Requested-With header with AJAX calls, stored by PHP in $_SERVER['HTTP_X_REQUESTED_WITH'] variable. So you can try to detect it at the beginning of the page form associated with forsalesection and redirect if necessary:

<txp:php>if(empty($_SERVER['HTTP_X_REQUESTED_WITH'])) header('Location: mysite.com');</txp:php>

Edit: maybe a better (Apache) way here

Last edited by etc (2014-10-08 12:25:13)

jakob · 2014-10-08 13:52:13

Not sure if this messes with Zurb Reveal, but what I’ve done before in a comparable situation is to use smd_redirect with a rule like this:

source: ^/section/(.+?)$
destination: /section#{$1}

This re-routes links to articles to a corresponding hash url. I then give each instance of a modal an id that matches the article_url_title and use a snippet of jQuery to catch an incoming #link and trigger the modal:

// auto-load event if event hash is passed as #value via url
        var hash = window.location.hash;
        if (hash) {
          $(hash).click();
        }

This is using LeanModal and inline modals but you may simply be able to direct it to Zurb Reveal’s load modal function.

joebaich · 2014-10-08 15:36:29

etc wrote #284597:

That’s what I have understood, the obscure point was I don’t want to mess with the way AJAX calls are made. :) Most of js frameworks (not sure for ZF) send a X-Requested-With header with AJAX calls, stored by PHP in $_SERVER['HTTP_X_REQUESTED_WITH'] variable. So you can try to detect it at the beginning of the page form associated with forsalesection and redirect if necessary:

<txp:php>if(empty($_SERVER['HTTP_X_REQUESTED_WITH'])) header('Location: mysite.com');</txp:php>...

Edit: maybe a better (Apache) way here

Grateful thanks once more, Oleg. I liked the look of the Apache way. Dot htaccess files are more in my comfort zone and so I tried it out.

RewriteEngine on
RewriteCond $1 ^forsalesection
RewriteCond %{HTTP:x-requested-with} !^XMLHttpRequest$
RewriteRule (.*) http://mysite.com [R=301,L]

It works for me for the most part, modals work normally when http:my site.com is accessed directly. Also when when one invokes a link http://mysite.com/forsalesection/specific-item, one is redirected to http://mysite.com as intended. If one then invokes the modal http://mysite.com/forsalesection/another-specific-item, the modal appears and behaves as intended.If however one invokes the modal that corresponds to the original link http://mysite.com/forsalesection/specific-item, one gets a version of http://mysite.com/ (i.e. the whole single page site) in the modal. Thereafter all modals don’t perform well.

Probably worth bouncing this over to a Zurb Foundation forum.

joebaich · 2014-10-08 15:46:18

jakob wrote #284602:

Not sure if this messes with Zurb Reveal, but what I’ve done before in a comparable situation is to use smd_redirect with a rule like this:

source: ^/section/(.+?)$...

This re-routes links to articles to a corresponding hash url. I then give each instance of a modal an id that matches the article_url_title and use a snippet of jQuery to catch an incoming #link and trigger the modal:

// auto-load event if event hash is passed as #value via url...

This is using LeanModal and inline modals but you may simply be able to direct it to Zurb Reveal’s load modal function.

Thanks Jakob. I’ll have a look at adapting that to my case.

I went the AJAX route instead of the inline route for the modals to cut down the size of the single page. Having everything in line, in this case, caused an unacceptable load time.

I seem to have more and more sites coming up that beg for a single page solution and so am keen to get a reliable method going for this.

etc · 2014-10-08 15:49:31

You are welcome, Joe. It looks like a cache issue, but I’m not quite comfortable with Apache. Is this article of any help?

Textpattern CMS

Textpattern CMS support forum

#1 2014-10-07 15:44:55