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.
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!
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.
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.
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. :-)
Yes sir!
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.
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`.
Spot on. I think item #3 could be handled easily if we knew for sure that all scripts and styles were registered using
wp_register_scriptrather than enqueued directly viawp_enqueue_script. Let WordPress do the enqueue’ing (is that even a word?)…but that definitely raises some backwards compatibility issues, since WP doesn’t strictly enforce registration.Anyway, if it’s something you (or anyone else) want to collaborate on I’m down to help.
But on #2, switch that around so the cron job fires if the transient is NOT set (i.e. expired).
Hey Tom, have you ever used this plugin? http://wordpress.org/plugins/wp-minify/
Looks like it does exactly what we were talking about…
Haven’t checked it out – may look into it when I have a free moment.
Thanks for sharing the link :).