wp_enqueue_script() doesn't work mid-page for footer scripts

[Viper007Bond]

Create a footer script at init, plugins_loaded, or whatever. Doesn't matter, just early.

wp_register_script( 'myscript' '/some/path/script.js', array(), '1.2.3', true );

Now if we were to do wp_enqueue_script( 'myscript' ); directly after that, the script would be outputted in the footer as expected.

However if we were to do the enqueue farther down the page, say inside a the_content filter, it doesn't work. It should. I need to be able to dynamically enqueue scripts for example based on shortcodes.

[Viper007Bond]

Missing comma inside that register:

wp_register_script( 'myscript', '/some/path/script.js', array(), '1.2.3', true );

And incase you didn't notice, the fifth parameter is set to true which makes it output in the footer.

[Viper007Bond]

Debugged and found the problem.

When WP_Scripts::do_item() fires for outputting the header scripts and comes across a script that is meant for the footer, it tosses that that handle into the WP_Scripts::in_footer array and aborts outputting it.

Calling wp_enqueue_script() after that point doesn't add the script to the WP_Scripts::in_footer array, so it never gets properly registered.

I have a couple solutions in mind, but I'll let someone more at home with the class (azaozz perhaps?) come up with the solution to ensure it's the cleanest one.

[azaozz]

Yes the script loader requires all scripts to be queued before the page starts to load so it can do the dependencies properly. It also supports wp_print_script() in the middle of the page and would print all dependencies (if not already in the head) and remove any of them if queued for the footer.

I suppose we can add support for wp_enqueue_script() in the middle of the page that would queue scripts only for the footer. Would need to force all dependencies to print in the footer too even if queued for the head by default.

That may bring some issues with scripts that cannot run from the footer properly and are printed as dependency. Perhaps would be better to leave this as an "advanced" option only.

[Viper007Bond]

I didn't think of just using wp_print_scripts( 'myscript' ); inside a footer hook. That works nicely.

Dropping the priority on this and switching it to an enhancement as there's an alternate solution.

[hakre]

Replying to Viper007Bond:

Debugged and found the problem.

When WP_Scripts::do_item() fires for outputting the header scripts and comes across a script that is meant for the footer, it tosses that that handle into the WP_Scripts::in_footer array and aborts outputting it.

Calling wp_enqueue_script() after that point doesn't add the script to the WP_Scripts::in_footer array, so it never gets properly registered.

I have a couple solutions in mind, but I'll let someone more at home with the class (azaozz perhaps?) come up with the solution to ensure it's the cleanest one.

thanks for getting into it. a propper dev feedback would be nice, because as you I think this should be easily solveable.

[Denis-de-Bernardy]

+1 for this one

[Denis-de-Bernardy]

Attached patch does the trick. tested with a footer script that required recursive depends including a few that should go in the header.

Before the patch: nothing gets added at all.

After the patch:

• all depends (including recursively needed depends) get added in the footer if none is previously added
• already included depends do not get added as expected

Potential issues I can think of:

• localized scripts (should work fine)
• scripts that really should be in the header, but I think it is the plugin author's job to make sure his scripts work.

[azaozz]

Still think it's better to use wp_print_scripts() in the middle of the page or in the footer. The patch may behave unexpectedly when wp_print_scripts() is used after it but before the footer action.

[aaroncampbell]

I just thought I'd add in my two cents. First, this would be really handy to have for the exact reason that Viper mentioned, shortcodes. Shortcodes have become an extremely useful tool, but the ability to easily enqueue scripts would really put them over the top. Right now I'm using the suggested method of a wp_footer action that calls wp_print_scripts, but it's not as elegant as using wp_scripts.

Hopefully we can take a look at this again some day soon.

[archon810]

+1 for a proper solution - the use case that Viper described (shortcodes) makes this look like a bug - the feature of printing scripts in the footer does not work as expected.

[scribu]

Can't wait for jQuery's require() method.

[scribu]

Related: #15126

[amattie]

I just ran into this issue when trying to add a script to the footer within a shortcode. I considered this to be bug and created a patch before looking for and finding this ticket. I'll be attaching that patch for debate and consideration purposes.

In order to address my needs for now, I will manually add my scripts to in_footer[] immediately after the enqueue.

[amattie]

Alternative solution for consideration purposes

[scribu]

Re-opening for reconsideration, given amattie's patch.

[azaozz]

The second patch forces a script in the footer without accounting for the dependencies. When that script depends on another script that prints in the head by default (and is not already printed) it would break.

I would rather go with the first patch (by Denis). It prints all scripts that haven't been printed yet in the footer regardless of the default location.

[scribu]

Related: #15843

[SergeyBiryukov]

Related: #16694

[philipwalton]

For what it's worth, I ran into another situation other than shortcodes where I needed to make the decision whether or not to enqueue a script after the admin_enqueue_scripts hook was fired. In this case on the admin side.

I'm using an MVC plugin framework that loads a view file for the settings form. In the view file the user of the framework creates a form object, e.g:

$form = new MVC_Active_Form;
$form->ajax_validation = true;

So the framework has no idea whether or not the settings form will require ajax validation until after WordPress loads it, which doesn't happen until well after the admin_enqueue_scripts hook is fired.

Anyway, I just thought I'd offer another example to support a better implementation of wp_enqueue_script() in core. In the meantime the proposed work-around is doing the trick.

[mitchoyoshitaka]

Working on #17704 now and realized I can't do it neatly because of this bug. Just another reason why getting this fixed properly would be appreciated.

[azaozz]

9346-2.patch adds support for late enqueueing of both scripts and styles which are printed in the footer.

[azaozz]

In [18446]:

Support for using wp_enqueue_script() and wp_enqueue_style() in the HTML body. All scripts and styles are added in the footer, fixes #9346

[nacin]

Lots of new functions, should docs would be nice.

Would be good to get westi to look at this as well, as he's generally watched the dependencies closely. Some of the stuff in [18446] looks a bit cryptic.

[azaozz]

Replying to nacin:

The only "real" change is making in_array() in class.wp-dependencies.php do a strict comparison. The rest is copy/paste between the wp-scripts and wp-styles functions. It would be better to open new tickets for any further problems.

[michalsrodek]

Unfortunately it's not the best idea to add styles in the footer. In some cases websites are loading very long and some parts are unstyled until whole page is loaded. I think that it would be better to buffer everything after head section using ob functions(​http://www.php.net/manual/en/ref.outcontrol.php).

[ocean90]

If you have problems you should open a new ticket.

[aaroncampbell]

Replying to michalsrodek:

Unfortunately it's not the best idea to add styles in the footer

This thicket was for scripts not styles.