GeoIP Redirect Architecture [Meta Discusion]

Yeah, I really like doing things with Context module. I hacked on the holiday_overlay module awhile back just so the I could use the path and various context controls to then determine when and where the popup got triggered.

Making it depend on context module might be a good / easiest route. Basically, add a new condition for GeoIP, then the reaction would the popup redirection thing. I'm not sure where we'd stuff in the text display variable and redirection, but I'd need to dig more into Context module. One of my main thoughts was thinking about doing it in a way so it works as ctools exportables.

I mean technically it wouldn't have to be with Context module...

Ported Context GeoIP to D7: http://drupal.org/node/1137972#comment-5840140.

With user's geo ip as a context condition, then we we turn geoip_redirect into a two part module in the sense that we keep it as a simple global redirect if people want just that OR if context_geoip is enabled and you select "use geoip redirect with context module," then you'd could easily build a context where the popup box setup triggered by different geo ip conditions and otherwise. I'll need to look though at how we can add stuff to context reactions.

Technically I could just create a new module called GeoIP Context Redirect, but I don't really think we need more modules in Drupal... Any thoughts?

Ok. After porting the context_geoip to D7, I said, hey there has gotta be a context reaction module for redirection, no surprise: http://drupal.org/project/context_redirect, though I'm not quite sure I like the way it does redirects...

Anyways, for geoip_redirect, I got most of the easy Drupal-ly stuff in place for creating two situations:

1. Global Variables for customized message text, redirect url and url link text, which get fed to the redirect javascript.
2. Context Reaction setup for adding specific redirect reaction details for message text, redirect url and url link text.

So more or less, structurally, it's ready for real work of redirecting. I've currently got it handled via hook_page_alter (basically to control whether or not, we use contexts to control or not) and then hook_add_js which is where I have the variables fed to the js redirect popup stuff. I saw that you had most of the work being done in the hook_boot but I'm sure we want it all there, though I could be wrong. I'm not very familiar with using cookies, but perhaps we can keep the cookie-ed redirect there.

Need to think a bit more, but storing individual redirect rules in the ctools exportables works nicely.

Yeah, I see your point about caching issues / boot_hook. Part of the issue is, of course, aggressive caching which will cache the results instead of running the code. I partially wonder if the issue lies more in the geoip api / context conditional situation that gets set. I'm getting some irregular reactions in the condition being triggered, so I wonder if we need to improve this by just having a bit of javascript to pull the IP dynamically from the server (in my case nginx) before it gets passed into the context condition/reaction engine. I haven't really dug into the geoip code yet.

Hmmm.... I'm seeing exactly what you mentioned about caching resulting in the first version cached resulting in that being the version seen by everyone. How does apache determine the user's IP? Is it exposed somewhere in a variable? Nginx (at least with BOA) has a sever variable that could be pulled and fed to the geoip stuff...

Yeah, I'm wondering if I'll need to make somes changes there in geoip api module so it's pulling this via javascript directly from server; we'll see.

This project just shoved down in priority today so not sure now...