DEV Community: Jackson Lewis

TIL: HTML tags edition

Jackson Lewis — Thu, 22 Apr 2021 16:01:23 +0000

I have a week off work, whey! And what better way to spend some of it then refreshing my knowledge of HTML tags. Now before you go bashing the keyboard labelling me a madman, hear me out. I feel HTML is deemed as 'the basic one' when people refer to programming languages, like you learn it on your first day then that's it, forever...

Here's 10 -ish tags I've found that I wanted to share, enjoy!

`<dl>`, `<dt>` and `<dd>`

First up is more of a 3-in-1, where <dt> and <dd> are descendants to <dl>. The Descriptive List element, contains a collection of terms <dt>, and descriptions <dd>. Let's look at an example:

<dl>
  <dt>Client</dt>
  <dd>Apple</dd>

  <dt>Role</dt>
  <dd>Web development</dd>

  <dt>Year</dt>
  <dd>2019</dd>
</dl>

MDN: Descriptive List element

`<del>`, `<ins>`

The Deleted Text element, along with its <ins> counterpart, highlight when text has been deleted, or added to the document respectively. You can also pass a datetime attribute on both to signify a date/time when the contents within the tag were deleted or inserted.

<p>It was a <del>sunny</del><ins>rainy</ins> day.</p>

MDN: Deleted Text element

`<address>`

Now I did find this one cool, it signifies that the HTML inside provides contact information.

<address>
  <p>Westminster, London SW1A 1AA</p>
    <a href="mailto:info@example.com">info@example.com</a>
  <a href="tel:02056123456">020 5612 3456</a>
</address>

MDN: Contact Address element

`<time>`

A way to specify a date or time in a more machine readable way. Could be great for including on your date stamp of a blog post.

<p>Tickets will go on sale <time datetime="07-06-21">Monday 7th June</time></p>

MDN: Time element

`<fieldset>`, `<legend>`

The Field Set element represents a collection of HTML form elements, which can be logically grouped. This may be handy where you have a quote form with multiple sections, and you can define the sections by <fieldset>. The <legend> tag is a label to the overall <fieldset>.

A neat trick is that you can pass the disabled attribute to the <fieldset> tag, which causes all form elements inside to also be disabled.

<form>
  <fieldset>
    <legend>Your details</legend>

    <input type="text" name="name" />
    <input type="email" name="email" />
    <input type="tel" name="phone" />
  </fieldset>
</form>

MDN: Field Set element

`<optgroup>`

I did actually discover this one a few months back, however it's too good not to share anyway! If you have a <select> element with a load of options, which could be split up into groups, then this is for you!

<select>
  <optgroup label="Audi">
    <option>A3</option>
    <option>A5</option>
    <option>Q5</option>
  </optgroup>
  <optgroup label="BMW">
    <option>1 series</option>
    <option>3 series</option>
    <option>X4</option>
  </optgroup>
</select>

MDN: element

`<output>`

I love this, if you say have a quotation form that takes user input and spits out some sort of calculated result, that's exactly what <output> is for!

<form>
  <input type="number" name="mileage" id="mileage" />

  <p>Miles remaining: </p>
  <output name="remaining-miles" for="mileage"></output>
</form>

MDN: Output element

`<datalist>`

While I can't see myself coming to use this very often, it's still good to know it's there, in the corner, waiting... You could think of it like being a <select> element, but you can type in your own value if you wish.

<form>
    <input list="parts" name="part" />

    <datalist id="parts">
      <option value="Water pump" />
      <option value="Battery" />
      <option value="Spark plug" />
      <option value="Front brake disk" />
    </datalist>
</form>

MDN: Data List element

`<progress>`

Again, limited use-cases yet still keeping it tucked away. Fairly self explanatory, the progress element indicates the progress of any given task. Perhaps you're running a process on a server and want to keep the user updated when it'll be complete?

If you wanted greater styling control, you could probably do something like how custom radio buttons work, where the main element (<progress>) is visually hidden and you use a <div> for the visual. Just remember to get your aria attributes correctly defined so it's all accessible!

<progress id="upload-status" max="100" value="30">30%</progress>

MDN: Progress Indicator element

Well there we have it! Who'd have thought refreshing my knowledge of mere HTML tags would prove so rewarding... Thanks for reading!

Photo by Valery Sysoev on Unsplash

How to preload images in WordPress

Jackson Lewis — Mon, 19 Apr 2021 16:11:54 +0000

Isn't it fun, the never ending game of web performance! This post will be looking using preload on images, and more specifically at preloading the featured image of a WordPress post. So let's get stuck in.

Preload featured image of a post

/**
 * Preload attachment image, defaults to post thumbnail
 */
function preload_post_thumbnail() {
    global $post;
    /** Prevent preloading for specific content types or post types */
    if ( ! is_singular() ) {
        return;
    }
    /** Adjust image size based on post type or other factor. */
    $image_size = 'full';

    if ( is_singular( 'product' ) ) {
        $image_size = 'woocommerce_single';

    } else if ( is_singular( 'post' ) ) {
        $image_size = 'large';

    }
    $image_size = apply_filters( 'preload_post_thumbnail_image_size', $image_size, $post );
    /** Get post thumbnail if an attachment ID isn't specified. */
    $thumbnail_id = apply_filters( 'preload_post_thumbnail_id', get_post_thumbnail_id( $post->ID ), $post );

    /** Get the image */
    $image = wp_get_attachment_image_src( $thumbnail_id, $image_size );
    $src = '';
    $additional_attr_array = array();
    $additional_attr = '';

    if ( $image ) {
        list( $src, $width, $height ) = $image;

        /**
         * The following code which generates the srcset is plucked straight
         * out of wp_get_attachment_image() for consistency as it's important
         * that the output matches otherwise the preloading could become ineffective.
         */
        $image_meta = wp_get_attachment_metadata( $thumbnail_id );

        if ( is_array( $image_meta ) ) {
            $size_array = array( absint( $width ), absint( $height ) );
            $srcset     = wp_calculate_image_srcset( $size_array, $src, $image_meta, $thumbnail_id );
            $sizes      = wp_calculate_image_sizes( $size_array, $src, $image_meta, $thumbnail_id );

            if ( $srcset && ( $sizes || ! empty( $attr['sizes'] ) ) ) {
                $additional_attr_array['imagesrcset'] = $srcset;

                if ( empty( $attr['sizes'] ) ) {
                    $additional_attr_array['imagesizes'] = $sizes;
                }
            }
        }

        foreach ( $additional_attr_array as $name => $value ) {
            $additional_attr .= "$name=" . '"' . $value . '" ';
        }

    } else {
        /** Early exit if no image is found. */
        return;
    }

    /** Output the link HTML tag */
    printf( '<link rel="preload" as="image" href="%s" %s/>', esc_url( $src ), $additional_attr );
}
add_action( 'wp_head', 'preload_post_thumbnail' );

Breakdown

There's a fair bit going on here, so let's break it down and go through the process.

if ( ! is_singular() ) {
    return;
}

The first if statement aims to prevent any preloading from taking place if any given condition is met. Perhaps you don't want to preload the featured image of a post that belongs to a certain post type, or just a specific page template.

$image_size = 'full';

if ( is_singular( 'product' ) ) {
    $image_size = 'woocommerce_single';

} else if ( is_singular( 'post' ) ) {
    $image_size = 'large';

}
$image_size = apply_filters( 'preload_post_thumbnail_image_size', $image_size, $post );

Here we set the size of the image we want to load. This is actually very important, because if we preload the wrong size image, we waste user data. It's worth noting that auditing tools like Lighthouse will probably scream at you too! So it's vital that the image size requested here matches the size requested on the corresponding template.

You could be fancy and create some form of an API, where this function to preload and the function that outputs the image tag are in the same place such as within a class. It could allow you to define in one place the image size and enforce consistency.

$thumbnail_id = apply_filters( 'preload_post_thumbnail_id', get_post_thumbnail_id( $post->ID ), $post );

/** Get the image */
$image = wp_get_attachment_image_src( $thumbnail_id, $image_size );
$src = '';
$additional_attr_array = array();
$additional_attr = '';

Next we set the ID of the attachment, which by default is that of the featured image (also known as the thumbnail). We then call wp_get_attachment_image_src(), passing our $thumbnail_id and $image_size. You'll see we also setup some variables which we'll be using in the next step.

if ( $image ) {
    list( $src, $width, $height ) = $image;

    /**
     * The following code which generates the srcset is plucked straight
     * out of wp_get_attachment_image() for consistency as it's important
     * that the output matches otherwise the preloading could become ineffective.
     */
    $image_meta = wp_get_attachment_metadata( $thumbnail_id );

    if ( is_array( $image_meta ) ) {
        $size_array = array( absint( $width ), absint( $height ) );
        $srcset     = wp_calculate_image_srcset( $size_array, $src, $image_meta, $thumbnail_id );
        $sizes      = wp_calculate_image_sizes( $size_array, $src, $image_meta, $thumbnail_id );

        if ( $srcset && ( $sizes || ! empty( $attr['sizes'] ) ) ) {
            $additional_attr_array['imagesrcset'] = $srcset;

            if ( empty( $attr['sizes'] ) ) {
                $additional_attr_array['imagesizes'] = $sizes;
            }
        }
    }

    foreach ( $additional_attr_array as $name => $value ) {
        $additional_attr .= "$name=" . '"' . $value . '" ';
    }

} else {
    /** Early exit if no image is found. */
    return;
}

This step is a little chunkier that the others, but what's going on is fairly simple. Most of what you see here is directly copied out of the core function wp_get_attachment_image(), the function used to output the <img> tag of an image. So, what it does is it calculates the srcset and sizes for the image, based on the $image_size provided. The reason we're using almost a direct copy of the code is simple, consistency. It's very important we have that when working with preload. From here we build up an array of HTML attributes which will be used in the final step.

printf( '<link rel="preload" as="image" href="%s" %s/>', esc_url( $src ), $additional_attr );

With the image we want, and having collated the necessary attribute values based on the image size, we can output the <link> tag to preload the image.

Filters

You'll notice there are two filters, one for the $thumbnail_id, and another for the $image _size. The purpose of these is that it is entirely possible for an image that isn't the featured image to be important enough that it should be preloaded. These filters allow you to change the ID of the attachment that is to be preloaded.

If you were using this directly in a theme for instance, you wouldn't need to use them, you could directly modify the function. I just wanted to show how it would be done if this were a plugin or part of a theme you couldn't actively modify.

Use preload responsibly

Now before you go and try to preload for yourself, it's important we quickly understand what the concept of preload is and how exactly it works. Preload lets you tell the browser what resources are critical and should be fetched as soon as possible, without having to wait for them to be discovered in the HTML, CSS or JS. You can learn more in-depth with this article on web.dev, as I want to focus more on using preload in WordPress.

If you try to preload too many resources, the concept of preload almost becomes obsolete because if you define everything as important, it all automatically becomes not important...

Usage of preload for WordPress

From our function above, we're only using it to preload the featured image of a post. As the majority of the time, any image above the fold is most likely to be just that. However, that's not to say there won't be instances where there's an image above the fold that isn't a featured image. In this scenario, we could utilize the filters as mentioned earlier to change the attachment ID of the image we want to use. For example, maybe for a template you're not using the built-in featured image, but an ACF image field instead. Well you could simply do something like the following:

add_filter( 'preload_post_thumbnail_id', function( $thumbnail_id, $post ) {

    if ( get_page_template_slug( $post ) == 'templates/home.php' ) {
        $thumbnail_id = get_field( 'banner_image' );
    }

    return $thumbnail_id;
}, 10, 2 );

In the above code snippet, if the page has a template with the slug templates/home.php, we change the $thumbnail_id to use the value from an ACF field instead.

Preload multiple images?

This is a question which may have sprung to mind. In this case, you may want to abstract much of the function so that you can run it multiple times. Perhaps you'd want to create an array of associative arrays, and loop over that and output the <link> to each image. I won't get into that for this post, although I could add it in if you would find it beneficial!

The results

Now for the important question, did it actually make a difference? Well, yes! Below we have a comparison, the before is, well, before preloading the featured image. And after is, obviously, after we added preloading.

To make this comparison, I've used the Filmstrip on webpagetest.org. The test was with Mobile on a slow 3G connection. As, when it comes to performance, these are the network connection speeds where it really matters.

In each frame, the ones with the red border are when the Largest Contentful Paint fully rendered on the page. You can see preloading the image made the image fully render on the page a whomping 4.5 seconds sooner! You may also notice that when preloading was added, the LCP image rendered in all at once, as opposed to progressively loading as seen before. This is because, when it came to rendering the image, it had already been fully downloaded, so was just a matter of rendering.

However, during my testing I noticed a downside, and that was that it prioritised fetching the image over critical stylesheets. This ultimately increased the time before anything was rendered in the page, commonly known as First Contentful Paint. So it's important to be mindful of any potential side effects when preloading resources, as you could be doing more harm then good!

Photo by John Baker on Unsplash

What is headless WordPress - an in-depth comparison

Jackson Lewis — Thu, 15 Apr 2021 10:25:56 +0000

Ah WordPress, the Content Management System that powers over 40% of the web. I think it's fair to say there is a big market for it. Now over the past few years, it seems something else has started to take the web dev scene by storm, JAMstack. This has lead to a new way of building the web of the future, and even WordPress is invited along for the ride!

But it's not WordPress quite as you know it, oh no, this is headless WordPress.

What is headless WordPress?

This is the principle of using WordPress with a decoupled frontend, where content is queried via an API such as REST or GraphQL (WPGraphQL), then displayed on the frontend.

Why might you want to use WordPress as a headless CMS?

The tech industry is moving at a phenomenal speed, and more specifically, websites and apps built with JavaScript-powered libraries and frameworks are starting to become the norm. Now then, WordPress was created way back in 2003, built on PHP. The platform has come along way, and it too has adopted some of this modern tech, with its Gutenberg block builder using React. However, you still remain within the confinement of a PHP based frontend.

Now that we understand what headless WordPress is, we should quickly remind ourselves how a traditional WP frontend works. This will help us draw up a comparison at the end!

The traditional way

If you've ever built a WordPress site, there's a good chance it was built traditionally, where all the code you write is in a theme. The theme controls what happens on both the backend and the frontend, it's where you'll have all your page templates, CSS and JavaScript.

Now we're not going to go in-depth on exactly what the setup of a WP theme is, as that's out of the scope of this post. You can find out more about themes over on the official WordPress Theme Handbook.

There are many many ways of working with a theme, you could be using a pre-built theme with lots of templates to choose from, that probably uses a page builder like Elementor. Or you could be building a custom theme that is bespoke to the needs of a project. Whatever the case, the fundamental structure is always the same, and therein lies the problem for many.

The headless way

Using WordPress as a headless platform does away with following the 'rules' of WordPress theme development. Long gone are the days of using the likes of a header.php, footer.php and style.css. You are free to structure the site however you please, which allows for a more tailored project, opening possibilities not previously available to a WordPress site.

Now before you get too excited and hit that ctrl + alt + del on a theme, WordPress still actually needs a theme in order to function. And your swanky new headless frontend may require some custom backend logic, or modify the WP admin to some degree.

So you could either use a default theme, Twenty Twenty One, or you could create your own barebones theme starting out with only the necessary file. I find it easier to have a barebones theme setup rather than using a default theme, as for one, you're not going to be making any use of 90% of the features of the theme, and two, you'd have to make a child theme for any custom bits anyway.

An example of something that you will still need the theme for is to register menu locations and custom post types. These items are backend logic and should be done the same way as if you were building a traditional site. Anything that is backend logic, you probably won't need to change how you work with, unless said logic needs to expose some data to the frontend that won't be handled by an existing mechanism.

So, now that we have a grasp on the idea of a headless frontend, and we refreshed our brains on the traditional way with themes, let's put the two head-to-head.

Comparison time

Pros of headless WordPress

Full control over the technology used on the frontend, from React to Vue to Angular. This factor alone is game changing to many, allowing endless possibilities for how the frontend is created. For example, if you only wanted a simple blog site, you may be best using an SSG like Eleventy or Gatsby. Whereas if you're working on a large commerce site, Next.js would be a better fit for scalability. This control over tech stack used all ties into the Developer Experience, which I always believe plays a massive influence in the success of any project.
Enhanced security by going headless allows your frontend to be hosted away from the WordPress installation. This is great for many many reasons, like someone can't just do example.com/wp-admin as the frontend isn't within a WordPress installation. It also protects against the likes of DDoS attacks.
Hide the CMS source completely, something that is theoretically possible, dependant on your setup. Providing you don't make any client-side API calls directly to the CMS, and if you alter the directory structure to images, it is plausible to totally mask the fact you're using WordPress or any CMS for that matter. This could be very welcoming news to those always looking to improve security.

Cons of headless WordPress

Reduced extendability. WordPress is well known for it's large eco-system of plugins, which allow you to easily extend the functionality of your website in one way or another. However when you go headless, many of these plugins will seise to work as intended. The reason being, these plugins are only built to work with traditional WP, whereby any frontend code is 'hooked' onto frontend template actions. So with headless, the actions are never run as they are never called as there are no PHP page templates. For example let's take Yoast SEO, one of the biggest plugins out there. Now all the meta data Yoast outputs to a page <head> is done so through the wp_head action. As this is the only means of outputting any meta data Yoast understands, we turn out attention to fix that. Now it is possible via WPGraphQL, using add-on plugins to expose a plugins data to the API, for us to query on the frontend. Luckily, there is an add-on plugin to Yoast SEO which allows just this. This is only one example, not all plugins have dedicated add-ons to extend to the GraphQL API.
Forces an alternative hosting setup. With a traditional site, the frontend and backend exist coupled together in a single place on a server. So when you go headless, you can't have the frontend inside the WP installation. Instead, top recommendations are to use a dedicated hosting platform for these types of websites. Welcome the likes of Netlify or Vercel. These have super simple setups to get a project up and running, taking care of of pretty much everything including free SSL's. You are free to host the WP installation wherever you please. This one isn't as much of a big deal, but still something you should be aware of as both Netlify and Vercel are paid if you want to use commercially.

From this in-depth look into the pros and cons of headless WordPress, it's important to make sure you're aware of what you're getting yourself, your team and maybe your client into. As, failure to clearly outline what headless means for a project, could leave you in a sticky situation.

To conclude, is headless the way to go? In my book, yes, most definitely. I believe the pros far out way the cons, in terms of both the possibilities it opens and future-proofing. As mentioned above, it is so important to make it clear to those it will affect, that a site is headless. Failure to communicate this could be devastating. Your manager or the client may know you're building a WordPress site and think that's great, and look forward to extending the site with various plugins etc... Little would they know that a headless site takes away much of this extensibility. On the flip side, if this isn't an issue and everyone is on the same page and understands the benefit of going headless, then you're onto a winner!

Using toLocaleString to display prices in your application

Jackson Lewis — Tue, 02 Mar 2021 12:07:52 +0000

If you have an application that display prices anywhere, such as an ecommerce store, it's very important that those prices are being correctly formatted. As it could cause a real headache if it were to go wrong, particularly if your application needs to support multiple languages and/or currencies.

That's where toLocaleString() comes into play. This method formats number values based on a language code. What's more, you can pass options to specify the style of the number, like a currency!

Let's take a look at how it works.

Using `toLocaleString()` for currencies

This method can be used for various means of formatting numbers, including when a number needs to be displayed as a currency. Below is the simplest example of using toLocaleString() to display a number as a currency.

// The data
const price = {
    currency: 'GBP',
    amount: 4.99
};

// toLocaleString options
const options = {
    style: 'currency',
    currency: price.currency
};

price.amount.toLocaleString( 'en-GB', options );
// £4.99

Example

Let's go through a step by step example of how we might use this method of displaying a price in a JavaScript application, we'll be using React for this example, however this will work for any website or application that uses JavaScript.

Firstly, let's check out the data we're going to be using.

/**
 * This could be the data object of a product, which contains a price object
 */
const product = {
    ...,
    price: {
        currency: 'GBP',
        amount: 4.99
    },
    ...
};

// Current langauge - this could be set on a backend system and stored globally
const language = 'en-GB';

Now that we have the price data we need, and know what language it should be formatted for, we can create a function that's going to format the data to display a price.

/**
 * Format a price amount based on language and currency
 *
 * @param {object} price The price object
 * @param {string} price.currency The currency to use
 * @param {number} price.amount The raw price amount
 * @return {string} The formatted display price
 */
function formatMoney( price = {} ) {
  return price.amount?.toLocaleString(
    language || 'en-GB', // Provide a default value as a precaution
    {
      style: 'currency',
      currency: price.currency || 'GBP' // Provide a default just in case
    }
  );
}

Perfect! So we pass a price object to the function as the price parameter, and directly return the amount which will get formatted based on the pre-defined language and the currency which is defined within our price object.

You'll also notice from the code snippet above, that we provide fallback values for the language and currency. While this isn't required, it may be a good idea if you believe it's possible either may not be passed a value by their respective variable. It just prevents your app from not displaying a price at all, which would not be good news!

What's so handy about having such a simple function like this is that we can use it everywhere in an ecommerce application. From the product page, to the cart and viewing customer orders, wherever there is a price to display, we'd use this function to correctly display it, as if enforces consistency across our application.

So now let's bring all this together to display a price on the frontend of our application, which will look a little like the following.

/**
 * Render the price on our component
 */
const Product = () => (
  <div>
    <p className="price">{ formatMoney( product.price ) }</p>
  </div>
);
ReactDOM.render( <Product />, document.getElementById( 'root' ) );

It's worth mentioning we're only using React for the example here. As toLocaleString() is native JavaScript, you can apply this to any application where JavaScript is used.

Other methods

Let's not forget, this is the world of web development, meaning there are usually many ways of getting to the same result. If toLocaleString() doesn't float your boat, you may want to take a look at Intl.NumberFormat. Here's how that may look:

new Intl.NumberFormat( 'en-GB', {
    style: 'currency',
    currency: 'GBP'
}).format( 4.99 )
// £4.99

Check out the full working example over on CodePen. Thanks!

Why I built my own WordPress theme

Jackson Lewis — Tue, 23 Feb 2021 15:40:42 +0000

With the WordPress eco-system flooded with themes, it's easy to get fixated on the idea that you have to use one that is already out there. But if you think about it, these themes are generic and are made for the general community, and not your individual style. So I took matters into my own hands and built a theme from the ground up, tailored to my own needs.

Let's follow the journey of the decisions made that led to the creation of my own WordPress theme!

Framework's aren't for me

I don't know who needs to hear this, but it's ok to not use frameworks/libraries if you don't like them. For me, I absolutely hated the idea of all the unused code from parts of the framework that I wouldn't plan on using.

Now you may be thinking, "Aren't we meant to be talking about WordPress themes?!". And yes, we are, however a framework is at the core of a theme. So it was a good idea to think about this first when going about creating a theme.

Now that I understood why I didn't want to use a framework for the fundamental HTML/CSS structuring, I began creating my own, but one that would solve the issues I have with existing frameworks.

Understanding what I wanted out of a theme

Moving onto the actual WordPress side of things, this would be where the theme would be tailored into something that could get the most out of. I had lots of ideas for things like helper functions that would reduce repetitive tasks such as calling an image on a template, or pre-built segments of the page such as a site header.

Here's a list of just a few of the things I specifically wanted:

Various utility functions for calling images on templates - something that really really bothered me was seeing the exact same code for rendering an image dotted about across various templates for a site. It was clear to me this needed resolving with the help of some nifty utility functions, which influenced shiftr_image() and shiftr_featured_image(), with one for general images and the other specifically for post featured images.
Separated configurations for development and production when compiling assets - after some playing around with gulpfile.js, I found that running minification processes on development slowed down compiling times, which lowers productivity. I also felt like source maps are unnecessary in production, and increase the file size of the respective compiled file. So being able to have full control and split particular tasks between development and production environments was a great achievement.
Integration with Advanced Custom Fields - every WordPress site I work on uses this plugin, so it only made sense to make sure it would be as effortless as possible to use it. Some of the utility functions as mentioned above, like shiftr_image(), use ACF functions to easily work with a ACF Image field automatically.

I found having a list of ideas like the above very helpful in understanding what the actual purpose of this theme would be, which gave me more motivated to get the damn thing built!

Hello, Shiftr

First off, I am one of those that absolutely loves naming and branding my personal projects, and my own WordPress theme was no exception. Let me introduce to you Shape Shiftr, or Shiftr for short. This is a WordPress blank starter theme built completely from the ground up with its own CSS/JS framework.

The stack

Shiftr has seen a few big updates since its initial release in early 2019, so to keep it simple, I'll just run over the current, more modern stack in use.

Gulp (v4)- The task runner used for everything while building, from hot reloading with browsersync, to compiling assets.
Webpack - I took the leap and opted for webpack here, so I could utilize ES6 import/exports which has made working with code in multiple files super easy. Some may say I'm crazy, but my love for JavaScript was really taking off at the time so I wanted to be able to use the most modern syntax.

Top features

What I find most rewarding after creating your own theme is then going onto use it in real projects. To date, Shiftr is used in 12 production sites, all built by myself. So over that time I have been my own critic of sorts, finding anything from bugs to improvements that could be made. I'll walk you through a few of the top features that make a real difference to my day-to-day work while using the theme.

Image functions: These are ultimately just wrapper functions to wp_get_attachment_image(), but has made adding images something that I no longer have to think about. I'm just going to quickly say, if you don't have something like this your theme, you seriouslyyyy need it, right now!
SEO-ready: I personally feel it is only fair that every website is built on a foundation that can be easily optimised for SEO. Shiftr includes everything from being optimised for performance to correct semantic layout of headings across templates.
Flexi template: This has to be hands down the biggest success to come out of the theme. Utilizing the Flexible content field in Advanced Custom Fields, I created a template that made it super easy for content creators to add and reorder sections of a page as they needed. This brought convenience and scalability to a site. It has evolved heavily to the point I dedicated a lot of time working on a great little API of sorts making it super easy to add new blocks to the template.

Staying ahead of the game

As mentioned in the previous section, I've tried to update the theme with new features, bug fixes and general touch-ups at least once every few months. I found it really important to stay on top of these updates, because as and when I would either find a bug or think of a new feature, I would end up just copying directly from one project to another, without ever actually putting the code into the source of the theme where it would be instantly available for future projects.

There can also come a time when WordPress catches up with modern tech. For instance, in WordPress 5.5, the core team brought native lazy loading with some help from the team at Google (I suspect). Now Shiftr already had Google's recommended implementation of lazy loading. So, on the working assumption that Shiftr would only be used with the latest releases of WP, I set about removing my lazy loading, as that can now be handled by WordPress itself.

So there we have it, my journey of developing my own WordPress theme that meets my every need. Feel free to check out the code for yourself over on GitHub, you may use it to find inspiration in creating your own theme. Thanks!