Author: Peter Knight

A guide to choosing a WordPress Plugin and Theme automatic update solution

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.

How to recover a lost or disappeared application window (Windows tip)

So this is an issue I have from time to time and it had me dumbfounded. I would lose a handful of windows of programs I had open and running. The usual trick to retrieving lost windows, or windows that have gone ‘off’ screen is to try one of these:

  • hit alt + tab, click the program thumbnail to select it, then use a keyboard shortcut to move it back on screen
  • hit windows + left arrow key or windows + right arrow key will move a window from left to right. Pressing this repeatedly will move this across screens in a multi-monitor setup
  • hit windows + d to show all windows, or windows + shift + m to restore windows
  • right click the windows taskbar and choose one of the windows display options from the menu

This wasn’t working for me because the application windows in question weren’t being recognized. If you check the task manager (navigate to it with control + alt + del) and you see the program in question running in the processes tab, your program is in fact still running. Then you can try this:


  1. Install process explorer (a free tool hosted by Microsoft)
  2. Run it
  3. Select the relevant program and right click to open up a menu, select “window”, click “bring to front”

Applies when:

  1. When you have lost an application window while the application is still running (verify it is running with task manager)
  2. When the application is not visible as an active program in the windows task bar and can’t be navigated to with alt + tab
  3. When you can’t restore the window by interfacing with its system tray interface (if applicable)

Autoresize for wp_editor (the TinyMCE editor) in WordPress 4.0+

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=””]

The Many Ways David Thorpe Is Wrong About Lebron

This is for sure one the best stories in the 2 decades that I have been an NBA fan.

In one of the most crazy basketball off-seasons ever and leading up to the announcement that Lebron James is returning to Cleveland, some of the most respected media members got it wrong. None surprised me more than David Thorpe’s opinions leading up and after the announcement. Thorpe can be counted on to provide some of the most interesting and astute player analysis in the media landscape, but he’s shown to be a poor judge of psychology and reasoning in this particular case.

David Thorpe had opined that the odds of the Heat breaking up was 1%. He was that sure Lebron would stay with the Heat. Now, it’s hard to get these things right, but that was a pretty unilateral opinion. Other members of the media were much less sure.

Instead of taking the 2 year deal Thorpe foresaw, Lebron is going straight to Cleveland.

After the decision was announced Thorpe was strangely pouring some cold water on the decision.

I remember just how frustrated LeBron looked when the Cavs lost to the Magic. If they fail this year to win…

In his announcement Lebron made clear that his expectations are that a title is not a guarantee. In fact everything I’ve heard from him over the years has emphasized just how hard and precious it is just to get to the finals. For a player of his stature, every year is pressure filled. Every year fans and media expect him to win the title, no matter what team he’s on. He lasted many seasons not winning a title in Cleveland, since then he’s grown in leaps and bounds, proving his mettle as a winner capable of rising above the rest of the playing field and winning titles. A title in Cleveland would be much more meaningful to him. It is dead-on the most logical choice for a competitor at the very top of his game.

Don’t the best athletes want the biggest challenge? What challenge was there left in Miami? It certainly wasn’t any bigger than the one he now has in his home state.

On a disturbing note, returning to fans who despised you and an owner who crushed you, all for doing nothing wrong, is sad.

I don’t see why this needs mentioning while Cleveland is celebrating the return of Lebron. Yes, the hate was poured on hard when he left. But this is the emotion so similar to ones you may experience in a family. They are so passionate because it is like family. And just like with families, not all emotions that are expressed are indicative of how much parties mean to each other. And reunions are not strange, but expected and welcomed, and they deepen the bonds.

David Blatt, welcome to the hottest seat in sports. Maccabi Tel Aviv is a pressure filled place, but nothing like what he is going to face.

The first year coach will have some pressure, but is it true that the team will have championship expectations? I think the fan base will be ecstatic just to have the best player in the world back in the fold, putting all his effort in. We’ve seen the Spurs at the top of their game. Nobody questioned that they were the best team this year. There was no finger pointing that the Heat underachieved. They just played a better team. And frankly, there are going to be 4-5 teams in that elite tier that all have the same pressure of feeling that burning desire to win, because they know they can do it. Cleveland won’t be unique, if anything, the pressure will be less than with the Heat during the first 2 years.

If Bron cares more about returning home than he does his legacy as a champion, it would shock me.But it would not make him any less a player

This statement totally confounds me. It makes total nonsense. His legacy as a champion has a much higher ceiling in Cleveland. Winning a title there will mean more than any of his other titles. He’s taking the path with the higher ceiling. Even if he fails to win another title, nobody can fault him from taking on the challenge. Another title in Miami would have been nice, but not as significant. To paraphrase the words of Chris Bosh, in Miami winning was like a relief rather than a truly satisfying experience.

The Heat marriage always seemed to me like one of convenience. He paired up with some very talented friends and worked with an experienced, top notch organisation. He got what he was looking for. But what he left was a passionate fan base and the home state he felt deeply about. Winning for the Heat fan base is a totally different thing. They feel lucky to have Lebron and so they should be. But the larger portion of the fan base is not as crazy about their team as some other states are. Let’s face it. He had created the perfect conditions for success. A really strong coach, team president and roster while taking advantage of an easier path to the Finals by continuing to come out in the East. Goals were accomplished. A more meaningful challenge awaits.

On paper, just looking at rosters, Miami was already slipping behind the growing quality of elite teams in the West. They weren’t going to be as good as the roster they had during Lebron’s first successful title run. That roster had run its course. Battier is done, UD is done as a thriving role player. The point guard position was a dead end. Wade is never going to be an 82 game a year player again. He couldn’t do it even during the best of conditions. He’s not going to become a 3pt shooter overnight either. They weren’t going to attract high caliber free agents as fortuitously happened in the past either. What fun was there to be had in sticking with the Heat? How rewarding was it going to be anyway? Where the Heat fan base really going to cherish his effort during all the challenges the Heat would face if they didn’t pull together a better roster? Especially if you’ve already achieved what you set out to do.

So David, I love your commentary, in fact I think I’ve seen every one of your TrueHoop appearances this past year and loved all of them, but you were so wrong about Lebron.

PS. I’ve always rooted against Lebron and his team as a fan, but this turn of events has potentially changed that around, and I’m excited to see the new narrative unfold.

An Exploration Of Website Layout Patterns

A blog commenter I came across recently was praising the merits of sticking to the tried and tested layout of a header, title, post content with a sidebar on the left or right and a footer at the bottom. It was a commentary on the complex layout options found in bulky commercial themes and the flexibility marketed in the various page builder plugins. Sticking to a basic layout is simple and it works but also a bit dull. Truth is, most of the popular sites have very unique layout patterns.

Currently I’m working on a theme framework for my WordPress projects and I was looking for a good system to support a large variety of layout use cases. So I went to do a bit of research and explored a sampling of popular sites and attempted to note down broad layout patterns in varying detail.

I looked at sites in a wide browser window, just to maximize the layout possibilities. What struck me was that there’s quite a variety of layouts. Optimal layout has a lot to do with the type of content on offer and so it’s interesting to see the different approaches. There are some interesting trends finding their way into these high traffic sites. Grids are very popular across the board, some sites make decent use of infinite scrolling (pinterest), linear layouts without sidebars have become very popular too (see Paypal’s new home page). Content heavy sites still make heavy use of sidebars, but the way they are implemented is quite diverse. Also interesting is seeing sites utilize a separate sidebar starting at the comments section under an article (SBNation and Techcrunch do that).

I decided to share some notes I took below. It’s not meant to be exhaustive or completely accurate, just an impression really. Thought I might as well publish it as a quasi-interesting work note.



A quick & dirty fix for the devious appearance of nbsp; (non-breaking spaces) in TinyMce editor

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.


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.

Why hiding the publishing date from your posts is bad

If you’re doing research into a topic, one of the most important guides is understanding when resources were published and last updated. I’ve been coming across a lot of theme designs where the author has chosen to hide the post date. It makes efficient research extremely hard.

Knowing when a post was first published and when it was edited gives a reader the ability to figure out the chronology. Even if an older source of information is more informative than a newly published one, it’s important to understand the order in which things were written. This is especially true for problem solving. Figuring out what the most current solution to a problem is vital.

When blog posts are being written in an optimal way, they build upon what has already been written and try to evolve an understanding about a topic. A big part of doing that is respecting the order in which things were written.

On most problem solving quests on google, I will look for the most exhaustive and authoritative resource as well as the most recent ones. Recency is important, because it often will lead to a post where the author has used older resources to build up a better picture or add some new perspective.

Freshness is also a good indicator that a topic is active and being actively thought about. It shouldn’t be made harder to figure out if a certain topic has become stale.

Older posts that have not been updated do not have the benefit of having gleaned from new developments, new solutions and new problems. That doesn’t make a post less valuable, but it has to be abundantly clear that it’s a dated post and may no longer be current.

There really is very little reader benefit to hiding a publishing date in the first place. If you have written evergreen content, that is to say, content that will stand the test of time, it doesn’t mean the post date becomes any less valuable. In fact, it can provide proof that you were the original author, or the first person to make certain statements.

It really baffles me that savvy authors who write on web development topics hide the publish date. This provides a terrible user experience. You are making understanding a topic more of a pain. Don’t make things a bigger puzzle than they need to be.

WordPress In 2014, Predictions and Frictions

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.


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.

Time Tracking and Application Usage Trackers

I was looking at the current state of the market for tools that let you analyze how you’re tracking your time while at your workstation/computer. I’m not talking about general purpose timers, but specifically tools that monitor how long you’re using certain applications and websites in order to build an automated picture of how time is spent on projects. It seems that the two biggest players continue to be RescueTime and TimeDoctor. These are polished solutions and are good in their own right. The biggest problem I see with both of these tools are the data privacy and security implications, as both store your data on their cloud. So I went to see if there were any other tools that work without sending data back to the product’s company.

I wrote up a short list of tools that I found, favoring apps that are free and don’t send back data to the cloud.

ProcrastiTracker <– my pick

The tool I’m currently testing has been created by a very smart solo-developer (currently working at Google) and the software is offered as freeware. Yay! The application has a small footprint and a simple, but powerful interface. It won’t wow you with a flashy UI, but it gets the job done. It’s surprisingly well designed. For example, it can detect inactivity and ask you what you were doing once you get back to your computer. That’s an intuitive way to build a complete picture of one’s usage, considering it would be very easy to forget if one were tracking this completely manually.

Visit Procrastitracker’s site


This tool comes in free and paid versions. The focus with this app seems to be about helping to eliminate distractions. It lets you select applications and sets time limits on them. It also tracks usage time over all the applications and sites that you use. It’s kinda ugly but when you think about it, it shouldn’t be a major stumbling block considering you won’t spend hours on end looking at it. It gets the job done.


ManicTime is more feature-rich compared to above two, and unlike the leading solutions RescueTime and TimeDoctor, data is stored locally. It comes with tagging functionality, stopwatch timers, analysis and reporting tools as well as tracking application usage automatically. For all of the features you will have to pay, but a limited free edition is available too.



Why I Don’t Like Child Themes [WordPress]

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!


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.


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.