Code Snippet: Disable jQuery Migrate

I like to keep my installs trim and scripts to minimum, i know nothing i run needs the migration tool, so let’s knock that one on the head. If you don’t know what this script does or is for, it’s probably best to leave it be.

	add_action( 'wp_default_scripts', 'on_wp_default_scripts', 2000 );
	public function on_wp_default_scripts( $wp_script_instance ) {
		
		if( !isset( $wp_script_instance->registered['jquery'] ) )
			return;
		
		foreach( $wp_script_instance->registered['jquery']->deps as $k => $script ) {
			
			if( 'jquery-migrate' !== $script ) 
				continue;

			unset( $wp_script_instance->registered['jquery']->deps[$k] );
			break;
		}
	}

Advertisement

Code Snippet: Replace the admin bar logo link

A handful of misclicks on that logo and i’m going to be writing a function to change the link.

add_action( 'wp_before_admin_bar_render', 'change_admin_logo_link' );

function change_admin_logo_link() {
	
	global $wp_admin_bar;
	
	// Get the logo node
	$menu_node = $wp_admin_bar->get_node('wp-logo');

	// Change the link to wp-admin
	$menu_node->href = network_admin_url();

	// Add the modified node back
	$wp_admin_bar->add_node( $menu_node );

	// Clean up
	unset( $menu_node );
}

Now I can avoid seeing that dreadfully designed about page if I misclick the top corner of the screen.

It’s been a while.

A good decade or so. It wasn’t personal, i didn’t stop existing, i just didn’t have a need to be writing about or code for, WordPress, nor have any need to be part of the whole ecosystem.

WordPress has changed pretty significantly in my absence. What the feck are blocks and why don’t i like em? I’m trying (i’ve not simply enabled the old editor), but it feels like dozens of layers of overly abstract JS libraries(that seems to be the modern thing) for what results in a barely intuitive and sluggish UI all just to allow users to become amateur front end designers with their content.

And yet a decade later registering an admin page results in a dozen extra CSS stylesheets being loaded into the head that aren’t needed (without even mentioning the emoji stuff). There has been some nice work on the backend however, the admin color themes are simple, subtle but work and there’s been some changes to the general admin markup, it’s more light, trim and consistent compared to the 3.x days (WP wasn’t even at v4 last time i was around).

Well, anyway, i’m blowing the dust off my old accounts and getting back into PHP and WP, i have time, little to do and a passion for writing PHP.

I’m feeling a bit behind the time and rusty, the underlying core aside from the block stuff seems to be largely the same, let’s see if this old dog can’t learn some new tricks.

Conditional tags on init?

I was recently answering a question on WordPress StackExchange and the question of appropriate hooks came up when suggesting where to hook on your styles or scripts when you’re needing to check conditional tags, those such is_page(), is_category, and so on..

http://wordpress.stackexchange.com/questions/8260/loading-scripts-on-specific-pages/

It was my impression, that both wp_print_scripts and wp_print_styles were front facing page actions that occur at a time equivalent to their admin counterparts and a query was raised by Rarst whether this is an appropriate place for enqueues..

The codex also suggests init as appropriate for enqueues.

Warning: You can only use conditional query tags on or after the init action hook in WordPress. For themes, this means the conditional tag will never work properly if you are using it in the body of functions.php, i.e. outside of a function.

I decided to write a PHP class as an example to get the results of hooking onto different actions because i was sure init was too early.

	class conditional_tags_check {
		private $results = array();
		public function __construct() { 
			add_action( 'wp_head',            array( $this, 'conditional_check' ) );
			add_action( 'template_redirect',  array( $this, 'conditional_check' ) );
			add_action( 'wp_enqueue_scripts', array( $this, 'conditional_check' ) );
			add_action( 'wp_print_styles',    array( $this, 'conditional_check' ) );
			add_action( 'wp',                 array( $this, 'conditional_check' ) );
			add_action( 'init',               array( $this, 'conditional_check' ) );
			add_action( 'wp_print_scripts',   array( $this, 'conditional_check' ) );
			add_action( 'wp_footer',          array( $this, 'output' ) );
		}
		public function conditional_check() {
			$action = debug_backtrace();
			$action = $action[2]['args'][0];
			$this->results[] = "$action :" . ( is_page() ? 'yes' : 'no' );
		}
		public function output() {
			echo implode( "\n<br />", $this->results );
		}
	}
	$conditional_tags_check = new conditional_tags_check;

I’ve purposely put the add action calls into a random order so you can see the natural order of the actions appear in the results(naturally the action occuring first will be the first result, and so on..).

The results for me came out as.

init :no
wp :yes
template_redirect :yes
wp_enqueue_scripts :yes
wp_print_styles :yes
wp_print_scripts :yes
wp_head :yes 

Init is the only action that fails the test, and shows “no”, where as all others appear to run late enough to determine the request is for a page(i was of course viewing a page). The above conditional tag could be replaced by any other and replicated to show that under each condition init fires too early to determine the kind of request(page, category, tag, single, etc..).

For reference the actions shown above fire in this order.

1. init
2. wp
3. template_redirect
4. wp_print_styles
5. wp_print_scripts
6. wp_enqueue_scripts
7. wp_head

Can anybody see any problems with the test code or disagree? Drop me a comment..