A few months ago, we asked Justin Tadlock and Emil Uzelac, of Theme Review, Co. to undertake a code review of Make and Make Plus. For those who don’t know, both are senior reviewers at WordPress.org (and Emil is now a reviewer at Envato). It was humbling — and also a great experience to have these two well-respected theme experts in the WordPress community take a deep dive into our code and scrutinize every line.
Now that we’ve had some time to collect our thoughts on the process, here are some of the things we learned from Justin and Emil’s feedback, that we think will help other theme developers better their own code.
Translated strings should be escaped too
Justin and Emil noted that we had done an excellent job escaping output from the database and user inputs. This is a standard practice for keeping code secure and preventing XSS vulnerabilities. However, one area that we had overlooked in some cases was translatable strings. Any string that’s included inside one of the translation functions, such as
__( ‘Hello world.’, ‘make’ )
will be replaced with the corresponding string in an .mo file, if it exists. Each language has its own .mo file, usually provided by a different translator. Theoretically, malformed or malicious code could be included in an .mo file and get inserted into a page load when the default string is swapped out. The way to prevent this from being a security issue is to use the escaped version of each translation function. So then
__( ‘Hello world.’, ‘make’ )
esc_html__( ‘Hello world.’, ‘make’ )
We have always reviewed each of the translations that we ship with Make to ensure that they didn’t contain anything malformed or malicious. But since we can’t control custom translation files or translations provided through the WordPress.org theme translation project, escaping all of our translation strings provides an extra layer of security hardening.
Good translator notes make for better translations
Speaking of translations, our theme had several instances where a translatable string, taken out of context, was practically meaningless to anyone trying to translate it using the theme’s .pot file. Justin and Emil helped us identify several of these instances and pointed out that we could provide context in a code comment near the translation string, and it would be included in the .pot file. Example:
Old .pot file entry
New .pot file entry
#. Translators: this string denotes a camera f-stop. %s is a placeholder for
#. the f-stop value. E.g. f/3.5
Some things actually shouldn’t be prefixed
One of the first things that’s drilled into your head as a WordPress developer is that everything should be prefixed so that your code will avoid collisions with other plugins’ code as well as core WordPress code. So in Make, all of our functions look like this:
Many of our CSS classes look like this:
One exception to this best practice is when it comes to naming 3rd party libraries. In Make, we include the Font Awesome icon font library. So do many plugins. If we all prefix our libraries with something like “ttfmake-font-awesome”, users may end up loading multiple instances of Font Awesome on a single page. If, however, everyone uses the same name, “font-awesome”, we can ensure that WordPress will only load the library once.
Clean, uncluttered templates make life easier for child themers, and for us
Justin and Emil noted that in several of our template files, we have a lot of logic to execute before we even get to the HTML. If you need to override one of these templates in a child theme, having all that logic in there adds a lot of complication, as well as increasing the risk that a future update of the parent theme will cause the child theme to become incompatible. For us, this increases the possibility that we will have a lot of redundant code spread throughout multiple template files.
The solution is to move much of that logic into functions elsewhere, and simply use those functions to bring only the pieces of data you need into the template files themselves. This is an area that we’re still working to improve.
Getting a third-party code review is totally worth it
If you’re a theme or plugin developer, and you’re on the fence about having your code reviewed, either before you release it into the wild or even for an established product, we’d encourage you to go for it. Reacting to user bug reports and feature requests will only get you so far in terms of improving your codebase. Getting objective feedback from a trusted third party will not only help you make your product better, but it will help you learn and grow as a developer — both of which are worthy investments. We take pride in the quality of our code here at The Theme Foundry, and getting third-party feedback on it has been a valuable part of making it even better.
So how did Make fare?
In Justin’s words:
I’ve reviewed 100s of WordPress themes and plugins over the years. I’ve seen the good, the bad, and the ugly. However, I can count the number of times on one hand when I’ve seen works of art. If code is truly poetry, then The Theme Foundry is the Shakespeare, Dickinson, and Whitman of our time, all rolled into one. Make and Make Plus represent some of the finest work I’ve seen.
When you’re searching for a WordPress theme, you’re probably not doing so on your mobile device. And when you’re sketching up ideas for a new website for your business, project or startup, it’s unlikely that the vision you’re conjuring is the stacked content and mobile menu toggle that ends up displaying on your iPhone.
We’ve talked about finding and evaluating responsive themes on the blog before, but we haven’t really touched on why it’s critical, especially now, for your website to be accessible to mobile users.
“Well-meaning British friends advised me not to use the term “special relationship” before I came to London. They said it was hackneyed, worn out, a cliché. I listened – then quickly realized when I got here that they were wrong. The US-UK partnership really is exceptional.”
–Matthew Barzun, United States Ambassador to the United Kingdom
It’s always a pleasure to see someone benefiting from one of our themes. And when it’s clear we’re really helping a small business enhance communication with its audience, seeing one of our themes in action is more than just a pleasure; it’s an honor as well.
On other occasions, we’re totally blown away that a certain person or organization has chosen to use one of our designs – and that’s exactly how we feel about this user: the United States Embassy in the United Kingdom.
If you’ve ever switched WordPress themes, you know how frustrating it can be to tweak your site to perfection while it’s live. The whole world can view your changes in real time, not to mention your mistakes. It’s far from ideal, sure, but what choice do you have?
What kinds of websites can you create with our Make WordPress theme? We developed Make to provide versatile design and layout options for a variety of personal and professional sites, and we’ve been reaching out to users to find out how they’re taking advantage of the theme’s powerful features.
One organization doing exciting things with Make is the South Milwaukee Performing Arts Center (SMPAC), which hosts over 500 events each year at its 786-seat theatre. For SMPAC, using the web to connect with the public is crucial – and Make is helping it forge those connections.
By now, few can deny the benefits of responsive website design. The web follows us everywhere, and responsive websites help publishers connect with readers on a variety of devices.
But what constitutes quality responsive design? Adapting content width to screen size is one thing, but providing a seamless, consistent experience across platforms is quite another. With an eye toward how we design responsive WordPress themes at The Theme Foundry, let’s examine some primary building blocks of effective responsive websites.
Our latest theme, Make, features a simple drag and drop page builder interface. It gives you the power to build a professional and responsive website by arranging sections and columns on your page.
We wanted to make the page builder even more flexible by adding support for widget areas in Make Plus. Widget areas unlock all kinds of interesting options. Popular plugins often add custom widgets to WordPress. These widgets can be placed almost anywhere on the page when you’re using the Widget areas that come with Make Plus. Some quick examples of what you can do with widget areas:
Many popular blogs use third-party commenting systems. From social sign in to support for rich media, comment management systems like Disqus and Livefyre bring an array of features to online conversations. Read through these brands’ marketing literature, and you might be convinced that native WordPress commenting is dull and outmoded by comparison.
Yet in spite of the impressive feature suites these two well–heeled organizations bring to the table, WordPress comments still have a lot to offer. In fact, the WordPress comment system provides at least one extremely useful feature for small publishers – a feature neither Disqus nor Livefyre can touch.
Let’s consider that feature and others as we explore the advantages of WordPress native comments and alternative comment applications alike. We’ll begin with the option many of us already know well: the built-in WordPress commenting system.
Earlier this week we released a new version of Make Plus, the powerful companion plugin for our new free drag and drop WordPress theme, Make.
One of the new Make Plus features is Style Kits. Think of them like custom starter themes for Make. Style Kits give you a head start with the design of your Make powered site. When you load a Style Kit, we’ll populate your Customizer design settings for your site with some hand picked style choices. You can then take control and tweak each the individual setting to get things just right.
Here’s the rundown on the rest of the new features we released:
One of our most common customer requests is: “How do I set up my website like the demo website?”. The most obvious answer would be to just hand that customer an unwieldy dump of demo WordPress data to import into their website. A slightly better option would be to add a button to our theme that imports this same dump of data into their WordPress website automatically.
When building Make, we knew we wanted to solve this problem, but neither of these solutions felt like a very nice user experience. Dumping a bunch data into a WordPress site just feels sloppy. We really wanted to find a more intentional approach.