[wp-hackers] Including javascript in the footer

[Azizur Rahman]

I am just thinking on the original issue here.

>> In my case I'm making a programmatic decision partway through the page
request whether or not I want to include a script in the footer, and
unfortunately, that decision is being made after the 'wp_print_scripts' hook
is fired.

I know this might not be the solution you are after but can't you just do a
client side asynchronous loading of scripts? you'll need JS enabled anyway
for your selected scripts to run.

You can set up you own dependency checking that fires When DOM ready. While
your asynchronous loading in progress you could easily display a status
message to end user.


Also:
>> So what should I do? I don't want to just echo the script markup in
'admin_print_footer_scripts' because that just seems wrong. However, I can't
really think of any other good way.

If you must load specific script you can always set up your dependent
files/tag into a javascript variable at this point and have it processed by
the asynchronous loader in the footer.



Regards,
Azizur Rahman


On Thu, May 19, 2011 at 10:03 AM, Mike Little <wordpress at zed1.com> wrote:

> On Wed, May 18, 2011 at 01:46, Dylan Kuhn <dylan.k.kuhn at gmail.com> wrote:
>
> >
> > For me it's a specific case, but one I seem to have to consider a lot.
> Map
> > libraries, fancy slideshows, table enhancers, and such can all be fairly
> > heavy on the javascript, but used in a minority of content. It seems like
> > that content is often as likely to be in a widget or dependent instance
> of
> > WP_Query as the main one.
> >
> > It's harder to make the decision in plugin code, because you have no idea
> > how much content will need the scripts. Maybe it would be a nice plugin
> > option to let the user choose their strategy, lookahead or global
> include.
> >
> >
> One possible strategy is to save a reference to the post at the time the
> content is generated. This could be looking for your short code (or
> whatever
> triggers the need for JS) in the content *at the time it is saved* and
> adding that post id to a list saved in an option. That way, the look up at
> request time is very fast (the option will already be loaded) and simple
> (looking for a post id in the retrieved content)
>
> Of course, you will need to hook post saves, trashes, and deletes but
> that's
> low overhead simply because it only occurs when the user alters content on
> the back end.
>
> Finally, if you need to cater for multiple loops, you can hook 'the_posts'
> (late) to make your decision (to include in the footer).
>
> Mike
> --
> Mike Little
> http://zed1.com/
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>