WordPress

If you’re moving your WordPress sites to Rochen hosting, here are some potentially useful tips if you’re doing things manually.

First I recommend using All-in-One WordPress Migration plugin to export your existing sites into an export file. This plugin is very smooth with large packages, but does come with a maximum size limit before you have to upgrade to premium. They don’t tell you this until you try to import a package that over 512mb, so it can take you by surprise. Annoyingly, the plugin doesn’t give you a way to filter out unwanted file types (like large zips that may be floating about), so you don’t have a meaningful way of reducing the file size without manually removing stuff. They also use a self-created file format that you can’t open with normal software like 7zip, so you’ll have no luck removing large files manually from there either. However as a workaround, you can adjust the file size limit by modifying the constant ‘AI1WM_MAX_FILE_SIZE’ in constants.php. Set it to 4 >> 28 to get a 1gb file limit.

You could also use the Duplicator plugin. This is another excellent free solution, but the actual import process is not drag and drop. With All-in-One WP Migration all you have to do is install the plugin on the new site and drag and drop the exported file to import. With Duplicator you have to manually upload its files and run the installer outside of WordPress.

Rochen’s panel doesn’t make it immediately obvious how to add apps/sites to your package. If you go looking for a ‘create new site’ or ‘add app’ button somewhere you won’t find it. Provided you opted for a multi-site plan, you can add new sites at no extra charge by going to the manage hosting section. Adding a new site works by selecting the Create new account option from that screen. Once you do this a new site with accompanying cpanel will be provisioned.

You have the option of automatically installing WordPress on the create account step, but it’s useful to know that it’s fixed to use the domain without www. This can be a bit of a gotcha if your exported site is expecting a www based site, as you’ll get a redirect loop when you try to access the site after importing the WordPress database as is. This means you have to manually go into phpmyadmin to change two of the top entries in the options table that define the site/home/installation url just to get to your WordPress admin again (else you may get stuck in a redirect loop). If you are moving a site that defaults to using www, you might as well skip the automatic installation option because you want to preserve the www behaviour in most cases (if Google indexes your pages using the www subdomain, you want to keep it that way). Instead go through the scriptalicious WordPress installation screen from the cpanel after provisioning the site. From there you have options to set the site url. You can easily choose between http:// http://www and https:// and https://www from a drop down menu.

That brings us to SSL certificate installation. This is very easy at Rochen. Find the Let’s encrypt button on the Cpanel screen. From there you can initiate certificates by pressing the ‘issue’ button. It will take you to a screen where you can set what areas will be covered. If you are managing your DNS settings with Rochen this should be all quite automatic. If you are managing things through another service (like Namecheap’s managed DNS for instance), you may have to make adjustments and additions to your domain’s DNS settings. Always give it some time whenever you change a DNS setting before things take effect.

DNS settings are pretty easy, you just have to point your A records to the IP of your Rochen server, which you can find in your control panel. On some of my sites I was using URL redirect records (which Namecheap lets you do) to automatically redirects one domain to the next so I could send people to the www version of the site if they tried using the site without www. I found this messed with the SSL certificate issuing step mentioned above (it insists on installing a certificate for the non-www version), so I changed those entries into standard CNAME records instead.

 

Vue is a very attractive framework for building interfaces that has rapidly become an alternative to other popular tools like React & Angular. It’s lean, it’s fast and it’s actually fun to use while making code easier to read and reason with. It’s beginner friendly while also providing every foundation needed to build out the most complex of apps and websites. It’s great for individual coders but also allows works well in large teams of collaborators.

Why Vue Works Great in WordPress Projects

In a WordPress setting Vue.js is a suitable solution for small pieces of functionality as well as entire themes because it is a small payload. Vue uses html templates that are easy to understand. Unlike some other frameworks, you don’t need tooling to get started. You can include Vue on your page and start creating components without ever touching webpack, node.js or configuring a transpiler without any noticeable dip in performance. Those tools are only required if you want to take the development approach up a notch.

Vue compares favourably to other ways of building interfaces. If you’re just using plain javascript or leveraging jQuery, Vue will help you write less onerous code that is more efficient. More sophisticated tools such as React and Angular have arguably a higher barrier to entry by comparison. Working with css and creating transitions also is easier in Vue. Vue allows you to work with ‘single file components’ where you can easily organize and reason with the different parts that make up a component; javascript logic, html templating and css are kept separate, yet come together in the same file. If you already have mastered any one of these languages, working with Vue may feel much more comfortable to you than working with similar components written for other frameworks.

Another benefit of Vue is that any additional tools you might choose to compliment Vue with are pretty easy to chose. For additional state management help you can add on Vuex, for routing there is vue-router and vue-resource provides a bunch of goodies when making web requests. You don’t have to endlessly research and compare the merits of different competing 3rd party projects like is the case in the React ecosystem (a disadvantage of React’s more sprawling ecosystem).

Learning Vue and Complimentary Tools

The home of the Vue project is noted for its excellence and is the best place to learn the ins and outs of Vue, go visit it here:

Guide to Vue.js

Vuex is a complimentary library that is useful for non-trivial projects that use Vue that you might like. It also comes with excellent documentation from the project’s creator:

What is Vuex

Video tutorials:

Vue.js 2 – Getting Started is a free video series on Youtube by @Maxedapps. If you like the instructor, he also has a paid course on Udemy that is excellent value.

Vue.js 2.0 in 60 minutes by Traversy Media.

Learn Vue2: Step by Step is a free(?) video series on laracasts.

Books:

Learning Vue.js 2 by Olga Filipova

Vue.js 2 Cookbook by Andrea Passaglia

Vue.js 2 Basics: Learn the basics of vue.js and earn your blackbelt by Tony Lea

WordPress Guides & Tutorials

Tutorials by Paulund that cover Vue usage in WordPress.

Josh Pollock wrote one of the first Vue tutorials for WordPress over at TorqueMag, describing how to work with Vue & the REST API.

Here’s is another write up by Josh Pollock on using Vue inside of the admin while taking advantage of ES6

Here you can learn how to create a Vue plugin from Ramsay Lanier, in it he demonstrates a content parsing solution for WordPress use cases.

WordPress Projects Using Vue

Riad has set up a limited experiment for Gutenberg the WordPress editor project which uses Vue instead of React.

Bill Stavroulakis has worked on an offline-first SPA using Vue.js, the WordPress REST API and Progressive Web Apps.

Wyvern provides WordPress theme boiler plate for a Vue project.

RtCamp have created Vue Theme, a starter theme which uses Vue as the basis.

WordVue is starter theme that helps you set up a workflow for a Vue powered WordPress theme

The customizer is one of the newest and most fast developing areas in WordPress. It’s also one of the tougher APIs to code for because there are a lot of moving parts and to get the most out of it you really need to be proficient with the javascript based API as well as the PHP based API. Here is an evolving list of resources that go beyond the Codex pages to help developers out as they build out their own customizer functionality.

Code Examples For Working With the Customizer API by the Theme Review Team

Various examples of working with the Customize API, such as creating simple and advanced panels/sections/controls/settings. But it’s mostly PHP and doesn’t touch much on the client side of things.

Code Example For Creating a Postmeta Based Customizer Setting

This is a working example of a postmeta based customizer setting by Weston Ruter. Note that some of this code won’t transfer seamlessly to, say a custom post type scenario without some adjustments, because it hardcodes for a post type of post.

The Complete Guide to the WordPress Theme Customizer

Daniel Pataki does a good job walking through a more complete tour of what you might be able to accomplish with JS driven logic.

Dependently-Contextual Customizer Controls

Weston Ruter guides you on creating Customizer controls that instantly toggle on or off depending on state using client-side logic. (see related gist)

Resetting the Customizer to a Blank Slate

A useful starting point if you want to create a dedicated customizer setup that is separate from the default experience.

Customizer tutorials and documentation

An older post by Justin Tadlock grouping some guides and articles on the customizer

And lastly two streams of resources of new guides and updates on the customizer are here:

XWP’s Make Blog Covering The Customizer

And the Make blog covering the customizer on WordPress.org:

Make Blog posts Tagged with Customizer

 

Writing code examples inside the WordPress editor is a lousy experience with most plugins. Most of them involve writing down shortcodes, using clunky input dialogs and messing with spacing because tab functionality doesn’t work properly. Syntax highlighter implementations also tend to be onerous, they are often clunky and bloaty and load too much stuff. In fact I was so fed up with existing plugins that I stopped posting code tutorials on this site.

Ever since Tinymce got updated to the v4+ branch new things have become possible with the editor. One of the coolest things is the ability to live preview shortcode output right inside the (visual) editor, as well as easily adding a graphical user interface for these shortcodes. It is an order of magnitude more user-friendly. I don’t think any of the existing code plugins have jumped on board the live-preview train yet, so I decided to implement a solution myself.

I made some nice progress with a plugin I have dubbed ‘Code Shower’. Below is a sneak peak.

here’s an example of how a (css) code snippet looks on the front-end:

[codeshower ui_state=”” language=”text%2Fcss” code=”.excited%20%7B%0A%09font-weight%3A%20bold%3B%0A%09font-size%3A%203em%3B%0A%7D”]

And here is a screenshot of how it looks inside the familiar WordPress post editor:

This shows the live preview inside the WordPress editor displaying my css code snippet

And below is what the graphical interface looks like when inserting a new code snippet. It still needs some polish, but it should give you an idea.

This is a pop dialog that shows when adding or editing a code snippet inside the editor.

There is still some work to do. Right now I am testing the plugin and it does have a dependency on a commercial plugin I’ve developed called Super Content Widget Pro. I’m probably going to make a it free for customers of Super Content Widget Pro, but we’ll see. Would you be interested in a plugin like this? Let me know.

 

If you have created a commercial or private plugin or theme and want to provide automatic updates for your product a number of solutions are available to you. With so many different avenues, which one is best for your project?

Code your own updater

There are a few guides out there that show you how to write the code for a basic plugin/theme updater. Notable sources:

Professional WordPress Plugin Development – a foundational book that you should have read if you are serious about WordPress development, it includes a section that shows you how to code an updater.

A Guide to the WordPress HTTP API: Automatic Plugin Updates – a tutsplus article

The benefit of coding your own is that you can keep things nice and simple. If you are needing more sophisticated features, you might find your time is better invested by using an existing solution instead.

Use an existing free updater framework

There are a couple of freely usable frameworks out there that you can get up and running very quickly, notable sources (all can be found on github):

1) W-Shadow has a plugin & theme updater as well as a server script to act as a repository. The server code is not dependent on WordPress, which is both a pro and a con, although it can be easily integrated into a plugin. You can quite easily customize it if you are open to getting your hands dirty with code (if you want to add in your own authentication protocols for example). The code isn’t formatted to WordPress guidelines which can be a bit jarring if you are customizing it. One perk is the ability to parse a zip package and extra all the meta information out of it so you don’t have to type this information out redundantly through an interface or in a script.

2) Automatic Theme & Plugin Updater for Self-hosted themes and plugins by Jeremy Clarke. This I haven’t tested and doesn’t appear to be maintained.

3) Reaktiv Remote Repo. This was created by Aaron Norcross, a reputed and trusted developer. It’s simple, easy to read and integrate. What’s not to love.

Purchase an off-the-shelf self-hostable solution

There are a couple of turn-key commercial solutions

Easy Digital Download has a commercial licensing add-on for software. EDD itself is free and this is a paid add-on, the developer is of a high standard and has managed to create a community around his products.

Woocommerce Software Add-on. It is pricey for an add-on, but it runs off the most popular e-commerce solution for WordPress.

Auto Hosted. The most cost-friendly of the bunch and also the most feature complete.

Sign up to a Hosted Updater Service

There are some pros and cons to using a hosted service.

Pros: you don’t have to maintain the relevant code, it’s all taken care of you. You don’t have to worry about your server going down. There are quite a few extra features that you get.

Cons: you have to worry whether the service sticks around and if the service goes down that can affect your customer relations. The cost grows with time when you pay per month. You have less control over the process. Most importantly though is that you are handing out data to another party and entrusting them to manage it responsibly. If a hosted service is compromised it could send malicious updates. Another business concern is the analytics you give them. By letting them handle your product updates you effectively share your sales data with another company that could bed used or shared in undesirable ways.

WP-Updates. It looks to be a very streamlined and easy to implement solution and also very price friendly. The company behind it is Dev7Studios (which appears to be run by a pair of developers) which has quite a portfolio of products. This is both a good sign and a bad sign. Good because they are likely to stick around long and bad because they might be(or become!) your competitor with one of their products and you would be arming them with valuable analytics.

SellWP is a fully featured solution that also takes care of a shopping cart and all of the other components need to sell WordPress products. It really is designed to get you selling your product as soon as possible. Unlike any other product, the pricing is based on sales and not on a fixed monthly or yearly fee. I think this is great and it’s especially good for those starting out. SellWP is run by a single developer; this might mitigate some of the concerns I have with having another commercial entity have access to valuable analytics, but it’s also a potential risk when a single person is a point of failure. If you are running an appreciable amount of business it would be important to have a plan B in place just in case.

A lovely feature finding its way into the default post editor for WordPress is autoresizing. This means that you no longer have to scroll up and down inside the editor, it will expand to fit your content automatically removing the scrollbars. It is even better now that the toolbar will always stay in view.

If you are using wp_editor to create custom editing instances, you can take advantage of this feature too. Previously I was using an autoresize plugin for TinyMCE but now it is as simple as passing in a setting.

[codeshower ui_state=”” language=”php” code=”wp_editor(%20%0A%20%20%20%20”%2C%20%2F%2F%20content%0A%20%20%20%20’yourcustomeditorid’%2C%20%2F%2F%20a%20unique%20id%20in%20lowercase%20letters%0A%20%20%20%20array(%0A%20%20%20%20%20%20%20%20’tinymce’%20%3D%3E%20array(%0A%09%09’resize’%20%3D%3E%20false%2C%20%2F%2F%20disables%20the%20ability%20to%20resize%20the%20editor%20with%20the%20mouse%0A%09%09’wp_autoresize_on’%20%3D%3E%20true%20%2F%2F%20editor%20expands%20to%20fit%20content%0A%20%20%20%20)%20%2F%2F%20settings%20array%0A)%3B” linenumber=””]

Sometimes when pasting content into WordPress’ native tinymce editor, non-breaking space characters appear in the output where there should be spaces. You can verify this is this issue by inspecting the source code in your browser’s dev tools. As a result text may break outside of its container and give a disastrous look. When troubleshooting this, you look at the editor in Text or Visual mode there appear to be just normal spaces. Strange.

My first instinct is to see if there are any content filters going on at the front-end. A common instigator for markup issues can be wp_autop() or some other filtering function. This was not the case though.

So I decided to correct the problem at the source, since the issue was happening with pasted text inside the tinymce editor.

It goes like this:

1) open up dev tools in your browser (control + shift + i for Chrome on Windows)

2) go to the console tab

3) Here you can enter commands. We are going to run some manual lines of jQuery/js . Make sure you have the visual mode enabled.

var contents = jQuery('#content_ifr').contents().find('#tinymce').html();

This stores the content that tinyMCE is working with in a variable.

var filtered = contents.replace(/ /g, ' ');

This filters that content and replaces non-breaking spaces with normal spaces. Note that this also gets rid of deliberate/manual instances of non-breaking spaces. If you need to preserve these, you’ll need more complex code or you’ll need to reapply them manually.

jQuery('#content_ifr').contents().find('#tinymce').html(filtered);

This replaces the tinyMCE window with the filtered content.

4) Update the post. Check on the front-end. And now your text should look proper.

January is always a good time to think forward and I thought I’d put down some thoughts around where I think the WordPress’s products space might be headed. What makes my particular take interesting? Well, I’ve think I’ve started to pick up on a few things that haven’t been talked about too much.

Mobile

It would be hard to start projecting 2014 without first addressing the elephant in the room:

mobile has become so big that you can no longer avoid it.

If your site is not performing well for your mobile users, you really have to address that this year. Frankly, the typical WordPress site stinks in terms of performance. Even sites that are using themes that are advertised as ‘mobile ready’ and ‘responsive’ deliver poor user experience. So why is that and can we expect better this year?

The problem that the surge of mobile devices has brought to the table is the sheer complexity and difficulty of delivering good site experiences across all platforms and machines.

It’s hard.

Really hard.

There are many unsolved and perhaps unsolvable parameters involved in designing for the web. Say the words ‘responsive images’, ‘bandwidth/network performance’ and ‘typography’ and watch web developers heads crumble. There are no elegant solutions for these pain points because there are no elegant means to predict what kind of software is being used to display a site, what the capabilities are (like detecting touch), what kind of connection a user has (dial-up, mobile data plan, wifi, whatever it is, it can make a world of difference), or how poorly that neat font is going to render. There are ways and tools, but none of them are definitive, particularly clean or full proof.

In other words, it’s a mess. But we have to live with it. And do the best we can.

So having said that, I do think we’re going to see far more attention paid to performance on mobile. But I also think the typical site is going to continue to be a pretty poor experience on mobile devices. That’s not all bad, because you can really stand out if you really hit the nail on the head and deliver for your users. The main obstacle that faces clients is one of perception. There is this notion out there that WordPress can do all of this great stuff (true of course). But the notion extends to this idea that you just have to load up some responsive theme that has a few media queries and now you are done.

So here’s a reality check some clients will need to hear

If you need a strong presence on mobile, don’t expect that a turn key solution is going to do the job for you. Expect to spend a lot of time thinking through your mobile web presence. If you are making your existing site more mobile friendly, you will have to think hard on how to do that. There are no hard and fast rules to rely on. In many cases, you can’t expect to just shuffle around some boxes. To do it right requires a well thought out plan. You need to put yourself in the shoes of your mobile users and think about how they want to consume and interface with your site in that setting.

But there’s an upside to that too. Because it means putting your imagination in the brains of your audience and only good things can come from better understanding your audience. You’ll also find out that this process requires a lot of simplification and that will bring you precious clarity about what you are trying to accomplish across the board.

The Rise Of The WordPress Powered Application: Revealing a Tension

Even more interesting to me is the rise of the WordPress application. Oh yes, you better believe it, there will be more WordPress applications coming in 2014. And this idea of running an app on top of WordPress brings about an interesting dilemma. I’m not talking about how WordPress might not be suitable as an App framework. Lots of purists will say that by the way. But these same people also rubbish WordPress in general despite that it’s by far the most popular CMS on the market, showing zero signs of slowing. I think WordPress will be fine as an App framework in lots of situations, but not all. But, that’s not the issue I think.

What is the dilemma then?

Currently there are 2 familiar building blocks that are mixed to create a highly functional WordPress site. We have WordPress themes and we have WordPress plugins. The two are to be considered as accomplishing two very separate matters. The themes handle the visual presentation and the plugins provide under the hood functionality.

Of course, the lines between what themes do and what plugins do have gotten much blurrier over the years. There are plugins that do a lot of presentation stuff, there are themes that incorporate a lot of functionality. In 2013 we’ve seen lots of push back against this. Theme authors were packaging too much functionality into their themes. Especially the more expert developers in the community have pointed out the perils of doing that. And as theming has become more popular, a general emphasis on coding quality has reached beyond a niche group of developers to the wider community. The most visible evidence of this came when ThemeForest decided to raise their theme requirements, in turn causing considerable revolt among its base of theme authors.

But there’s an interesting dilemma here that isn’t quite being addressed by a pathological desire to meet coding standards and conform to best practices. This too is a perception problem.

On a code and file system level, we want to uphold the highest possible standards. This is good for everyone involved. It makes everything better and conversely, doing the opposite only serves to increase problems. The basic guideline is a golden one: use plugins for functionality and let your theme focus solely on presentation.

I’m perfectly fine with this guideline, but it doesn’t address this problem we have of dealing with situations where the lines get blurred. Think of the new users, a client perhaps, or someone just getting into WordPress. These people think in terms of solutions to what they want to accomplish. They buy, download and install solutions. They don’t go out to download plugin files and theme files.

We’ve been treating plugins and themes like separate units. That makes sense on a code and file organization level, but it doesn’t make sense in terms of selling a solution. If you want to sell a solution that involves plugin stuff along with a theme, because that’s kind of how we look at it, it’s a pain. We have to go out of our way to include some kind of plugin installer that runs when we install a theme and then ask the user if they want to add this and that plugin. It’s an entirely fragmented and overly complicated process. But we kinda have to do it that way, because, you know, it’s very important that we treat plugins and themes as separate things.

Now, some people are so against the horror of themes packing all kinds of functionality that they rail against it blindly. Now some are trying to dictate what a theme should do or not do. And I do get it. It truly is not ideal to have all kinds of functionality code in your theme folder. It locks you in, it’s hard to maintain, it makes things messier. It’s not the way to go. But we do need a way to sell solutions that feel like a cohesive unit, a combination of files that accomplishes certain things for our business. To a certain extent, maybe we need to look at how we regard the whole process of installing components in WordPress. There should be a cohesive, nice way to install solutions.

And this point is the perfect time to get back to the other trend I mentioned: the rise of the WordPress application. You see, applications perfectly highlight this weird friction in WordPress surrounding the two types of building blocks called the theme and the plugins. How can you go about installing an application on WordPress? How does a WordPress developer sell a solution without causing their customers headaches? Must the user oversee a complicated installation process that juggles plugin folders and theme folders? I should hope not.

I would love to say I have the perfect solution to offer up here. But I do think whatever is going to happen, it will also have to change the perception about how we install solutions using WordPress.

And I know the problem is real. Right now there’s a very interesting project happening called o2. It’s the spiritual successor to the P2 theme. The P2 theme is perhaps one of the earliest kinds of WordPress applications and definitely one of the most successful. It has tons of logic in its files. It doesn’t operate like a normal theme because it really is a community type tool, with front-end posting being its most prominent feature. The successor o2 is only widening that gap between what the normal theme does and what o2 does. In fact, calling it a theme is not even appropriate. It is an application with tons of client side javascript goodness. There are even rumblings of having Node.js power some of the back-end. Now we’re definitely outside of traditional WordPress solution territory! That is exciting. It will reshape how we think about WordPress.

Something I’m most looking forward to seeing is how the o2 team is actually going to package it up. What’s the installation process going to be like? Will it be a plugin? Will there be extra server requirements (node.js?), will it rely on a 3rd party service? How will it go about doing that?

Beyond Plugins and Themes

Thinking about this paradigm of plugin vs theme packages, what would be the evolution of that? How can we have people thinking of installables as solutions and have them installed that way? I’m not completely sure what it would look like. Maybe it would be called a package installer or a solution installer. It could contain plugins and theme files, but behind the scenes installation logic would handle all the specifics. To the user, they would just be installing a solution. I kind of like the idea behind that.

New terrritory

This year will also be the year many WordPress developers will get their feet wet creating actual mobile applications. This is not a terribly bold prediction because just recently a new tool as arrived on the scene called AppPresser which has the potential to be the gateway that was needed to get web oriented WordPress developers to start coding for mobile. What AppPresser does is handle a bunch of the details in meshing up with another bridging tool: Phonegap. What Phonegap does is provide a way to code an application using html, css and js and install it as a mobile application. Phonegap exposes a mobile’s device features through javascript, allowing you to really take advantage of what mobile has to offer while living in the web based technology stack you are already comfortable with.

Another not so bold prediction is this: there will be a lot of mediocre WordPress powered apps springing up. This seems a bit harsh, right? We now have the right tools for the job don’t we?

Creating really good mobile apps is not easy. People coming from developing on WordPress will face an entirely new learning curve. It requires a much higher attention to detail to performance. To give an example, with the average WordPress theme you can get away with not having to think too hard about CSS rendering performance issues, but those are magnified on mobile devices.

There is also that danger that people will think that you can just create a decent turn key solution now that the tools are here. Just because the tools make it possible, does not make it easy. I predict there will plenty of sluggish apps with less than stellar performance that are sold to clients on low budgets.

AppPresser itself also does not (yet) assist much in the way of offline support. Meaning, currently AppPresser built apps will be pretty much reliant on an internet connection. The folks have understated how important offline functionality is (because lots of other apps require an internet connection too). It means – I believe – that really good apps built via AppPresser will have to figure out how to close the gap between the performance of ‘real’ native apps and those mediated by PhoneGap and a WordPress site.

To give AppPresser some credit here, they have definitely signaled to would-be developers that this is not a solution to turn just about any WordPress theme into an app. They don’t advertise it as turn key in such. They clearly want to avoid having to be associated with low quality apps that you particularly see with tools that promise a no-coding click and build solution.

Having said all that, AppPress could accelerate the evolution of WordPress as a whole. Very exciting!

So, about 2014

In my world WordPress is a bit like building with Lego and we are growing the kinds of creations we can make with it as well as expanding on how we can reach, surprise and delight people. What I love most about using WordPress as the foundation for a rich experience is that it can be self-hosted, it’s fully open source, it’s highly adaptable and easy to install. This is such a great alternative to using a multitude of 3rd party companies that dictate what is done with your data and what can and cannot be done with an app or site.

This year will bring will be the most creative year in WordPress yet.

And 2015?

One trend I haven’t mentioned, purely because it will take at least another year, is a fuller realization of this idea of WordPress as an operating system for the web. This trend I’m talking about would bring WordPress even closer to its users. It’s having WordPress as a backbone for self-hosted applications running on small, tiny networking computers that you can buy for trivial prices. I think we may see WordPress expanding into this new area. The two key indicators here are the emergence of the affordable plug computer (such as the Raspberry Pi), an easy to use operating system, such as arkOS, and the increasing desire among users to gain more control over one’s own data. This could open the door to all kinds of cool applications that could be built using WordPress, such as a private diary, a fitness logging tool, a notepad-like tool, a social network for your family. All these things could run on your own network soon, with hardware you own and software you can use freely. The possibilities are endless.

When working with WordPress themes, child themes are the promoted way of making customizations to a theme. The logic is pretty simple on paper, the child theme inherits all the functions and styles of the parent theme, but you are now able to overwrite anything you like with your own CSS and add your own template tweaks.

There are a lot of benefits to child themes. One great thing is that you only have to deal with the stuff you want to change in your child theme directory, while you can let the parent theme take care of the rest. Often, all you want to change is some css and that makes organizing your child theme fairly easy as you can get away with using a single file. Most importantly though, the child theme method makes it so that the parent theme can be safely updated (right?).

When I first started with WordPress, it wasn’t that common for themes to get updates and if they did, it was a manual uploading process. Now, it’s far more common for themes to get frequent updates and the update api is similar to that of plugins with push button updates. Nobody really likes updating, especially if it’s a theme because you worry about whether it is going to mess with your design. But updating you must (right?) to stay current with the most recent code base and fix bugs and security issues that are uncovered. Child themes, on the face of it, are designed to protect your customizations.

So child themes are important and provide a lot of benefits. What’s not to love?

Well, consider these common scenarios that child themes can try to tackle and let’s see how well it performs.

Scenario #1: A non-designer/developer wants to make some small css edits

The problem with child themes from the perspective of a regular user who’s not familiar with WordPress coding, is that they first need to understand that they need to make a child theme. If they get that far, they have to figure out how. And to actually set one up requires a bunch of steps. You need to have a basic understanding of how parent themes and child themes relate to each other. They need to create a directory in your themes folder, setting up the stylesheet and so forth. Those are all technical tasks that require a user to work around in the file system. Now it’s important to add that some themes package up a child theme and I think there is a plugin that makes spawning a child theme with a click of a button possible. For sure, a push-button solution to setting up a child theme, that’s a wonderful thought. Even with that, child themes are kind of an abstract concept for a new user to have to come to grips with. Are child themes really needed to make some small tweaks?

Scenario #2: Tweaking templates

If there’s a great case for using child themes, it’s to change how some templates display content, right? Say for instance, you want to move the publish date display from the top to the bottom of a post. Well that’s easy with child themes. You take your template file from the parent theme, copy it to the child theme, modify to your heart’s content and voilà. Oh wait, it’s not showing up on pages, just on posts. No worries, let’s also copy page.php to the child theme directory and make the same edits. Before you know it, you are digging through all the templates and making wholesale copies and edits and your child theme directory all of sudden looks a lot like your parent theme directory. I mean, this is not a terrible thing, but has it made our world that much brighter and clearer? I don’t know.

Scenario #3: Making non-trivial changes to the theme

Let’s say you are making largish modifications to a theme. You want to create this novel front page layout, you are adding sidebars to pages, you are changing how excerpts are displayed and adding templates for some custom post type. All your modifications live in the child theme and so the parent theme can be easily updated without overwriting anything you wrote. Perfect right? Except you update your theme and all of a sudden you find your theme is broken. What?! That’s not supposed to happen. Well it can, given the right circumstances. Just because you’ve prevented updates from overwriting what you wrote, doesn’t mean it’s impervious to breaking when the parent theme gets updated. So we can throw out the idea of carefree updating just because we adopted the child theme methodology.

The other potential issue when making big changes to a theme inside a child theme is that the likelihood of veering off of how things are coded in the parent theme becomes a bit higher. Because the code is more isolated from the parent theme, some users might code things in such a different way than is done by the parent theme. This can lead to confusing situations, as well as a higher likelihood of things breaking on updates. Consider the most common alternative to child themes: copying a theme and renaming it (also has downsides, mind you), you are far more likely to fit your code into the way things are done in the original theme.

Scenario #4: Extending a base theme or framework & theme skins

Another nice use case for child themes is the way it allows theme developers to work off a base theme. That way you can build on a great foundation and create something more unique on top of it. These base themes tend to be updated frequently – all the more reason to use a child theme. What’s not so ideal about this way of creating themes is that it makes things more complicated. If a user wants to modify your child theme, it has to create… wait for it… a grandchild theme. And now we have files for our themes living in three parallel directories. Let’s say a consultant builds you such a grandchild theme and now you need to make some modifications… do you want to create a great grandchild theme? I bet you do.

So now there’s a bunch of things going on. Imagine the cognitive overhead with files living in multiple directories, inheriting stuff. Updating a parent, grandparent or even a great-grandparent theme adds a whole new layer of breakage possibilities. Happy debugging that, newbie! Oh, sorry, are you confused when browsing wp-content/themes/ and you don’t remember what theme is what among all the other themes you’ve downloaded? Yes, the theme hierarchy is not reflected in the file system where you make your edits, so stay sharp!

#holdon

Grandchild themes aren’t actually natively supported so you wouldn’t get the same ease of implementation as you do with child themes even if you wanted to go that route. It begs the question, if grandchild themes aren’t really the solution for these situations, users have to do things differently anyway. Kind of limits the child theme methodology in the first place.

Now, from a theme developer perspective, selling child themes is a tough sell. Try explaining to your users that they need this parent theme installed but not activated. If you are working with a commercial parent theme, you lock your theme’s faith to whatever the parent theme’s developers decide to do with it (or not). Instructing users on editing your child theme is not something to get excited about either.

The myth of solving theme updates

Themes can get updated. Some themes get updated often and some do not. The prevailing mantra is: updating is critically important! Child themes solves issue of people updating, supposedly. Except it doesn’t do it really that well. Stuff can break regardless of being faithful to the child theme paradigm. This is why some people don’t update. Who wants to hit the update button if you know you could be in misery the moment you see your site has been screwed up? You have stuff on your schedule, and solving problems you didn’t need or ask for wasn’t on it! So if people are reluctant to update, at best we can say the child theme setup is only partially delivering on its promise.

But wait, think about this themes getting updates thing. Why are theme updates important to start with?

Take plugins for example, if you don’t update them, you might be missing serious security fixes or performance boosting improvements. Plugins are almost always critically important to keep up to date. But if a theme needs a security patch, it’s probably doing something it shouldn’t be doing in the first place. Many themes try to stash far too much functionality in the theme. Functionality that absolutely should be living in plugins. If themes are created and chosen properly, there would be very little reason to solve a ‘critical security fix’.

Simply put, the child themes paradigm doesn’t tackle the problem of updates at the root.

There are, of course, more reasons a theme gets updates. Usability fixes, improvements, added templates, better file organization, updated support for new WordPress functions. The thing is, a particular theme update might not affect the working of your site at all, good or bad. You probably don’t care that your theme has better multilingual support, fixed bugs with it’s right-to-left language support or added some post format that you are not going to use, ever, anyway. I’m not saying that all updates are trivial, I’m just saying that the need to update a theme as they come out is not important by definition.

When an important update does come out, an alert webmaster can also check to see what the actual changes are and work that in manually if they didn’t go the child theme route. In fact, you might have to do that anyway if those updates would affect your own custom code.

If the person who manages the site isn’t alert, how likely are they to hit that update button anyway? The semi-alert webmaster might hit the update button automatically and then become embroiled in a site debugging session. If there are changes in the parent theme, the code in your child theme may need updating too – so you have to spend time investigating. The end result is the same, either you are being mindful about your WordPress installation, or you are not – hassle free updates are no guarantee. Child themes don’t really tackle the problem that beautifully.

Another road block to using child themes

So you decided you want to make some updates that warrant the creation of a child theme. Your client decided the site needs to be responsive! Let’s get to work on a child theme then. Except the moment you switch to the child theme, you lose a f&ckload of settings that you have to migrate. Oh what fun! And this is the point where I imagine many people decide to edit the parent theme instead. If child themes are so important to use, why is it such a pain?

Functions.php hell

Child themes don’t do anything to actually improve coding practices all that much. Function.php hell continues to exist. Need to tweak your theme’s functionality, stick it in the functions.php. Create a functions.php in a child theme! Yeah. Now we’re doing things proficiently. Wait, no.

Endlessly long functions.php with disorganized snippets are not the answer. Some users are smart and use file organization, but it’s still a bunch of functions living in your theme directory. It’s not ideal. Often functions end up in there, when they are theme agnostic. And even when they are theme specific, a better place to stick certain functionality code is inside plugins.

But you really can’t blame people for this practice because the better alternative is not straightforward enough. I’m all for creating small plugins that handle specific functionality. But creating plugins is a leap for new users and a slight hassle for experienced users as well. There’s no ‘create-a-mini-plugin button’ in the interface. You have to create it all yourself. But the benefits are very nice. You can create functionality that will work in your next theme (custom post type registrations for example) without moving code around. You can toggle small plugins on and off which makes troubleshooting things much easier. If you make mistake, the plugin is deactivated instead of crashing your theme. And – by having it in a plugin – you won’t have to touch your theme’s files.

Alternatives

My frustration with child themes in WordPress stems from the fact that there are better ways to do things. There are alternatives to be had. They are not all perfect, but I will cover some of them in an upcoming article out in a day or two. In the mean time, what do you think could be a better way of dealing with customized themes?

ps. Sign up to my newsletter if you are interested in catching the follow up article.

 

WordPress is the leading CMS on the web today, powering 1 in every 5 websites on the web according to some sources. It has become the incumbent and with that comes a truckload of daily criticism. Outsiders mock the code, or the alleged lack of security, the performance, how it is a terrible choice for anything other than a blog or how it has become bloated as a blog platform. Meanwhile, new, hip looking platforms pop up right and left, some of them outright claiming to be modern WordPress replacements. Meanwhile, one business owner with the largest WordPress community of customers outside of ThemeForest claims to be nervous about how slowly WordPress seems to innovate.

Most of these criticisms or negative viewpoints around WordPress are, to my mind, just the noise generated that come with the territory of by being a comparatively mature platform with a dominant position in the market. Sometimes we find big corporations with monopolies fall behind and crumble at the mercy of small new innovative start-ups because innovation is not embraced. One of the reasons might be because the bigger you get, the slower you can transform. Is WordPress like that?

Yes, a little, but mostly NO.

The negativity around WordPress in some circles is simply overhyped. People quickly forget or fail to understand what makes WordPress so powerful. It’s more than just the code, it’s the community and the ecosystem that has evolved out of it. More importantly, it’s the open source foundation its based on: a vision of making publishing on the web easy and inclusive to all, building something beautiful on free software principles. In a single concept, it’s about freedom.

When people demonstrate some other product that is supposed to compete with WordPress, they typically gloss over what actually WordPress provides. They say: “see this new platform, it’s more minimalist, it’s simpler and more beautiful to use! It’s so much better than WordPress.” Forget that it’s only good for simple sites that require only minimal functionality, the bigger point is that it’s a fools errand to make comparisons based on one or two features while blanking out on the enormously rich ecosystem and ethos around WordPress.

Or they say how much better the code is because it uses a trendier language, compared to the much maligned PHP. Except the trendier language is not as widely available as PHP, making the barrier to entry higher. Except the fact that PHP abundantly has proved to work despite its shortcomings. And overlooking the fact that virtually all platforms, WordPress included, are becoming more Javascript centric anyway.

It’s relatively easy to start a new, lean product that does a handful of features well and starts out with a nice looking interface and fresh code base. But when that product matures over the years, the code base will grow, features will be added (or not) and after a while, people will be lamenting how bloated it has become, or how it doesn’t adopt certain principles, or how it has lost its vision, or how it can no longer make radical changes without upsetting all its users. And that is if it gets any lasting traction. The majority of new software initiatives simply fail and wither before they even reach that stage.

WordPress is one of the biggest success stories of Open Source software. What are the odds of any open source project growing into something so large? Pretty small. That is one reason alone to not buy into the hype of any young product that is aiming to out-innovate WordPress. So many things need to align for something to grow so successfully.

Is WordPress innovating fast enough?

Let’s be real, of course WordPress needs to keep innovating or it will fall behind. But its pace of innovating is probably perfectly fine.

There will always be an urge to have a knee-jerk reaction when some other platform accomplishes some feature in a ‘sexy’ way. If anything, the desire to integrate a similar feature over too quickly leads to bad decision making. A case could be made that the efforts to integrate a new post formats UI (something Tumblr does well) has been a frustrating affair because not enough vision was applied to how it fits in with WordPress and its vast user base.

Some of the exciting developments in WordPress don’t really pop out to most end-users just by reading the feature lists. WordPress as a tool is getting better. There are tens of thousands of hours going into WordPress from developers all around the world. That’s some seriously valuable work that you get to play with when you develop on top of WordPress.

Some of the coolest developments to me involve the api improvements. These open up new possibilities that you just couldn’t easily and robustly do in the past. In the near future WordPress will integrate a new JSON api (now available as a plugin), making the creation of rich client side functionality even easier than before. The better the tool gets, the more developers can do with it. And it’s what people do with the tool that impacts innovation more than anything. What awesomely innovative things can you do with Medium? Tumblr? Ghost? Any fill-in-the-blank static site generator? Or one of the many generic click and point site builders? It doesn’t compare to what you can do with WordPress. Not even close.

There are innovation pains

It would be false to say there aren’t any issues with innovating the WordPress code base. The burden of backward compatibility does make an impact. Integrating real big changes into WordPress can take many releases. Considering that releases tend to take their time, some of the more exciting things can take a long time to materialize. Things like an api for custom comment types, a better infrastructure and api for making relationships between different types of data in the WordPress database, a less cluttered back-end experience, better front-end controls. All of these things take a long time to do properly. Take the widgets API – now being addressed as a feature as a plugin – it will not be radically improved in WordPress 3.8. Instead it will get some smaller UI improvements. A big do over for a component that is used by millions can’t be rushed. This is something all successful products have to contend with.

Another measure of innovation

While WordPress core may move slowly for some, this is not the only way to measure innovation. With every new release developers are able to do more with WordPress. Some older products that were built on top of WordPress had to work really hard to get certain functionality into WordPress. Now those kinds of functions have become much easier to implement (forums, memberships sites, ecommerce functionality). Whether it’s because the API has become better or things have gotten easier to setup, the ability to innovate on top of WordPress just grows. End-users just care about results and there is a huge user base for developers to build innovating products for, leveraging all that WordPress provides.

Let’s put this in a different way. If you are complaining about the lack of innovation in WordPress, build something more innovative. The choice is this, either start from scratch and burden yourself with the need to code up all kinds of basic functionality needed for a platform, or get a multi-million dollars worth head start with WordPress that also happens to have the biggest user base of all CMS-es. I know what platform I’m using and I’m certainly not worried about WordPress falling behind. If something radically better surfaces, would I consider using it? Frankly, the odds of that happening right now are small and it won’t happen overnight. It takes a long time to make something truly great.