Hey there, WordPress theme developers. When you’re crafting themes, are you checking the quality of your theme code? The design is important, yes, but so is the code. Within the past year, the WordPress theme review team has been hard at work encouraging best coding practices among WordPress theme developers, with the goal of raising the overall standard of the themes that appear in the WordPress.org theme repository. Even if you don’t intend to submit your theme to the WordPress.org theme repository, it’s wise to develop your themes as though that was your intention. I hope that by the end of this post, you’ll have a better understanding of the benefits of doing so.
The WordPress Theme Review Team and its guidelines
Just in case this is the first time you’ve heard of the theme review team, I’ll describe it briefly. They’re a group of volunteers from the WordPress community that reviews each theme that is submitted to the WordPress.org theme repository to check for compliance with the guidelines and standards that they have set forth. I’m not going to list all of the guidelines here because you can read them at the theme review team’s website, but I do wish to highlight a few here because they’re especially relevant to coding practices:
Briefly, a description of each of the above:
The Theme Check plugin
This is a plugin that tests your theme to see if it meets the latest theme review guidelines. If your theme is missing a required or recommended feature, or if it contains deprecated functions, the plugin will let you know and suggest possible fixes.
Code quality
These are a general set of guidelines that specify how you should format the HTML, CSS, and PHP in your theme. All HTML and CSS mark-up must validate to W3C Standards, and your PHP must neither generate any notices, warnings, or errors when WP_DEBUG is turned on (turn it on by placing define('WP_DEBUG', true) in wp-config.php).
The Theme Unit Test
How well does your theme handle posts without titles? Do images resize properly? Do floated elements inside posts clear properly? Are all possible HTML tags that users can use in the visual editor styled? Are all widgets styled? The theme unit test is a set of sample data that you can use to test your theme in scenarios such as these.
Of course, as I stated earlier, these are just three of the areas in the theme review guidelines. A theme passes its review and is accepted in the WordPress.org theme repository when it satisfies the criteria for all of the areas.
So, why should you care?
The theme review team’s guidelines are important for all WordPress theme developers for three basic reasons:
- They establish general consistency among WordPress themes for users and developers.
- They ensure protocols for theme security.
- They raise the bar for overall theme quality.
Let’s discuss these three areas in more detail.
Consistency
WordPress themes are a eclectic bunch, but they do have at least one thing in common — they are all WordPress themes. It’s important to always keep this in mind.
When your theme deviates too far from the core WordPress functionality, you run the risk of users becoming frustrated as to why certain features that they’ve come to expect from WordPress don’t seem to work with their site. Listed below are sections of the theme review guidelines that help establish a base consistency among themes in the WordPress.org theme repository:
- Template Tags and Hooks
- WordPress Generated CSS Classes
- Theme Template File Checklist
- Licensing
- Theme Name
- Credit Links
- Documentation
Before you add a custom feature to your theme, check to see if WordPress already has a core function that can take care of it. The table below highlights core features your theme should utilize as much as possible.
| Theme Feature | WordPress Feature to Use |
|---|---|
| Custom Logo/Banner | Custom Headers |
| Background Color/Image | Custom Background |
| Menu Management | WordPress Navigation Menus |
| Theme file editing | WordPress Theme Editor and Plugin Editor |
| Theme Options Page | Settings API |
| Theme Options Page Design | Stick with the WordPress UI instead of making your own design. (Ryan Imel from WPCandy wrote a blog post on this subject) |
| Design options (color pickers, font size tools, border size, etc) | Keep to a minimum. Encouraging users to make design changes with CSS is more scalable in the long run. |
| Direct Database Queries | WordPress Template Tags and Functions |
| Thumbnails | Post Thumbnails (Featured Images) |
Security
Themes play a large role in WordPress sites, so it pays to ensure that your theme’s code is as secure as possible. Don’t let your theme be the one that leaves your users’ sites vulnerable to hackers. No one wants (or deserves) to have their site hacked. If you follow the theme review team’s security-related guidelines, you will be one step closer to building a theme that is as safe as it is gorgeous. The following are the theme review team’s guidelines related specifically to security. I highly recommend that you read them as you develop your theme:
- Theme Settings and Data Security – Properly escaping all data throughout your theme and using the Settings API for theme options pages are essential characteristics of a secure theme.
- Theme Obsolescence – Outdated code and deprecated functions are a security threat because they may contain known vulnerabilities that hackers can exploit. Themes in the WordPress.org repository will be removed if they are not updated on a regular basis to comply with the latest version of WordPress. In a similar vein, third-party scripts can also pose security risks, as we saw with the recent TimThumb vulnerability. If you use third-party scripts in your theme, please, please, please check those scripts regularly to make sure they are up to date. If the original author of a script does not put out regular updates, think twice about using it. Security is never a “set it and forget it” deal — you must approach it Mad-Eye Moody-style: CONSTANT VIGILANCE.
Quality
The final reason that it’s important to pay attention to your theme’s code is for the sake of quality. A theme that uses well-formed, modern code is easier for you and other developers to maintain in the future. The larger the number of well-coded themes we have, the more positively this reflects on the WordPress community as a whole. The following area from the theme review team’s guidelines relates specifically to code quality (I linked it earlier, but I’m linking it again because it’s that important):
In addition, WordPress has adopted standards for writing PHP, HTML, and CSS. We use these standards when converting themes for use on WordPress.com:
Conclusion and … how to get started
I hope I’ve convinced you why it’s so important to pay attention to your theme’s code, whether you are creating free themes or commercial themes. If you’re interested in applying some of these principles to your theme development, here is a nice list of procedures to keep in mind during the development process:
- Make sure you’re aware of the current theme review guidelines.
- Look at the code of the current default theme, such as Twenty Eleven, as a starting point and as an example of best coding practices and implementing core WordPress functionality.
- Get in the habit of testing your theme with the unit test data.
- Turn on WP_DEBUG in wp-config.php to check for hidden errors, warnings, and notices.
- Install the Theme Check, Log Deprecated Functions, and Debug Bar plugins. Run their tests often to catch (and fix) potential problem areas before they pile up.
- Before you add a custom function, check to see if there is a WordPress core function that can take care of it. If you feel that the WordPress core functionality is lacking somehow, try supplementing the core feature instead of replacing it completely. Make sure that any custom feature you add does not leave “debris” behind (such as broken shortcodes) or otherwise cause a site to break badly if users decide to switch their theme. What are your “fallback” features?
- Consider joining the WordPress theme review team, which forces you to learn by checking others’ code. For more information, please read Justin Tadlock’s excellent post on this subject: Join the WordPress theme review team.
Resources for further reading
- WordPress Theme Review Team
- How to Create a WordPress Theme (ThemeShaper Tutorial)
- ThemeShaper Resources Page
ThemeShaper 
45 responses
This article clearly has good intentions, but I have a big problem with this:
This wrongly assumes that the reason theme developers deviate from standard WordPress functionality is because they do not know it exists, or just want to be difficult and do their own thing. Not the case.
Many theme developers ignore the settings and capabilities listed after this quote because, quite frankly, they aren’t very good. WooThemes, as but one example, have created far superior theme management and administration features which far surpass WordPress native features both in functionality and usability.
By suggesting that theme developers should stick to WordPress core functionality, you are effectively discouraging innovation. You are discouraging the very thing that Matt talks about as the root of inspiration for core functionality in the first place. Where would menus be right now if Woo hadn’t stepped up to the plate and refused to use core functionality in favour of doing their own thing?
The focus here should be in two parts. One part on theme developers to improve their code and comply with WordPress standards, and one part on core developers to actively support theme developers and make it easier for them to achieve what they want using core functionality. It’s a two way street, and in my experience the second part doesn’t have a whole lot of traffic.
Either way, I’m not sold on a department of Automattic pushing this issue. This is a great post, but the fact that it’s coming from somewhere which is not without bias undermines its credibility.
As a small side-note on the subject of theme quality. It would a welcome addition if I could actually see the images and read the captions for this article on my iPhone. It’s frustrating when I can’t get to the full-site cause it’s been designed to be “responsive” – but the responsiveness is actually preventing me from getting to the content. Putting your own house in order before those of others, I imagine, should be a priority.
Innovation is great and should definitely be encouraged. However, striking a balance between innovation while maintaining a harmony with existing standards and WordPress core features is key.
We have another few reasons to believe that indeed “Theme Code Matters”.
Lets go:
1) A theme that is loading fast has no doubt the best relation to great seo ability, and the ranking, and the pagerank will improve by much.
2) The end-user, which is the visitor, would have a much greater ease of surfing the website, and while being fast, he will enjoy returning to it.
3) Ease the theme by the graphics of it by lowering the amount of images/flash usage within your theme.
This three tips should do the work in helping your WordPress blog to be number 1.
Well, that’s no good. Thanks for pointing that out.
I’m seeing this more and more with ‘responsive’ designs. The sudden rush to make everything responsive needs to be balanced with giving users options to control how they experience content on mobile devices. A Switch to desktop version should be mandatory.
John, I agree with you that no one should be stifling creativity, but I think what Michelle is trying to say is that it’s more beneficial to the user to use common standards that have expected behaviors.
Where I personally think some theme companies get it wrong is when they put the want to be ahead of their competitors before the user experience. In the end, this is a disservice to the user. I am a WordPress developer by trade and I find most theme options panels to be baffling. The fact that there is a mini app built into a single WordPress page makes no sense in the normal user workflow.
I think another often overlooked point is that built-in WordPress APIs are inherently more secure. Companies that try to reinvent the wheel are losing out on years of learned security best practices. I can’t tell you how many theme options panels I’ve had to augment with simple things like proper escaping of data.
Finally, I think these theme companies would get a lot more public recognition and praise from the community by actually contributing their ideas/code to core like Woo did. In the end, the entire WordPress community was able to benefit from their contribution, not just their users. And it’s not just theme options panels that gain that benefit. WordPress does a pretty good job of using common interface elements throughout the admin. If they offer up a better way to do something in one section of the site, chances are it can be applied to the entire admin making the entire admin better.
I think the source of this post is irrelevant. Similar topics have been posted on WP Candy recently and gotten positive reviews.
Finally, I think that last comment you made was a bit spiteful. I’m sure that would have been much more appreciated had it been mentioned out of the public eye.
Let’s clear that up. There are LOTS of UX problems with WordPress – it’s not perfect by a long shot (that’s not a criticism, it’s just the way it is). The reason theme developers make their own admin panels is because it’s the lesser of two evils.
If core provided a better way of doing it, I have absolutely no doubt that theme developers would use it. In case you haven’t noticed, they’re all building pretty much the same type of systems, they just want something that works.
The source is absolutely relevant. Automattic is a for profit company its own goals and motivations for publishing content on this blog. Regardless of intention, it is inherently biased based on those factors and what it stands to gain. There’s no getting away from it, and it’s certainly not comparable to an objective magazine site with no political motivations whatsoever.
As for my final comment, I couldn’t care less what you think of it. This is a public discussion and my public comment was relevant to this public blog post on a public site who’s own functionality contradicts the words which it’s writing. It was 100% relevant, and not particularly spitefully worded.
Actually, this most definitely IS the case, most of the time. In the few instances where a theme developer knows about a certain API, but chooses to roll their own, their users usually lose.
Case in point: WordPress makes a functional, solid image resizing and featured image API and rolls it into core. Generally speaking, everything it does, it does well. But there’s this one thing it doesn’t do: dynamic, on the fly, image resizing. But as it turns out, it doesn’t do that one thing because that one thing is actually pretty hard to do.
So, what do theme developers do? They include TimThumb in their theme. Voila! Oh wait …
If a theme developer can’t figure out a way to build an admin panel using the Settings API and some standardized table markup, then maybe they shouldn’t be building WordPress themes.
Are you kidding? You’re telling me theme developers are crazy for wanting to use semantic code instead of the hideous mess of tables an non-semantic crap that WordPress spits out? And you want them to then market that as a unique product?
On-the-fly image resizing isn’t the only reason people use TimThumb, either. It’s also worth pointing out that TimThumb came long before the_post_thumbnail(). Even years later, TimThumb still offers more functionality. Want people to switch? Make it better.
+1 Nathan. Exactly what I’m talking about with regards to security.
John, this is exactly what I’m talking about. If theme authors spent more time contributing their good ideas (and code/design for that matter) back to core, it would probably produce sexy semantic code instead of the “non-semantic crap”. That’s a win/win for everyone since, once it’s in core, the burden is not on the theme author to continue maintaining that code. That’s not only good business sense, but it’s shows that a theme company has better community awareness. Theme authors can then get back to building great front-end designs instead of crafty back-end hacks.
@Brandon – I spent 18 months regularly contributing to core and I’m this second writing a patch that introduces new admin UI hooks FOR theme and plugin authors. So don’t you preach to me about how people should be contributing or all the reasons that there are for it.
It takes two to tango. I’ve been on the core side. I’ve been on the theme developer side. Posts like this are 100% a case of the pot calling the kettle black.
Theme developers are largely undervalued and under-appreciated in the WordPress community, and yet many of them do more good than anyone else.
Core does not facilitate easy contribution by theme developers, and it certainly doesn’t invite it. I don’t blame them for wanting to steer clear of the politics and built a profitable business instead.
John, I’m not preaching (at least I’m not trying to). I wasn’t actually talking about you. That’s awesome that you spent some time contributing to core. I’m just starting down that path having just submitted my first patch to core, so maybe I’m drunk on that kool-aid.
I’m a custom theme developer and I have also worked with a premium theme company to build an options panel for their public facing themes, so I know some of the difficulties of creating a theme with options. It’s amazing what a little jQuery can do to the non-semantic WordPress code. No matter what snazzy thing I come up with, I always feel like my duty is to give the user the most consistent (even if it’s bad) user experience throughout their content management system.
I’m not sure I get where this is coming from. Everyone I know puts theme companies/developers on a pedestal, almost to a fault. Having run two WordCamps myself, and attended more than I care to admit, I feel like I have a fairly decent sense of what people love and hate about in the WordPress community. Most people feel that pricing for paid themes is inexpensive in comparison to the value of the product. I hear stories all the time of people who buy “developer licenses” to paid themes in the off chance that they might use it because of the price. Perhaps it’s theme developers who undervalue themselves.
Why doesn’t core make it easy to contribute to? I am admittedly an svn dummy. Using a page from the codex, I was able to check out core, mod it, create a patch and submit a ticket. It took me all of a day to learn how to do. The only reason a theme developer wouldn’t be able to contribute back is because they don’t know how to make their code work with WordPress core. Do they spend so much time building separate interfaces to do what they want, that they don’t actually know how to implement their code into core?
I agree with you that core doesnt’t invite you to contribute, but does it have to? Nobody is going to force theme developers to contribute code to core. Some of that responsibility should fall on the shoulders of the developer.
Indeed.
We have a rather strange situation with WordPress themes, in that if a user is paying for a commercial theme, it has definitely NOT been vetted by the WordPress Theme Review Team; the full review process is only available to those who submit their theme for the free theme directory (for good reason). Unfortunately, most users assume that if they’re paying for a theme, it must be better than the free ones available. A lot of the work I do is customizing commercial themes, and every time I do it, I have to charge the client for my time relearning this particular developer’s version of the wheel. More consistent theme code quality by all developers (free and commercial) would benefit us all greatly.
I’d like to see us go even one step further with regards to theme development: plugins = function, themes = form. We’ve spent years trying to separate content and presentation in web design, yet so many of our WordPress themes are code blobs trying to do everything (I know – I’ve been building them myself). As soon as a user switches themes, they “lose” (in their minds, anyway) any of their content tied to custom post types, etc. which just makes us all look bad. Releasing themes with an accompanying plugin for any function/content related code would give consistency to the user experience and make modifications easier for everyone.
Great post, Michelle!
Can agree to this a lot. A lot of those premium themes are not that premium..
I also get work from people who buy $35 themes and then complain their frontend loads for 10 seconds, cause the developer, in an urge to overpower competitors (or whatever the motivation) has pulled in almost every trick possible. Those are not best practices, and certainly don’t deserve the predicament ‘premium’… See also Justin Tadlock’s post about shortcodes for example.
And some theme devs just don’t know ALL available theme building options, that’s why an article as this one is certainly useful. Thanks Michelle.
It would have been so nice to read something about localisation in this article too! It’s a pity too that it is not included in the official theme guidelines, but the fact that both twentyten and twentyeleven come fully localised can be seen as a step forward.
Any theme that is not fully localised is completely useless in a bi- or multilingual environment. Of course I know that WordPress itself is largely US-based and the big influential sites about WordPress as well.
I am just hoping that one day people start realising that WordPress has quite a bit of traction outside the US and in many of those cases, sites are built using at least 2 languages.
Any theme I make nowadays is fully localised, whether the client uses it or not. This should, imho, become the standard!
Hi Piet. Thanks for your comment. I agree that localization is very important and it often gets overlooked, so I’m glad you brought it up. All of the themes we convert for WordPress.com are fully localized, and we send them back to the WordPress.org theme repository with localization in place. It would be great to have this be a standard for all themes as the international WordPress community continues to grow.
Dunno why, but i stopped reading it after this part:
All HTML and CSS mark-up must validate to W3C Standards
[…] https://themeshaper.com/2011/09/13/your-themes-code-matters-too/ […]
Hi guys, just want to chime in, seeing as I may qualify as a commercial theme developer. John is right in stating that WordPress core functionality doesn’t always work for themes that may be trying to do something a certain way. Sure, it’s easier in some ways to build out theme options using the WordPress settings API, image headers, backgrounds, etc, however, it’s not always the best user experience or constructed in a way that works with certain themes. And no, there’s not always an action or filter to make it work the way you want.
A great example is the post thumbnail, or (as it should be called) the “post image.” The post thumbnail provides an easy experience for the user, however, it is extremely inflexible due to the lack of cropping features for various image sizes (and no, the image cropping UI for the thumbnail size is not awesome/acceptable) and the lack of image replacement options for certain image sizes. For this reason, we use the multiple post thumbnails plugin, which provides the ability to upload multiple images and keeps the WordPress UI, which allows users to easily see the options for their images and attach an image for each location in the theme. Now, the UI for this is not perfect either, but it’s far easier for a user to understand.
I think there needs to be a balance here. Theme developers should strive to keep the UI close in appearance and make use of WordPress core functions but, above all else, strive to build something that provides the best possible experience for your user. If you do it “right,” it’ll make it into Core in one form or another, whether through inspiration or actual code.
I think John is totally right on this one but I also think Michelle makes some great points if we’re talking about themes that are being submitted to WordPress.org or WordPress.com. 🙂
[…] Theme Code Matters, Too on Themeshaper. […]
[…] Theme code matters, too | Themeshaper Share this:FacebookEmailPrint This entry was posted in WordPress by tsop. Bookmark the permalink. […]
@ John
Sorry but I really believe that a lot of developers ignore them because they don’t know that they exists, TimThumb is one example of this, add_image_size() has been available since 2.9 most theme developers continued to run TimThumb until the recent security issue I cannot count how many themes I had to remove that from themes.
Use of settings API is a lot more efficient than some of the other options implemented by most themes, in fact a major problem is that configuration seems to take precedent over convention, do we really need to add a logo upload option???
Your Automattic rant seems to be more personal than anything else so I will stay out of it. What I find really funny though is your last statement, on responsiveness and the iPhone, I know it is the buzzword and all, but on a five by something screen it just sounds very funny to me, like trying to fit bus seats in a mini, shouldn’t it be adaptive, but I digress…
I do believe that design and innovation should drive the whole theme process, but to me that means that things like the theme unit test (XML) should contain content that is designed for real-world applications. Stuffing it with a ton of categories, tags and poorly constructed content structure(s) is as bad as themes with tons of configuration options.
The short is… EMPHASIS should be on good design and the development process should be empowered to support this, sometimes I get the feeling it is the other way around.
Code only matters when Design does!!!
If you think that the only reason theme developers use thumb.php is to achieve something which can be achieved with add_image_size() – then you don’t have much experience with commercial themes.
I didn’t “rant” about Automattic even slightly, and it certainly wasn’t personal.
Again most of them do, and I really cannot see any other valid reason that would warrant a themes widespread use of dynamic image generation, specialty themes… maybe. In most cases the add_image_size() is sufficient.
Just a small comment on the example of including timthumb script.
I would want to use WordPress media library and core function of the post thumbnail – however I made a decision early on in building my blog that I would host all my images on photobucket mainly for space and bandwidth consideration
WordPress core functions will not work on external images and I have not found any work around that doesn’t include uploading the image to my wordpress install.
Timthumb does the job for me and I started using it after I heard about the security issues with the prior version
Sorry to break it to you Doug, but TimThumb also creates copies of those images on your own server (at least temporarily) and serves them from your server, wasting some bandwidth, but especially using a lot of CPU cycles.
There’s just no other way to do it.
For a bandwidth issues I would prefer to let WordPress do the work and move my images to a CDN after the fact there are plugins that will do this, rather than use timthumb to dynamically generate thumbs.
The second question would be is my bandwidth consumption that high to warrant the extra work am I really saving anything here.
The third issue was how well would TimThumb scale on a high traffic site, I just did not feel that it would.
Best practices can tend to loose sight of good design!!!
I would love to read about alternatives to using timthumb for externally hosted images but I have not found much info on that issue. I looked around for several weeks before I decided to go ahead and use timthumb
I am not an IT guy and my theme development is something I do as a hobby.
What plugins could I use if the images were based on a CDN?
Try W3 Total Cache – http://www.wpbeginner.com/plugins/how-to-install-and-setup-w3-total-cache-for-beginners/
This is a great discussion. We’re all dancing around the fact that we’re human beings and not machines. We have to counter complexity with things which simplify.
So, if we want people to comply to the moving target of “standards” we have to spend the time making it easy for them to do so with some kind of easy to find resource, and that “living resource” needs to be maintained. It’s not enough to just “expect” people to do everything right, and then be disappointed when the complexity of the situation causes them to fail to do something we think they should.
As for the “responsive design” thing, there’s a blatant conceptual error involved with it, also commonly known as a “brain fart.” It needs to be a SETTING, so theme users can CHOOSE. I was recently another of the hundreds if not thousands who repeated wasting valuable hours trying to stop this behavior (because in my particular case it’s interfering, not helping). The WordPress.com support people said they will consider putting in some text in the description letting people know that the Twenty Eleven theme behaves this way. (face-slap) It’s too late for me to throw out all my work and take a risk on another theme. He told me I could try another theme that does not have this behavior. I told him I wasn’t going to just start trying all kinds of themes to test them. He then told me which ones had this behavior. This is information management at it’s worst – repeatedly making other people guess and dig.
I was also told by forum helpers to learn CSS and then undo that behavior. He incorrectly assumed that simply knowing CSS was all that was needed, when one also needs to know how things were designed, named, about the interacting layers, all of which no one was going to tell us. Nor did he try to determine if it was even possible, which I believe it is not (because like everyone else I had to give up on it.)
See, these are all human failings. And it boils down to our failure to acknowledge that we are human beings, not machines. Our human nature goes against the grain of technology and the information age, and the “helper interface” between us and it has to be there for us to be successful.
Like Haley Joel Osment sees dead people, I see bad information management and bad “information interface” between people and technology. (visit my site)
[…] to developing WordPress themes (and plugins too, for that matter). I noticed a good post on the ThemeShaper blog (ThemeShaper are Automattic’s theme team) specifically calling on theme authors to pay […]
Interesting post and even more interesting debate.
I’ve been developing in WordPress since pre 2.0. I know tons of the tech side yet my clients aren’t the techie types. They’re everyday folks who are often intimidated by the thought of having control over their own website. To us techies this seems pretty silly and possibly childish. Yet most of the population – and the great majority of WP site owners – are from this non-techie world.
I say all this because I think what’s missing in this debate is the full breadth of WP users. We need to think outside our own personal feelings about code and standards and start thinking of how WP is being used by the people we develop sites (and the WP core) for. I don’t hear anyone talking about the need, sometimes, to add features or functionality (or remove it) from admin so that users find WP to be easier to use.
For example, I read<a href="http://justintadlock.com/archives/2011/05/02/dealing-with-shortcode-madness" Justin's post on shortcodes and while I don’t disagree with him, I also know from working with hundreds of clients that shortcodes make their WP experience easier, less stressful and more accessible to them. Shortcodes provide a way for our clients to add buttons and format content in ways that don’t require much of a learning curve. And that’s a good thing.
You know, I use WP to build business platforms for small business owners and I think I’m doing my paying client an injustice if I don’t make their experience as user-friendly as I can – regardless of conventional thinking. I heard Matt say at WordCamp SF this year that he doesn’t think the admin panel should be changed in WP. Well, that’s fine for coders and developers. But are we considering the everyday user that both doesn’t need and doesn’t want all the complexity of Settings, Edit Theme or Edit Plugin? As ‘experts’ working for our clients, isn’t it our responsibility to make their experience easier? Most of the nearly 400 clients I’ve put on WP have been happy to sacrifice complexity and power for simplicity and ease.
And who else are we developing our themes for if not for people who aren’t ever going to touch HTML/CSS/PHP? Just a something to consider…
[…] to developing WordPress themes (and plugins too, for that matter). I noticed a good post on the ThemeShaper blog (ThemeShaper are Automattic’s theme team) specifically calling on theme authors to pay […]
To each his own.
Code the way you want to. If it works, and serves your intent, then it’s gold.
Standards are a means to uniformity. But uniformity is not always necessary.
This is a great article, but nobody should consider it a general rule. If you need standards, then code to the standards. If not, then don’t code to standards.
[…] do different? They keep their eyes open for tangential opportunities, and take advantage of them., Theme Code Matters, Too Great article of best practices for WordPress theme development., WordPress Essentials: […]
Hierarchy is key – lesser content modules (Subcategories, Pages, Monthly Archives, Search) are tucked away so the user stays primarily focused on recent blog posts and recent lifestream items. Newer items are lighter with a larger font size, and get incrementally smaller and darker as they get older.
[…] my WordPress theme code better so that I could start selling themes on ThemeForest. I came across this article which goes into incredible depth about guidelines to follow, plugins to install to help you make […]
[…] not all about the WP. ThemeShaper lists an awesome article on WP Theme Validation: “Theme code matters, too“. Something for anyone writing themes to keep in mind (hint, hint). I know I would’ve […]
Speaking of core, I just want to see Automattic do a useful and robust media library for WordPress. The existing functionality is terrible.
Hi Ian,
I recently installed the theme called “Toolbox” since I’m quite fond of its simplicity. But later I realized that I can’t replace its blog name/title with a logo of mine.
Now I read the WordPress tutor about adding a custom_header_image, but I got nothing but errors after inserting it into the “functions.php” in Toolbox.
So if you have time, could you please give me the appropriate code that I have to include in the Toolbox child theme to get this done? Thank you.
Hi Michelle,
I totally agree theme code matters because if it is not clean you will face a lot of problems managing your WordPress blog like plugins are not compatible or your website loading speed will be slow.As you know not all bloggers are coders. You just really shared really good tips about this topic and I like the The “Theme Check plugin” . I think any blogger should try at least learning the basics of coding.
~Salah
I’m not a developer but I am a little OCD, I recently tried to hire a developer to go over my site and make sure it was 100% compliant and he told me it was pointless. Is this true?
It’s not pointless but it’s not absolutely necessary either. If you’re hiring a developer, money might be better spent on getting them to make your site faster while at the same time making sure any new markup or CSS they write is valid and making sure any code they alter is also valid. And when you’re looking for developers to build something look for ones that care about standards and validation. They’ll likely wind up still creating web pages that don’t 100% validate but they’ll know when and why they broke any rules.
I hope that helps!
Thanks Ian!
[…] change on any part of my theme as quick as I want. But a couple weeks ago after read a post from Themeshaper, I become aware that designing my own theme is not a very good choice, I should pick a theme from […]