Idea: Restrict block based on JS Referrer
mikeytown2 - January 28, 2009 - 22:40
| Project: | Similar By Terms |
| Version: | 6.x-1.18 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
There are many applications of what I'm proposing here... but I would like to focus on the simplest first. Using Javascript, investigate document.referrer() and document.location.href() to see if the visitor didn't come from the site already and didn't land on the front page (adding toLowerCase() would be a good idea for the JS functions). If that is the case unhide (css display) the Similar By Terms block. Using a Javascript solution keeps this new feature cache-able with things like Boost (my fav toy on cheap hosting). Is this a good idea?
A more advance thing would be something like this
http://www.justjquery.com/2008/11/04/how-to-make-the-most-of-search-engi...
#1
1. The new caching code uses the standard drupal caching system. It just uses on a per-node bases were the standard cache does it on a per-role bases. So if Boost works within the standard Drupal Caching System then it will work with the updated Similar By Terms. You can disable the cache by simple setting it to never.
2. As for search field that would make since as an independent modules not part of this module.
Thanks
Robert
#2
boost serves static html through some .htaccess trickery. Thus when an anonymous visitor is browsing your site, they are getting served a static html file. No PHP is run on the server. I like the Similar by Terms module, but I only want the similar by terms block when the visitor hits it from a search engine that is linking to something other then the frontpage. That's where the JS comes into mind; otherwise you could use some PHP ($_SERVER["HTTP_REFERER"]; $_SERVER['REQUEST_URI'];) and control the displaying of it in the block config. All in all I think it will work, so I need to go write up some JS.
#3
This sounds outside the scope of this project. Maybe I am miss understanding why you are tiring to do. I will certainly look at the patch to look into including in this module.
Thanks
Robert
#4
This is the Javascript I'm cooking up, going to wait until later to test on a live site
//lowercase, kill 'http://', kill stuff after '.com/', kill 'www.' if there
var ref = document.referrer.toLowerCase().split('http://').pop().split('.com/').shift().split('www.').pop());
var base = location.href.toLowerCase().split('http://').pop().split('.com/').shift().split('www.').pop());
if (!document.referrer || ref==base) { //no referrer was passed OR referrer is from this website
$('block-similarterms').hide()
}
else { //unhide similar by terms div
$('block-similarterms').show()
}
#5
I thought there was a module that examines the referrer for search engine URLs to display content selectively - but I can't locate it, perhaps it was just a dream..
I would suggest using a combination of PHP and JS code - because JS might be disabled (and then a Drupal site doesn't work well anyway) and PHP REFERER is not always reliable...
#6
using boost, so php isn't an option. less then 1% of users to my site have js off, so I'm not worried about it
#7
Here's the working code, just tested it
$(document).ready(function(){//lowercase, kill 'http://', kill stuff after first '/', kill 'www.' if there
var ref = document.referrer.toLowerCase().split('http://').pop().split('/').shift().split('www.').pop();
var base = location.href.toLowerCase().split('http://').pop().split('/').shift().split('www.').pop();
//no referrer was passed OR referrer is from this website
if (!document.referrer || ref==base) {$('div.block-similarterms').hide();}
//unhide similar by terms div
else {$('div.block-similarterms').show();}
})
Anyway to add this to the page via a configure option on the admin page? Make it a selection that the admin can choose on admin/settings/similarterms.
http://api.drupal.org/api/function/drupal_add_js
#8
Better yet would be to put the option on the block configure page; that would cause class conflictions though, since the block does not have a unique class. Core theme problem... each block has to have a unique class was never was specified. No good solution, other then to change block.tpl.php :( Guess making it a global option is the best bet for now.
#9
This is missing any configuration options.