Centralize javascript inclusions

[mdawaffe]

WP should provide a built in means of including javascript files and their dependencies. This has been discussed on wp-hackers at least twice (most recently: ​http://comox.textdrive.com/pipermail/wp-hackers/2006-April/005917.html).

The attached patch establishes a method to define and use WP javascript, reworks the admin section to make use of this method, and calls this method both in admin-header.php and in the wp_head hook. The patch keeps track of all scripts and their dependencies, which scripts are slated for inclusion on the page, and which scripts have already been included on the page.

Perhaps a little overkill.

[mdawaffe]

WP_Scripts class

[mdawaffe]

Forgot to mention that the patch also adds ?version=$wp_db_version to all the src attributes. A different method of cache busting could easily be swapped in.

[skeltoac]

Sweet!

On cache busting, I wouldn't count on the db_version bumping the scripts on a bugfix release. How about this: Each script can have its own version number as an optional argument to the add method, then fall back on db_version.

Also, we have TinyMCE accepting ?ver= and passing that on when it loads its scripts and dialogs. So if you're going to change it to version you have to change TinyMCE as well. I'd stick with ver.

[mdawaffe]

Thanks for the pointer about TinyMCE and ver. I've deprecated tinymce_include() and taken your suggestions for cache busting in the new patch.

2701b.diff

1. Optional version parameter in the addition functions.
2. Native scripts have all been given versions. I used real version numbers where provided, real version numbers . _changeset where necessary, and changeset otherwise. I kept the date based version on TinyMCE. Whether we use dates or changesets for anything in the future won't matter. The changesets were easier to find, is all.
3. src="blah?ver=( $script->ver ? $script->ver : $wp_db_version )"

[mdawaffe]

Good suggestions from skeltoac

[skeltoac]

Changesets are better than dates as long as the committer sets them correctly. The patch writer doesn't know what the changeset will be, so should bump to a guessed number and make note in the ticket for the committer.

[mdawaffe]

As an aside, this offers a nice pluggable way to disable scripts that pose accessibility concerns.

/*
Plugin Name:  AJAX b0rked my screen reader.
*/

add_action( 'wp_print_scripts', 'no_ajax' );

function no_ajax() {
 global $current_user;
 if ( $current_user->data->no_ajax )
  wp_deregister_script( 'sack' );
}

With this in mind, we should rewrite the printer such that it doesn't include JS with missing dependencies. That way, the plugin wouldn't have to try and non-robustly do wp_deregister_script( 'sack', 'ajaxcat', ... );, and the user wouldn't get a lot of JS errors.

[mdawaffe]

absolute links. Better dependencies check

[mdawaffe]

2701c.diff

1. Absolute paths may be needed by some.
2. Do not load scripts with missing (i.e. unregistered) dependencies.
3. wp_print_scripts hook should fire first thing since wp_print_scripts() doesn't instantiate $wp_scripts.
4. Some inline docs for the recursive or otherwise confusing functions.

[ryanscheuermann]

I've installed this patch, and I must say, this is some fine work. Definitely digging the dependencies, and the fact that plugins can call wp_print_scripts without worrying about whether or not it's already there.

As far as I can tell, everything seems to be functioning correctly. Still testing it, though.

Maybe one small suggestion: move the WP_Scripts and _WP_Script classes to classes.php?

[ryanscheuermann]

OK, found a bug: WP_Scripts->all_deps() uses array_combine which is only available in PHP5 :-(

​http://us2.php.net/manual/en/function.array-combine.php

[mdawaffe]

Just say no to array_combine(). Fixes bug found by ryanscheuermann.

[mdawaffe]

Good call. Thanks.

2701d.diff

1. Ditch array_combine(). Use something less complicated.

[mdawaffe]

oops

[mdawaffe]

As for the best place for the classes, I don't know. classes.php is fine, if that's where people want them.

2701e.diff

1. Oops: stray var_dump() fixed.

[ryan]

This only needs to be loaded for the admin, right? I think it only needs to be loaded when admin-header.php is loaded. Maybe add WP_Scripts and friends to wp-admin/script-loader.php and include it from admin-header.php.

[mdawaffe]

Ideally, people could use it to deal with JS in their themes and plugins as well. It gets called by the wp_head hook.

[ryan]

Okay. How about putting the class and the wrapper functions into wp-includes/script-loader.php or something like that?

[mdawaffe]

script-loader.php

[mdawaffe]

2701f.diff

1. Move classes and wrappers to wp-includes/script-loader.php
2. require script-loader.php from wp-settings.php
3. Move tinymce_include to wp-includes/deprecated.php

[mdawaffe]

If we allow query string like parameters to be passed through the enqueuers and printers, we can get rid of a lot of the inline JS. Everybody likes browser caching!

2701g.diff

1. Allow things like wp_enqueue_script( 'script?foo=bar' ) that calls script.js?ver=3000&foo=bar.
2. Do this for the dbx stuff. Doesn't admin-header.php look pretty now?

This will give plugins a much better means of customizing the admin panels. Currently, a lot of WP's decisions to include or not include various JS bits is not accessible. Also, it's a nice resource for themes and "front-face" plugins.

[mdawaffe]

Allow parameter passing to scripts

[ryanscheuermann]

Hey mdawaffe, first test found 1 small bug. dbx-admin-key-js.php needs to add 'link.php' to its test case:

	case 'link-add.php' :
	case 'link.php':
              $man = 'linkmeta';

Otherwise, when I edit a bookmark, I get a DBX error about an invalid session ID.

[ryan]

[3788]

[mdawaffe]

Fix for call from wp_head

[mdawaffe]

The wp_head hook passes an empty string to wp_print_scripts() which breaks the script loader since various pieces test that value for identicality with false (not equality).

2701h.diff

1. Fix for call from wp_head.

[arnee]

Please allow plugins to use DBX. Patch for dbx-admin-key-js.php attached.

[arnee]

Allow plugins to use DBX

[mdawaffe]

arnee, I had assumed that plugins would just create their own dbx-key javascript to register and enqueue (de-registering or dequeuing the normal dbx-key if necessary).

I suppose plugins which use the same DBX groupings as the core does (something I had not considered) would benefit from your patch.

[mdawaffe]

Better fix for wp_head. Replaces 2701h.diff.

[mdawaffe]

2701j.diff

1. Fix call from wp_head. A slightly better patch than 2701h.diff.

arnee, I'm not sure of the security implications of allowing arbitrary JS injection (albeit from a restricted set of users).

So -1 to 2701i.diff. Plugins can register their own dbx-key JS as separate files.

[ryan]

(In [4105]) script loader fix from mdawaffe. fixes #2701