The Great Expectations of Modifying WordPress Themes

Earlier this week, I was talking with Chris – our product midwife at 8BIT – about the differences in expectations between engineers, developers, designers, tweakers, and end users when it comes to modifying WordPress themes.

I started my career in software engineering – specifically, I used to work in .NET followed by Ruby on Rails – as well as object-oriented programming before moving into fulltime WordPress development.

And you know what they say: Old habits die hard.

Old Habit Die Hard

Did someone say “die hard?”

Case in point: ask my team what I did when I first became the lead developer of Standard. I spent more time yanking out template code, abstracting it into functions.php and a collection of other files all of which would make sense to someone comes from a different background, but not WordPress.

And here I am, years later, where I’m significantly more familiar with “the WordPress-way” (even writing blog posts on Coding Standards and various APIs even) and there are still issues to be solved around this very issue.

Modifying WordPress Themes: Developers and Users

One of the things that gives WordPress a leg up in the design and development space is the ease of which the hobbyist can tweak a theme in order to get it to look how they want.

After all, if you think about themes in their purist form, they really are a collection of markup and styles (located in style.css, of course) along with a few calls (such as wp_head() and wp_footer()) to the WordPress API.

Sure, they may include JavaScript and there may be a call to something in functions.php, but I don’t think that’s something that’s absolutely necessary or critical to a simple, straightforward theme.

A Developer’s Perspective

In the latest release of Standard – even in work that I’ve done in my plugins – I’ve begun to employ both LESS and JSLint via CodeKit in order to help better organize the code and to enhance the load time and performance of the product in question.

But here’s the thing: Occasionally, I – or the team – will receive a comment about not being able to make changes to style.css because it’s all one minified line of code.

Furthermore, there’s no hope for modifying the JavaScript because it’s not only been minified, but it’s even been obfuscated. This is the topic for another discussion, so I digress.

A User’s Perspective

But as far as the styles go, is this a valid concern?

I think so, especially for those who know just enough to be dangerous when it comes to tweaking their theme to look just the way they want.

So let’s say that a user purchases and/or downloads a theme of their choosing and ready to make a few customizations – perhaps change some colors, alter some fonts, or add some type of CSS transition.

They open up style.css and…

What is this? It’s a one CSS!

A User's Perspective

What’s a one CSS, anyway?

But seriously, a customer opens the stylesheet to begin making their customizations and they can’t because the CSS has been minified.

At this point, some may stop right there and think the theme’s been incorrectly developed, that they’ve wasted their money, or that something has gone wrong.

A Case of the Empathies

As developer’s it’s easy to write this stuff off and say “they don’t understand – we’re helping them by making their site faster!” and it’s because we don’t have the reputation of being the most empathetic type of people.

A Case of the Empathies

You know that feel, bro?

Oops.

And though there is some truth in that, come on. It’s important to ask: Are we breaking a typical expectation of someone who’s working with a WordPress theme? Are minified stylesheets out of the question?

Personally, I don’t think so. I see it as a point of education.

First, I think we need to make sure the user understands what they are getting in the product. Next, they need to know how to make changes: If it’s a theme, then create a child theme – perhaps we can even provide an empty stylesheet with a set of empty selectors and code comments. Third, if we’re working with a plugin, we offer a custom.css file that allows them to modify the look and feel as needed.

Where Are We Headed?

As much as as I’d like to believe we’ll head in the direction of minified styles and optimized JavaScript, I think that’s a bit of a way off – at least as far as WordPress is concerned – not because the community is dragging (there are incredibly bright people working on and with WordPress), but because of the expectations that our user base has.

Change is tough – this is true of any team, organization, or piece of software – and the longer or more developed any of the above are, the harder it is to change course.

To that end, I do believe that we’ll begin to see more and more people begin to use LESS, JSLint, and/or other similar tools for making front-end development easier, and more optimized, but it’s also going to have wait for the average user to catch up.

On average, I’ve no idea how long that takes – I’ve not been doing this long enough – at least not yet.

13 Comments

I think if WordPress core automatically merged & minified all enqueued all registered JS & CSS, that would change everything. Non-developers could view and edit the raw files and WP would optimize silently in the background.

Might be a fun project to work on, actually…

    In theory, it’s one of those things that sounds great, but there are some inherent hurdles that come with this.

    The biggest things that immediately come to mind are determining is if it happens on the server-side or the client-side. Technically, doing so on the server-side would be optimal because it will be faster.

    Secondly, you’re faced with checking versions so that once they are merged and minified, then it’s only done once (of course, it’ll need to be done when a file is updated, so it only happens when files are changed).

    Third, you’ve got an issue of dependencies to make sure that things are done in the proper order such that JavaScript and styles aren’t minified in the wrong order. This gets a bit more complicated when you throw plugins into the mix.

    That said, all of these things are problems that can be managed – it’s just a matter of balancing pragmatism on the user’s end with offering developers and designers the tools.

    Regardless, this is why I dig on CodeKit so much ;).

      All very important considerations, I agree. My response would be:

      1. Server-side, for sure. Users measure site performance by load time;
      2. This could potentially be resolved with transients, where everything gets re-minified every X minutes/hours/days — or when a ‘Resources’ settings page is visited (kind of like rewrite rules get flushed when you visit Permalinks);
      3. WordPress already has a system for tracking dependencies, via wp_register_script() and wp_enqueue_script().

      There are two problems with using CodeKit. One is the issue you addressed in your blog post, about not meeting the user’s expectations when you minify your resources; and the other is that I use a PC. :-)

        1. Server-side, for sure. Users measure site performance by load time;

        Yes sir!

        2. This could potentially be resolved with transients, where everything gets re-minified every X minutes/hours/days — or when a ‘Resources’ settings page is visited (kind of like rewrite rules get flushed when you visit Permalinks);

        Sure – I’d even go as far as saying the transient is actually just a flag value and then there’s a cron job to check the value.

        If it’s set, then it kicks off a process to handle all the scripts and styles from that point, then it clears the transient.

        3. WordPress already has a system for tracking dependencies, via wp_register_script() and wp_enqueue_script().

        Oh, totally – but assuming everything is minified into a single file, then you need to make sure that the files are done so in order and then, ideally, make a single call to `wp_enqueue_script` and/or `wp_enqueue_style`.

Trackbacks and Pingbacks

[...] The Great Expectations of Modifying WordPress Themes – Earlier this week, I was talking with Chris – our product midwife at 8BIT – about the differences in expectations between engineers, developers, designers, tweakers, and end users when it comes to modifying WordPress themes. [...]

- rezzz.com | Jason ResnickJune 21, 2013 at 7:53 am

[...] Tom McFarlin’s post “The Great Expectations of Modifying WordPress Themes” he speaks from a developer’s perspective of employing tools such as LESS and JSLint to help [...]

[...] Tom McFarlin’s post “The Great Expectations of Modifying WordPress Themes” he speaks from a developer’s perspective of employing tools such as LESS and JSLint to help [...]

[...] The Great Expectations of Modifying WordPress Themes: How do you balance developers working with LESS and JSLint to produce minified code with users needs to customize a theme? Check out Tom McFarlin’s thoughts. [...]

[…] The Great Expectations of Modifying WordPress Themes – Earlier this week, I was talking with Chris – our product midwife at 8BIT – about the differences in expectations between engineers, developers, designers, tweakers, and end users when it comes to modifying WordPress themes. […]

Leave a Reply

Name and email address are required. Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>