If you’ve ever tried to improve a site’s performance on Google’s PageSpeed, you’ve probably seen that one of the “Opportunities” is to “Eliminate render-blocking resources”. These resources are typically CSS and JavaScript files. Usually, it’s not easy to remove/move the CSS resources as this will often result in a FOUC, (flash of unstyled content). However, in most cases, you can get away with moving pretty much all JavaScript to the, as long as you’re not using it to style the content in the viewport (usually this is the “above-the-fold”), so let’s do that!

How to Move Common JavaScript Resources to the Footer

First, let’s look at the most common of JavaScript resources; jQuery. Even though jQuery isn’t as popular as it once was, it’ll be around for the foreseeable future as a vast number of JavaScript solutions are built on top of it. Plus, it’s been baked into WordPress for many years, too!

Here are 3 ways to move it to the footer and the logic used here can be used with other JS libraries, too.

1. Add data to the enqueued scripts

Using wp_scripts->add_data(), this will add the a key/value pair (‘group’ and 1) to the targeted script. Note that ‘group’ is WordPress’s way of determining if the script goes in the head or footer, 1 will put in in the footer. key/value (group/1):

add_action('wp_enqueue_scripts', function() {
    wp_scripts()->add_data('jquery', 'group', 1);
    wp_scripts()->add_data('jquery-core', 'group', 1);
    wp_scripts()->add_data('jquery-migrate', 'group', 1);
});

2. Dequeue existing scripts and enqueue new scripts

This approach is handy if you want to change the source, such as loading from a CDN:

function dequeue_head_scripts_enqueue_footer_scripts() {
    wp_deregister_script('jquery');
    wp_register_script('jquery', 'https://cdnjs.cloudflare.com/ajax/libs/jquery/3.5.1/jquery.min.js', false, null, true);
    wp_enqueue_script('jquery');
}
add_action('wp_enqueue_scripts', 'dequeue_head_scripts_enqueue_footer_scripts', 10);

3. Move all scripts out of the head

This way move all JS out of the head and into the footer but feels a little extreme with no granular control:

function move_scripts_to_footer() {
    remove_action('wp_head', 'wp_print_scripts');
    remove_action('wp_head', 'wp_print_head_scripts', 1);
    remove_action('wp_head', 'wp_enqueue_scripts', 1);
}
add_action('wp_enqueue_scripts', 'move_scripts_to_footer');

Conclusion

In my opinion option one is the best fit (even though it feels a little ugly retrospectively changing it using ‘group’), as there’s no need to remove the default jQuery and you can keep tight control over which scripts are in the head and which are somewhere else. If you’d like help with this, or you have an odd edge case where none of these approaches are working, then please get in touch.

Many plugins inject unnecessary HTML comments into the page’s source code. Let’s look into ways we could remove them.

Why do you want HTML comments in the first place?

It is a pet hate of mine that HTML gets flooded with unnecessary tripe, such as comments that relate to a section of the HTML. In WordPress loads of plugins dump this crap into the page, but why? In my opinion, as a programmer, a live site is no place for this bloat. Sure, if you feel the need to output them for debugging purposes, in development/staging, then do so – though I’m still not sure why you would, as there are proper debugging tools and techniques for that. But a live site should be optimised; only transmitting data that are necessary for the presentation and functionality of the site, so let’s try to achieve that.

How can these HTML comments be removed?

There’s more than one way to remove these comments, and, in some cases, the best solution is to stop them being created in the first place, but that’s not so easy when you don’t always have control over third-party code that’s creating them.

Yoast, a third-party plugin for SEO, have provided us with a way to achieve this. Here’s an example of how to remove comments that Yoast injects:

/**
* Disable Yoast's comments
*/
add_action('template_redirect', function () {
    // abort if the class doesn’t exist
    if (!class_exists('WPSEO_Frontend')) return;

    // set probable method (Yoast updates this from time-to-time)
    $method = ‘debug_mark’;

    // get instance
    $instance = WPSEO_Frontend::get_instance();

    // abort if the method doesn’t exist
    if (!method_exists($instance, $method)) return;

    // remove the method
    remove_action(‘wpseo_head’, [$instance, $method], 2);
}, 9999);

Note that the code above is fairly volatile, as it will only work if Yoast doesn’t change the classes and hooks being called.

Remove all HTML comments

The above code snippet only addresses the comments in the head tag by a single plugin. There are techniques to remove all comments from the page. One way is to buffer all the page’s source code and use a regular expression to remove anything between <!-- and --> before outputting the buffer’s contents. Personally, I don’t think this is a nice solution, as it will probably slow your site unless you cached the results, nonetheless, here’s a theoretical solution (untested):

/**
 * Callback function to remove HTML comments
 */
function buffer_callback($buffer) {
    return preg_replace('/<!--(.|s)*?-->/', '', $buffer);
}

// start buffer at the site's head
add_action('get_header', function () {
    ob_start('buffer_callback');
});

// end buffer and flush after the WP Footer's content's been collected
add_action('wp_footer', function () {
    ob_end_flush();
});

Are There Other Ways to Clear Out the Noise?

Whilst searching the entire document for specific strings of characters isn’t ideal, it is a solution. Alternatively, we could investigate ways that prevent the creation of them in the first place, but that’s easier said than done. If I create one I’ll share my findings.

If you have a suggestion or you’d like to discuss implementing something like this on your site, then please get in touch.

Recently, I’ve had a couple of projects that require thumbnails for video posts. There are plugins out there to do this, but I wanted a simple, lightweight way. Good news is, this can be achieved very easily by making use of WordPress’s WP_Embed class.

/**
 * Maybe get thumbnail from embed
 *
 * @param string $string
 * @return bool
 */
function get_embed_thumbnail_from_string_maybe ($string) {

    $found = preg_match_all('|^\s*(https?://[^\s"]+)\s*$|im', $string, $matches);
    if (!$found) return false;

    // nb: this can be used if we're just checking an embed exists and is supported
    //foreach ($matches[1] as $match) if (wp_oembed_get($match)) return $match;

    $embed = new WP_oEmbed();
    foreach ($matches[1] as $match) {
        if ($embed->get_html($match)) {
            return $embed->get_data($match)->thumbnail_url;
        }
    }
    return false;
}

Place the code above in a custom functionality class or, for a crude option, dump it in the functions.php file and call it when a thumbnail of the first video in a string is required. An obvious use case is the blog archive page when displaying thumbnails with each post link.

We develop custom WordPress solutions. If you have any advanced WordPress requirements, including custom themes, plugins or theme modifications, please let us know.

Code to Remove Meta Boxes from Specific Pages

add_action('do_meta_boxes', function() {
    $post_id = $_GET['post'] ?? ($_POST ?? false);
    global $edit_post_id;

    // just call it once - don't repeat yo'self!
    if ($edit_post_id !== $post_id) {
        global $post;
        $edit_post_id = $post_id;

        // array of pages that will exclude the meta box(es)
        $exclude_on_pages = [
            'home'
        ];

        // remove the meta box(es) from the specific pages
        if (in_array($post->post_name, $exclude_on_pages)) {
            remove_meta_box('postimagediv', 'page', 'side');
        }
    }
});

Conclusion

Plonk this in a plugin or your theme’s codebase and you’re good to go. Or, if you would like to know more about how you can control the meta boxes on your website, check out these posts on how to move meta boxes and how to move the Yoast meta box down, or read the official WP documentation on <a href="https://developer.wordpress.org/reference/functions/do_meta_boxes/" target="_blank" rel="noopener noreferrer">do_meta_boxes()</a> and  remove_meta_boxes() If you have any questions or would like help with WordPress related challenges, call us and we’ll gladly help.

On a client site, we wanted to restrict menu items to Custom Links, only. Thus remove all other menu types. The main drive behind this was to improve the user experience and reduce confusion, as the menu is only for Social Links.

With a brief search yielding very little I set about coding a solution, by hooking into the admin_head action. But before we get into the code, let’s review what we need to do.

Scenario: Only display Custom Links

When the current screen is the Menu screen and the selected menu is social_navigation, conditionally remove all link types except Custom Links. To do this we need to:
– get the current screen
– get the currently selected menu
– check if the current menu is the social_navigation menu
– get a list of all link types
– remove all links that aren’t Custom Links

Get the current screen

This one’s easy, we append -nav-menu.php to the add_action hook:

add_action('admin_head-nav-menus.php' ...);

Now, the action will only fire when we’re on the menu screen of the admin area.

Get the currently selected menu

Though, not a straightforward as above, we can get this form the globally scoped variables, in the form of the menu’s id:

global $nav_menu_selected_id;

Next we’ll use this to check if the current menu is social_navigation.

Check if the current menu is the Social Menu

This is a little fiddly, as we need to compare the id from $nav_menu_selected_id with the id of the Social Menu. So first, lets get a list of available menus, then we can compare their id‘s with $nav_menu_selected_id. For this I’ll grab another global variable:

global $menu_locations;

Then compare the id of social_navigation with $nav_menu_selected_id to see if we’re currently viewing the Social Menu.

Get a list of all link types

Another global variable comes to the rescue here, $wp_meta_boxes. This is a multidimensional array of all meta-boxes, including the nav-menus. So everything we need is in $wp_meta_boxes['nav-menus']['side'] (we only need side as all nav-menu meta-boxes are of side context):

global $wp_meta_boxes;
// $wp_meta_boxes['nav-menus']['side'] holds all the nav-menus

Remove all links that aren’t Custom Links

All we need to do is loop through the $wp_meta_boxes['nav-menus']['side'] array and conditionally remove the link type if its id doesn’t match add-custom-links:

foreach ($wp_meta_boxes['nav-menus']['side'] as $nav_menus) {
    foreach ($nav_menus as $nav_id => $nav_menu) {
        if ($nav_id !== 'add-custom-links') {
            remove_meta_box($nav_id, 'nav-menus', 'side');
        }
    }
}

And that’s it. Here’s the full code, copy an paste this into your functions.php file, or better still, a functionality plugin, modify it to suit your needs and you’re good to go:

/**
 * Remove nav menu meta-box links from the 'social_navigation' menu
 *
 * NB:  all nav menus are $context 'side'
 *
 *      use var_dump(wp_list_pluck($nav_menus,'id'))
 *      inside the outer loop to display a list of all link type IDs
 */
function custom_remove() {
    global $wp_meta_boxes, $nav_menu_selected_id, $menu_locations;

    // store the id of the social menu
    $social_nav = $menu_locations['social_navigation'] ?? false;

    // if the current menu id is the social menu's then let's do this
    if ($social_nav === $nav_menu_selected_id) {

        // loop through the 'core' and 'default' arrays 
        foreach ($wp_meta_boxes['nav-menus']['side'] as $nav_menus) {

            // loops through their menus
            foreach ($nav_menus as $nav_id => $nav_menu) {

                // remove the menu's meta-box if it isn't the one we want to keep
                if ($nav_id !== 'add-custom-links') {
                    remove_meta_box($nav_id, 'nav-menus', 'side');
                }
            }
        }
    }
}
add_action('admin_head-nav-menus.php', __NAMESPACE__.'\\custom_remove', 10);

Note: We namespace our environment for conflict avoidance, hence the __NAMESPACE__ prepended function call.

Conclusion

This is a really nice bit of code for improving the user experience and keeping control of your menus. I especially like it because it’s pretty lightweight, too!

If you have any questions, or have a particular programming challenge, especially with WordPress, please get in touch and we’ll gladly help, as we’re seasoned in WP – designing and building custom themes and plugins. And love a challenge.

Recently, I had an odd scenario where wrapping long text needed either word-wrap, overflow-wrap or word-break to achieve the same overflow pattern across different browsers. To arrive at a suitable solution I opted to use @supports to maintain control of the declarations.

What is @supports?

@supports is a feature query, whose associated block of statments only get triggered when the client (i.e. browser) supports the feature(s), as described on MDN. Here’s a simple example:

/*
 * Test if client supports display: grid 
 */
@supports (display: grid) {
  display: grid;
  float: none;
}

The example above is pretty self explanatory:
Process the enclosed block of declarations if the control declaration is know by the client.

The Problem – text that is too long for the width of its containing box

This is a common webpage layout hurdle, and one that completely breaks the page if not handled with due consideration. Take for example a scenario I’ve seen time and again: horizontal scroll on a mobile device, where the content overflowing to the right of the viewport is completly unstyled, as depicted below (NB: the site in the demo isn’t broken – we’re just demostrating the issue):

Toggle Demo

Using @supports to handle long words

This is an ugly problem. And one that’s often addressed with a combination of hyphens(inc. prefixes) and word-break. Unfortunately, there are times when they don’t cut it. For example, when a hypen isn’t a desirable aethestic, or not all words want breaking.

What I was looking for was a way to break long words, but not hypenate them, and defintely don’t break words that can just fit on the next line. So, through trial and error, I found the following to work perfectly for our use-case, which only passes the relevant declarations to browsers that support them:

/*
 * Break long words
 * Only break words that are too long to fit on one line
 * Uses @supports
 */
h1, h2, h3, h4, article {
  /* doesn't recognise underscored_words on all browsers */
  word-wrap: break-word; 
}
@supports (overflow-wrap: break-word) and (not (word-break: break-word)) {
  /* doesn't recognise underscored_words on all browsers, use if word-break: break-word isn't supported */
  h1, h2, h3, h4, article {
      overflow-wrap: break-word;
  }
}
@supports (word-break: break-word) {
  /* use if supported */
  h1, h2, h3, h4, article {
      word-break: break-word;
  }
}

Conclusion

Using @supports is an elegant way to make us of the tools that fit each of the browsers we need to code for. Sometimes, more-often-than-not, we don’t need to use it. In the case above I could have just let the browser’s decide if they could or couldn’t understand the declarations, but the way I’ve structured it gives me confidence that I’ll get the desired outcomes from the declarations I’ve tested. Plus it gave me a reason to talk about @supports.

This article will demonstrate how to conditionally load the JS and CSS for CF7, but the concept could be adapted to apply to other plugins.

Preventing/dequeuing the script and styles

NB: For the rest of this article I’ll refer to scripts and styles collectively as assets.

The first thing we need to do is stop the default action of the assets being loaded on all pages. A generic way of achieving this would be to find the assets in the $wp_styles and $wp_scripts variable. However, CF7 provides a filter that can be accessed, for which we can just return false, thus not enqueuing anything:

/**
 * Do NOT enqueue CF7 scripts and styles
 */
add_filter('wpcf7_load_js', '__return_false');
add_filter('wpcf7_load_css', '__return_false');

Now the assets will not load on any pages. Our next task is to specify the pages we’d like to load them on.

Conditionally loading assets

For this particular scenario the assets only need to be loaded on the contact page. WordPress has a suitable function to achieve this, is_page(). This function takes the page id, name or an array of the page ids and names. Contact Form 7 states that the functions to load the assets back in need to be called before the wp_head() hook, therefore we’ll call them in get_header(), which is fired just before:

/**
 * Action: Load Contact Form 7 assets into get_header
 */
add_action('get_header', function() {
    // Load assets only on contact pages.
    if (is_page(['contact', 'contact-us'])) {
        if (function_exists('wpcf7_enqueue_scripts')) wpcf7_enqueue_scripts();
        if (function_exists('wpcf7_enqueue_styles')) wpcf7_enqueue_styles();
    }
});

As controlled by the outer if statement, these assets are only being called when the page slug is either ‘contact’ or ‘contact-us’. To extend this to enqueue the assets on other pages simply include the pages in the is_page() arguments, or modify the expression to include further conditionals. For example, assume the sidebar for the blog pages had a CF7 form widget, the control statement could be modified to check if the sidebar is active:

if (is_page(['contact', 'contact-us']) || is_active_sidebar('blog-sidebar'))

Wrapping it up

There are many ways this code could be modified to meet specific requirements, just add it to your theme’s functions.php file (or a functionality plugin) and modify as necessary. The examples in this article are specific to Contact Form 7, for a more generic approach to enqueuing and dequeueing JavaScript and stylesheets refer to WordPress’s wp_enqueue_scripts() documentation, or get in touch with our seasoned WordPress developers.

Schema markup helps search engines understand your content by describing its primary purpose, in a machine-friendly way. The most recent, and in my opinion, the easiest to maintain, is ld+json, which is contained in a script tag, proving the search engines with the key data.

What does ld+json markup look like?

The best way to explain what ld+json markup looks like is with example code, based on the Article type. Below is the code for this post:

{
    "@context": "http://schema.org",
    "@type": "BlogPosting",
    "headline": "the post title",
    "datePublished": "the post date",
    "image": {
        "@type": "ImageObject",
        "url": "the post thumbnail"
    },
    "description" : "the post description/excerpt"
}

As you can see, this is super easy, so get marking up! But you may want to double-check that your post has a featured image and an excerpt, otherwise image.url and description will be empty. One easy way to overcome these is to check a thumbnail exists and use WordPress’s wp_trim_excert() to create an excerpt from the post’s content. Feel free to get in touch if you would a helping hand, as we’re seasoned WordPress developers.

What’s a @media query?

Here’s a simple example of a media query to make the text 10% bigger on devices with a screen (viewport) wider than 768px (the viewport width of the original iPad):

@media (min-width: 768px) {
  p, div {
    font-size: 1.1em;
  }
}

This is a pretty self-explanatory snippet of code:

When the width is greater than 768 pixels relatively resize the font size of paragraph and div tags to 110% of their current size.

Cool, right? But what about if we also wanted to increase the font-size of div tags by a different amount when the height is greater than 1024px? One solution is to use nested media queries.

What are nested @media queries?

Taking the problem described above, here’s an example of nested media queries to make the text within the paragraph and div tags 10% bigger on devices wider than 768px, but with a nested condition to apply an additional rule to div tags when the viewport height is also at least 1024px:

@media (min-width: 768px) {
  p, div {
    font-size: 1.1em;
  }

  @media (min-height: 1024px) {
    div {
      font-size: 1.15em;
    }
  }
}

How about that?! The query is still pretty self-explanatory:

When the width is greater than 768 pixels relatively resize the font size of paragraph and div tags to 110% of the current size. However, if the height is greater than 1024 pixels relatively resize the font size of div tags to 115% of the current size.

Note: there are other ways to achieve this, without nesting the media queries, most obviously is by having separate query groups for paragraph and div tags.

/**
 * Filter: Add feature image to RSS feeds
 *
 * @param $content string   the content
 * @return string           the potentially modified content
 */
function rss_featured_image($content) {
    global $post;

    // if the isn't an associated featured image, then return just return the content
    if (!has_post_thumbnail()) return $content;

    // featured image layout
    $styling = ['style' => 'float: none; margin: auto;'];

    // add a filter to return null for srcset
    add_filter( 'wp_calculate_image_srcset_meta', '__return_null' );
    $featured_image = get_the_post_thumbnail($post->ID, 'medium', $styling);

    // remove the above filter
    remove_filter( 'wp_calculate_image_srcset_meta', '__return_null' );

    // return the featured image and the $content
    return $featured_image . $content;
}

add_filter('the_excerpt_rss', __NAMESPACE__.'\\rss_featured_image');
add_filter('the_content_feed', __NAMESPACE__.'\\rss_featured_image');

Using a plugin or WP developer

Don’t fancy getting you hands dirty with code? Search the WP plugins repo, or get in touch for further help.