WordPress’s hidden hazards for do-it-yourselfers, Part 2

Continuing with round two of the complain-a-thon and avoiding-the-pitfalls advice for WordPress do-it-yourselfers.
Go to: Part 1 | Part 2 | Part 3 | Part 4

The WordPress theme landscape: an unorganized polyglot of a mess

N
ow, what about the design of your site? Another initial hurdle to clear when you’re first beginning on the road to a self-hosted WordPress site is what it’s going to look like. It’s basically a three-fold choice:

  • Use one of the stock WordPress themes (Twenty Ten, Twenty Eleven, Twenty Twelve, etc.).
  • Go with either a free or premium theme from a third-party developer (i.e., Themeforest, Elegant Themes, or any one of a boatload of other developers).
  • Roll your own.

The stock WordPress themes: ah, ugh. I think the first observation to be made about themes for self-hosted sites is that the stock themes offered by the WordPress core developers mostly suck. It’s not just that the themes are minimalist, because minimalism can be good, but that they are minimalist in a clunky way that just isn’t visually very pleasing.

Perhaps one shouldn’t complain too much about this since the core WordPress developers are primarily coders, but this is a recurrent issue you typically see with any kind of open-source software: the user interface and particularly the graphic design of things are often a serious weak spot. Coders’ brains are just wired differently than most people’s, and specifically they are wired differently than people like graphic designers who are strongly visually oriented.

But if that weren’t enough, coders for some reason almost seem to operate under the hubris of “we don’t need no stinkin’ visual design,” which of course is just the opposite of the truth. More than any other group, coders should be seeking help with the visual design of things, and yet they seem to be the last to acknowledge the need. Or if they do acknowledge it, are painfully slow to actually do something about it.

At any rate, if you don’t care for the simplistic, somewhat graceless look of the stock, core WordPress themes, don’t bother, and don’t worry that you’re alone.

My troubles with themes

Despite my lack of enthusiasm for the stock WordPress themes voiced just above, I did not want to create extra work for myself if it could be avoided. So at first, being the adaptable sort, I thought, well, okay, why not see if I can make one of the stock themes work for me anyway. The clean, basic, if rather uninspiring look of Twenty Eleven suited me kinda sorta okay, more or less (at least it wasn’t obviously clunky like some of the others in the series), so I thought I’d go ahead and first try that.

Sidebar hyphenation in post titles, are you kidding me? But I immediately ran into a silly little problem that, at first, I couldn’t believe the developers had overlooked. Under “Recent Posts” in the sidebar, words in post titles were being hyphenated. Really? You can’t be serious, here!? C’mon, developers, are you really that lazy or idiotic that you don’t notice this? Or worse, don’t care about it, if you do notice it? Maybe some people wouldn’t care, but I did, and to me it was just shoddy. (I can’t quite recall, but it may have been there was some sort of plug-in conflict causing the hyphenation. However, if so, it was a very mainstream plug-in, and the conflict didn’t occur with other themes I tried.)

A simplistic design, okay, I can try to live with it, but shoddiness where broken words appear in the sidebar is just stupid. I couldn’t find any way around the issue, and so at that point, I thought, if this is the kind of carelessness in appearance the core WordPress code geeks think is fine, I’ll go ahead and look elsewhere, thank you very much.

One masthead and only one masthead allowed. So I started looking at Themeforest and other places, and found another theme that was fairly minimalist, and started working with it, but then ran into another problem. And this is another one of those stupid WordPress things, one that few off-the-shelf themes seem to address, but that one would think is a fairly common need. You’ll notice that my site here is actually a combined personal and business site. There is the blog that you’re reading here, but on the main menu bar, there’s a “Work” section to advertise my business services and avocational pursuits.

One of my requirements for doing this is that when one of the “Work” pages is selected — say, “LeewardPro Car Tags” — the masthead image or banner at the top of the page should be customizable to match. In my case, while the overall site masthead may be very similar from one business page of the site to the next (using the same background texture), the customized headline lettering in the masthead that’s highlighted is different for each. And in the future, I’m leaving open the possibility I might want to make the masthead completely different for each different Work page on the site, with a unique layout and graphics for each.

It turns out that many if not most off-the-shelf themes don’t allow for this possibility. Again here, I was a bit dumbfounded that this capability didn’t exist. Wanting to have a different masthead for different pages is hardly any different than having a unique “featured image” for each post or page in WordPress. How hard could it be?

From off-the-shelf themes onward to theme frameworks. Multiple mastheads aren’t really that hard at all, actually, as I was to find out. But to get that to happen, I ended up having to roll my own theme. This, though, entailed first investigating what in the WordPress world are called “theme frameworks.” In a way, these are like custom WordPress themes you can buy, except that they contain their own development environment and tools for creating your own site design by putting together different page layouts.

I was somewhat appalled I might have to go to that length just to be able to change out the masthead on certain pages if I wanted. But it turned out I had no choice, so I decided to tackle it. In the end, I’m glad I did, because it also gave me the “nth” degree of control over many other things I like to fiddle with as a typographer as well. These include such items as the font style, size, color, and all the other attributes one can apply to any and all of the different pieces of type and verbiage that go into a WordPress page or post.

But frankly, if I had been able to get the few simple needs met I’ve just outlined, I might well have gone with an off-the-shelf theme instead.

The vendor lock-in trap with everything-but-the-kitchen-sink themes

Even if you’re not as picky as I am, or don’t have specific “deal-breaker” needs like I did, there’s one critical thing that you need to be aware of when choosing an off-the-shelf theme: Pick the theme based only on its design features, not its functionality.

Theme design vs. publishing functions. “Design” here means the layout of the pages — the size and placement of headlines and text copy in relationship to each other, along with the relationship of those and all the other components of the page with each other: the site header, masthead, navigational menus, the footer, the sidebar, how the comment headings and responses are structured, and so forth.

By contrast, “functionality” means things like social-sharing buttons, maps, contact forms, photo galleries, sliders, tabs, tables, email subscriptions, and so forth. Also included in extra functionality is what are called “custom post types,” also known as custom content types — anything other than a post or a page. (“Posts” are the date/time-based articles you write that are listed in reverse chronological order on a WordPress blog. “Pages” are those that stand outside the chronological post sequence, i.e., independent standalone entries — like the About and Contact Us pages, or product and service pages on a business website.)

Use standalone plug-ins, not custom, built-in theme functions, to keep your theme “portable.” Design and functionality should be handled separately from each other. Any functionality you need that goes beyond the core built-in WordPress functions (i.e., anything you can find in the stock WordPress themes in the Twenty Ten, Twenty Eleven, etc., series) should be handled by plug-ins, not by your theme. Why? The reason is that plug-ins are portable from one theme to the next, whereas if extra functionality is handled by the theme itself, if/when you decide to move to another theme, you will lose any extra functionality built into the previous theme as well. You want whatever functionality you utilize to reside either in the WordPress core or in plug-ins that you can install on top of any theme.

All of the popular, super-duper, everything-but-the-kitchen-sink themes (such as Avada and Divi) build extra functions into the theme itself, which means that you’ll be left high and dry if you employ any of that additional functionality, should you later move to another theme. Yes, these themes look very slick, and you can get going with them at the drop of a hat, and start blogging immediately. If you are aware of the difference between core WordPress functions and the extra functionality built into themes like these, and if your needs are simple or you can be disciplined about using only plug-ins for any added functionality you need, then you might be okay using one of these themes.

What if your theme’s developer goes belly up? Keep in mind that if the developer of one of these all-the-extras-built-right-in themes should ever go out of business, you’ll be left with no more updates, including no more bug fixes.

Just say no to bundled plug-ins. Another issue is that if the theme includes bundled plug-ins from other developers, if security issues develop with those plug-ins but the theme developer doesn’t regularly update their bundled version of the plug-in, you could be hit with security problems. Better that the plug-ins you use should stand on their own separately and not be bundled into the fabric of a theme.

So don’t get trapped. Get in the habit of using standalone plug-ins for the extra functionality you need instead. It’s a modest mental shift but carries big consequences.

Theme developers who won’t lock you in

There are a number of theme developers who have a reputation for focusing on the design component of their themes and not trapping you with extra “vendor lock-in” functionality you’ll regret later. Or if they do add extra functionality, they will put it in a separate plug-in they have authored that you can take with you, if you ever leave. (But it may still be advisable to use a third-party plug-in instead.) Here are a few of these developers:

Themeforest is a “buyer beware” marketplace in terms of both potential vendor lock-in by extra features that may trap you later, as well as its increasingly unsatisfactory reputation for poor code review, as noted on WordPress developer forums. Also, Envato, the company behind Themeforest, is becoming known for nearly always siding with vendors/developers, not customers, when disputes arise.

The seductive, siren call of high-end, photo-driven, photo-dependent themes

Something you almost never see talked about or acknowledged, and I don’t know why, is the fact that most of the flashy, knock-your-socks-off WordPress themes are heavily dependent on liberal use of photographs to pull off their high-class looks. And not just any photos. To really do the job well, we are talking upper-echelon, ad-agency-quality photographs, for the most part. Many people just want to blog, though, and yet if you set up your blog using one of these themes, you are going to find yourself casting about lamely for photos to use. And you’re probably going to find it’s a big burden. Either in time or cost, or both.

Perhaps the reason this tradeoff is rarely brought up is because the “experts” have really been hammering the point home the last several years that photos increase reader engagement. While this is no doubt true, and is definitely important for news and business and tech sites, when it comes to blogs, people don’t care about photos as much. With blogs, visitors come primarily for the writing and information, and mainly they just want to read good posts. Unless any photo you use is directly relevant to your post (not just a generic throwaway), you don’t need to worry about it that much.

If you can easily supply truly good photos and need them, then use them, otherwise don’t. So unless you have a professional editorial staff, or you yourself are a good photographer and have a compelling reason to base your blog around the use of photographs (say, you’re a gardener, for instance, and are showing off your own backyard digs), you really need to ask if you’re going to be able to replicate the look of the demo theme you saw that you found yourself so taken with. Because if you can’t supply good photos, or enough photos, or any photos, the layouts will look lame.

Heck, from what I’ve seen, most people seem to have trouble even just coming up with a single, good, “featured image” photo — often used with individual blog posts — let alone a layout or front page dominated by multiple photos that are always changing. Most people with such sites, other than professional news/editorial sites who utilize such themes, are obviously just plopping in generic images from stock-photo subscription websites. Lame, lame, lame. Did I same lame? LAME.

My advice: If you don’t need photos, don’t use them, and don’t pick a theme that requires them to look good. Or, pick your spots and use them where they really count instead of trying to find additional photos just for the sake of finding them. There are plenty of “minimalist” theme designs around. Find one and use it instead. It will save you a lot of time and headache.

Don’t use photographs just because everyone else says you should. It’s one thing if you have a real need for them. In that case, you definitely need to use them, and you should. Otherwise, quit being a me-too trend-follower and doing what everyone else is just to jump on the bandwagon. Think for yourself.

Rolling your own theme with a theme framework

Very important (2017) update to the section just below: The developer behind the Headway Themes framework has more or less abandoned the product, provides little if any support, and the consensus among current and former users is that it is now a dead-end platform, despite claims to the contrary from the developer. Headway is still being sold, however, without acknowledgment on its website of the lack of support, or the fact the developer has taken a job with another company. As a current user myself (presumably former, at some point), I am looking for an alternative and recommend avoiding Headway.

When it comes to creating your own theme, I don’t have the time or inclination here to get into all the ins and outs, so I’ll just mention a few of the most reputable frameworks that I regularly hear about:

There may be other theme frameworks out there, but the ones above currently (2017) get the most favorable press. Genesis is considered a little better if you are more the get-your-hands-dirty coding type. If you’re less capable coding, Headway would be the preferred choice with a better WYSIWYG (what you see is what you get) interface for laying out pages, and its very thorough menu-based interface for styling various elements on the page. I am refraining from commenting about the pros/cons of each compared with the others since the market is different now than it was when I first made this post.

Headway is what I have used for my website here, although I will say in the same breath that I prefer doing direct coding of CSS for styling the typography on the site. What is good about Headway, though, is even if you don’t use its menus for styling CSS, the menus can still be helpful in targeting the correct CSS selectors to use in your code, which is what I find to be the biggest obstacle with CSS personally, when it comes to WordPress. From my perspective as an I’d-rather-be-blogging-or-designing guy, WordPress pages are a huge pile of layer upon layer of spaghetti-code, and you can waste inordinate amounts of time just figuring out how to target the proper bits of code for styling. So anything that can assist with that is something I appreciate and helps move things along.

Always create a “child theme” separate from the main theme framework. When you’re creating your own theme design with a theme framework like those listed above, be sure to first create your own “child theme,” which is basically a sub-theme container (often literally a folder) where all your own theme customizations go, such as your layout settings, CSS code (i.e., the style.css file, or the like), and any modifications to PHP files such as functions.php. (Exception: Oxygen saves your design customizations separately from the main framework files, and therefore does not require child themes.)

The above is standard advice everyone gives, but can be easy to overlook in the initial enthusiasm of creating your own theme and wanting to jump right in without taking care of important preliminaries first. If you make your theme customizations directly within the theme framework itself rather than in a child theme of it, then whenever the theme framework application is updated, it will wipe out and overwrite all your customizations. If they are in a sub-theme instead, your customizations will load separately, on top of the theme framework, thereby remaining unaffected.

Go to: Part 1 | Part 2 | Part 3 | Part 4

Leave a Comment

css.php