DEV Community: Michael O

How to include a custom stylesheet for any given page in WordPress

Michael O — Sat, 04 Jan 2020 01:41:36 +0000

Updated: 28th Feb 2024.

Every byte counts.

One of my biggest pet peeves with website presentation is how inefficient it can be to manage. Specifically, when you load a page, the entire stylesheet will load regardless of how many CSS selectors are actually required to present the current page correctly.

Depending on the size of your CSS file, it not uncommon for any given page to require less than 1% of all the loaded CSS selectors to present correctly. Which mean the other 99% gets loaded anyway.

The method I am about to outline below, while not perfect, can at least reduce the impact of this problem.

The problem we are trying to solve

Sometimes there's a requirement to create a custom landing page for a website, which can require a completely different set of elements and CSS selectors need to be introduced into an additional custom presentation layer (more CSS).

I’ve tackled this a few different ways over the years. A long time ago I would just include the new custom styles in the main stylesheet (adding to the CSS filesize – yuck). Later, I thought it would be smarter to simply make a SASS partial and import it into the main stylesheet, but that doesn't solve the bloat problem. Neither of these methods do anything to reduce the size of the main stylesheet, even if the partial method was a little easier to manage.

Years later, I made a function to include a custom admin metabox in my skeleton theme, which would let me specify the path to a custom stylesheet on pages when I needed one. This is an improvement, because the custom stylesheet would only load on pages where is was required, but still not perfect because in WP admin it was difficult to know which pages were including custom CSS (unless I also added code for an admin column to indicate it, but that's just adding more bloat somewhere else).

I think we can do better, and so today I’ve created something a little more contained that leaves the main CSS untouched.

Prerequisites

For this to work you’ll need:

WordPress to be using permalinks set to anything other than the Plain option.
WordPress to be running on at least PHP 4 in order for the file_exists() function to work.
Access to your theme files.

The code

Paste this into your theme or theme functions.php file:

/* Check if CSS file name matches the slug, and if it does, include stylesheet for that slug */
function check_for_css() { 
    global $post;
    $post_slug = $post->post_name;
    $filename  = get_template_directory() . '/css/' . $post_slug . '.css';
    if (file_exists($filename)) {
        echo '<link rel="stylesheet" id="' . $post_slug . '-css" href="' . get_template_directory_uri() . '/css/' . $post_slug . '.css" type="text/css" media="all" />';
    }
}
add_action('wp_footer', 'check_for_css');

What’s happening here is quite simple. We’re checking for the existence of a CSS file based on the current page slug. For example, if the current page slug is my-custom-landing-page then this function checks your theme /css/ directory for my-custom-landing-page.css and if that file exists, then it outputs the style tag into the footer.

Note that I output my stylesheets into the footer because they are render blocking, but if you prefer to output into the head then change this line...

add_action('wp_footer', 'check_for_css');

...to this...

add_action('wp_head', 'check_for_css');

Summary

Using this function will prevent your stylesheet from gaining unnecessary weight for pages it doesn't need to present, and only load your additional custom stylesheet when it is needed.

How to make a living from WordPress development without violating the GPL

Michael O — Tue, 10 Dec 2019 03:43:35 +0000

Introduction

Much of what is written below has already been covered in interviews ad-nauseum with Matt Mullenweg. And if you’re already ‘pro at GPL’ then there probably isn’t much new you could learn here, unless you’re looking for a refresher course. But for additional insight from a one-man-army developer, read on. You may just learn a thing or two.

A little background

When I first got into WordPress development I was admittedly a bit fuzzy on what my rights were when it came to the subject of selling my work online. I had a vague idea that anything I produced under the WordPress framework was ‘public’ or ‘open’ to some degree, but I didn’t know to what extent.

Not everyone who works with WordPress for a living necessarily knows exactly where they stand relative to the GPL, and depending on who you ask you may get varying degrees of opinions on the subject.

To cite an anecdotal example, I once had a developer email me a few years ago demanding that I “hand over a copy” of the Rocket Apps website theme (the original theme that I do not distribute and that I custom designed and built specifically to market my own products) because, he said – and I’m paraphrasing here – “WordPress is open source and you have to give it to me whether you like it or not” – or some misguided reasoning to that effect. While he was laughably misinformed, it still serves to illustrate that not everyone knows what rights the GPL actually affords those who work within the WordPress ecosystem.

I’m sure other developers have similar stories but in case you’re wondering, you absolutely do not have to hand over a copy of your custom WordPress theme or plugin – under certain conditions (more on this subject later).

WTF is the GPL?

The General Public License (which WordPress utilises) allows users the freedom to run, study, share, modify or even sell any software that is licensed under the GPL. In the context of WordPress this extends to any software that uses the WordPress framework and APIs in order to function and – this is the key distinction – only if you are distributing said software.

The key here is worth repeating: the GPL only applies to software you plan on distributing.

The basic principle is: the same rights that were afforded to you while developing your WordPress software should be inherited by the people using your WordPress software.

In other words, as you were happy to build your software on top of established GPL licensed WordPress APIs, functions, hooks etc, the same license applies to whatever you were able to derive from it. This is a condition of working with any software licensed under the GPL, not just WordPress.

Does this mean you have to give your work away for free?

Absolutely not, but it’s easy to interpret it that way.

As mentioned the GPL affords many freedoms, including the right to sell (distribute) your software to paying customers. But it’s worth keeping in mind that the person who paid money for your software also inherits the right to do exactly the same with it, and neither party can dictate any conditions (aside from keeping a copy of the GPL license with the software).

At this point it’s very easy to form a picture in your head where one person buys a copy of your software and then distributes it to all his friends, and although that’s a legitimate concern and it might feel like piracy, it’s not even close.

So try to think of it this way: When you’re selling your WordPress software you should be selling the value in other areas, instead of just ‘the theme’ or ‘the plugin’. For example, many theme and plugin developers put up a paywall to sell their products and make you enter a license key (which is legit and the GPL is totally cool with it), but in reality what they’re really selling is the support, time and resources that are required to maintain the product for you.

This is something that most customers are willing to pay for because:

it provides reassurance to know they can get support for the product when they need it
the product they paid for will continue to work into the future with updates
they typically don’t have the technical expertise or the budget to roll and maintain their own solution
they may not trust or have had a good experience with any of the free offerings

This is also why it’s important to make sure your potential customers understand what they are getting for their money, such as ongoing software updates, fast support, access to community forums, documentation etc, and make this known when marketing the product. Most customers probably don’t care (or are even aware) that they can share, modify or sell the software they just purchased from you.

Is your original content forced to inherit the GPL?

That’s totally up to you. If you want to employ a different license for the CSS, JS, Images, SVGs, documentation, branding or anything else that is your own original work, you are free to do so. Some developers will offer a separate ‘developer license’ (usually paid for) that will give the user the right to include all your original assets when they share your software.

A good real world example of this happened a few years ago, when Sean Lang forked the excellent commercial Migrate DB Pro plugin on Github, and stripped out the licensing code so everyone could have access to all the pro features for free. It would be easy to interpret this as a dick move, but Lang was well within his rights (as is anyone) because even though Migrate DB Pro is a paid-for product, it is still licensed under the GPL. He did, however, have to remove all instances of copyrighted material owned by the plugin developer.

What about the website you built for yourself or a customer?

If you’re contracted to build a website for a client on WordPress, in this instance the GPL does not apply. The GPL would only apply if you or your client plan on distributing the software, but this is typically not the case when a client has contracted you to build them something that will only be used in a single instance.

That said, if you handed over the software (website files) to your client and they decided to start distributing it, then the software would become bound by the GPL. This might be worth mentioning to your client if you’re in a situation where you need to hand over the theme or plugin you created to them.

Are collaborators on the software allowed to distribute it?

No. If you have other developers working on your software, say in a web development agency scenario or even remotely for example, this does not constitute distribution. The software developer (typically the company or agency producing it) with all its employees and contractors is considered to be a single entity and therefore retains copyright ownership of the code regardless of how many employees it has been distributed to for development purposes.

Ways to legitimately earn income from your WordPress software

As mentioned earlier many developers put up a paywall for their products. But you don’t have to do this for all your products. An excellent real-world example of this is WooCommerce, who give access to their core plugin for free (a good strategy for encouraging mass adoption) and only charge for their extensions, premium store themes and support (all of which is optional). But that model doesn’t necessarily agree with everyone and if you’re not comfortable with it, there are other options.

Some developers offer a free ‘lite’ version of their theme or plugin but charge to upgrade to a pro version.

Another (perhaps financially riskier) scenario is to simply give all your software away for free but charge to help customers set it up, customise it, or solve other problems for them.

There are even WordPress developers who don’t produce specific products for sale as such, but instead market themselves as WordPress solutions experts who will build custom theme and plugins for your business needs.

It all depends on what model your comfortable with (and you can change anytime), but the point here is that there are options available that don’t violate the terms of the GPL.

How to decide if your WordPress software is bound by the GPL

Usually it always does. But if in doubt, ask yourself: Will my code function normally if I take WordPress out of the equation? If the answer is no, then your code is considered WordPress derivative and therefore the GPL applies.

The more you know.