Refactor JS

Would switching hook_init() for hook_boot() fix it? Nevermind, tried it - undeclared function drupal_add_js() during boot.

Ok, this is going to sound Really silly. The problem is with Drupal (not Varnish's) caching turned on - then hook_init() never gets run, so Varnish never picks things up right? Hence the thought of hook_boot() if it had access to the functions then we'd be happy. Have I got my head wrapped around the problem correctly now?

The cache I was originally trying to work around was Varnish, the cache that's causing the problem as things stand is Drupal's own?

If so: hook_exit() ?

Hm, I'm taking a further look into this. Hook_exit() and hook_footer() seem to be post page render, so we can't add more JS on those unless we use hook_footer to write our own JS.

Maybe use hook_theme_preprocess_page() to add the JS? I withdraw this idea, looks like by the time it gets to preprocess_page() the content and js is already rendered.

Otherwise, the prev thread mentioned using ajax, maybe write a settings js file whenever settings are updated and use ajax to pull those settings in?

I did figure out how to get theme_preprocess to run, the page was cached with the output so splashify showed, but that didn't change anything. Since theme_preprocess isn't hidden by cache I think something else is going on.

I'm still really unclear why I'm seeing the behavior I'm seeing based on the cause you're describing. I'm still not getting why this doesn't work as expected under Drupal cache. Lemme explain:

Looking over the code in splash_init(), it gathers all the setting information - checks against the URL for URL specific settings and the splash=on/off value, then generates the correct who/what/when/where settings and passes them to JS settings. It does all this without taking input from the user - so the results of this process should be universal for all users.

Then the page gets cached, with those settings and the js that goes with splashify. All those js settings will now permanently be cached, but they're universal - should be ok. None of them are responsible for making a specific user see the flash based on their past experiences that's handled in js and js storage.

Then on page load, the splashify.js looks at the given settings and looks at the user's information in storage, *then* makes the decision to show the plash or not for this specific user. That's the decision point that matters for a single user and it's already in JS so it should be client side and safe from cache. I've confirmed that the JS does execute for every page load.

Wait... I think I may have found the problem. Tell me if this makes sense:

In hook_init(), PHP code sets js_nowtime = time(); and js_expiretime = time() + some value; Those values get passed in settings, and cached as any other js setting would. So based on this, under cache conditions, nowtimeSeconds will always be the first init time of the first visiting user, and js_expiretime based on the time given for that user. Neither the expire time, nor the nowtime update for any user display afterwards. So the behavior that user experiences is the behavior everyone sees, because as far as the script is concerned that's what time it is.

I think that's what's screwing this up. If so - then what we need to do is use the client side JS to figure out the now time and the expire time for this specific user, given a difference between the two that we pass in settings. I'm going to test this and see if it works. If so - then I'll get a patch to you.

Yep, looks like that was it. Removing the user information (time of arrival) from the hook_init calculations did it. Patch incoming shortly.

Timing issues like this are something I've run into a lot. Caches and JS and other oddities are par for the course for me. Sorry for getting a little chattery on the thread but talking it out really helps me sort out issues like this. :)

Here's the patch for 7, I'm working on the one for 6 right now.

Re: timezones, we actually don't have to worry about them at all. The timeframe for a user (daily, weekly, etc) is according to the user's own needs as a sliding window. Unless the computer is physically traveling time zones often and updating the timezone when it does - it won't be an issue: all time related math goes on the client side. It's a small enough edge case I feel comfortable saying the traveling user might not be surprised to see a splash page a little early.

And I wasn't awake last night apparently, even better reason not to worry about timezone - the getDate() function in JS we're using gives milliseconds since epoch. So timezone neutral. TZ just isn't an issue here at all.

And the D6 version, along with some minor tweaks the menu and permissions I needed to make to get this working on my dev site in 6. (Should be useful for the Backport thread too.)

Putting this up to needs review, I think we'll be in shape for our site so I'll report any odd behaviors we encounter as well.

As for getting around the JS rule, we could do it by breaking the "law" of Drupal, but for a contrib module like this I'm not sure I would recommend it. The reason that the js loads when it does is because drupalBehaviors waits until doc.ready to kick everything off. Bheaviors also makes sure that js runs properly if there's an AHAH or AJAX (depending on the version) event on the page. Elsewise you can get some really odd trigger/retrigger style behaviors going on.

You could get around this by printing your JS outside of the drupal_add_js context, dropping it directly into output somehow on the page in the header, or immediately after the body tag. But seeign as how you can't predict the behavior of the page it'll be loaded on so you'll have the risk of odd AJAXy interactions and potential namespacing issues.... probably not a good idea to do it that way.

I'll see if drupal's JS has any fast-track location we can attach to instead of behaviors.

Early reports from my client site say: It works! :) With both Drupal caching and Varnish caching.

Did you make sure to clear the cache? There's a JS change in this so if you've got the old JS in action that could muck with things.

Re: The internal URL issue, that may be something we need to move to the JS if it's not there. Basically anything that's dependent on the user's behavior (their storage settings, the time they arrived, the url they came from) needs to be in JS not in PHP.

hook_init should run for the very first user, and it just returns the diff between the two which would remain stable across any further user interactions. The value being returned in js_expire_after isn't a timestamp, rather it's the number of seconds to add in JS to make the right expire timestamp.

Try this patch, I've moved the comparison of referrer to hostname into JS. I'm not sure what's up with the cookies - I didn't change anything that would have touched that, but I don't think jStorage uses cookies to store data.

Great! :) Since we're working on adapting this module to a live site, I'll get patches in for anything else as they come up. We're mostly D6, so I think I'll help with the backport next. :)