From WordPress

Sneak peak of new code snippet plugin for WordPress

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:

.excited {
	font-weight: bold;
	font-size: 3em;
}

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
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.
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.

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.

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.

wp_editor( 
    '', // content
    'yourcustomeditorid', // a unique id in lowercase letters
    array(
        'tinymce' => array(
		'resize' => false, // disables the ability to resize the editor with the mouse
		'wp_autoresize_on' => true // editor expands to fit content
    ) // settings array
);

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.

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.

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.

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.

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!

#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.

Is WordPress Falling Behind? Don’t Believe the Hype

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.

A Personal Note as WordPress Celebrates 10 Years

WordPress is ten years old. It’s been wildly successful and that’s putting it mildly. To celebrate, MarketPress released an interesting infographic. I think the most amazing figure mentioned here is the amount of code that has gone into WordPress. It’s over 200 thousand lines, which they estimate to equate to about 52 years worth of programming. Fifty-two years. Not only is that a testament to the sheer power of open source collaboration, it underlines just how valuable WordPress is as a tool. When you install a free copy of WordPress, you are using software worth millions and millions. I think that’s awesome.

In ten years, WordPress has come a long way. I think one of the most exciting things for me was the increased support for custom post types and taxonomies (strangely omitted from the infographic). I remember when I started my first blog in 2007 on WP 2.1 and was trying to integrate it with a forum software. That’s a 1 minute job these days and I spent weeks trying to figure that one out at the time. It was fun though and getting my hands dirty with code kindled my passion for WordPress and website development. It’s like building with Lego and I love it. With my 6 and a half years’ worth of experience, WordPress still feels fresh to me and I still love learning new things about it.

I expect great things from WordPress going forward, I can only see it growing forward. Future looks bright.

Differences between using get_post() and WP_Query()

WordPress gives developers a number of ways to grab post content from the database. A lot has been written about the differences between using query_posts(), get_posts() and WP_Query, with WP_query being generally favored in most situations. But there is another method called get_post() which can fetch content for a single post, page or custom post object. If you want to output content from a single post object, you could technically use any 4 of these methods.

The question is, where does get_post() fit in with these other methods and what is the best way fetch the content of a single content object in the posts table?

The answer depends on your use case. Let’s say you want to show an excerpt of a specific post in your sidebar, what are the considerations? The get_post() function seems tailor made from grabbing a singular content object, which would make it a pretty obvious choice, but the other methods could also be used. When do you use what?

Ruling out get_posts() and query_posts()

If you’re just polling one object, be it a post, custom post, attachment or page and you know the post id, slug or post title of the object, we can easily rule out query_posts() as it is not a good fit. It wasn’t designed for this purpose and really is about showing multiple posts in a loop.

The difference between get_posts() and get_post() is larger than it seems. The main under-the-hood difference here is that get_posts actually uses WP_query and get_post() does not. So while we can use get_posts just fine for picking a single object, it’s not going to be as efficient as get_post() or as powerful as a custom WP_query. For that reason, let’s talk about the differences between those two.

WP_query vs get_post()

Let’s first look at a simple code example that will give you the same exact output using either method. Following along the lines of our use case example, we are grabbing a post with id 5 and displaying a title and an excerpt to that post.

<?php
// suppose we want to display an excerpt from a post with a post id of 5

// with WP_query

$args = array(
    'p' => 5
);
$custom_query = new WP_query( $args );

if( $custom_query->have_posts() ) {
   $custom_query->the_post();
   the_title();
   the_excerpt();
   wp_reset_postdata();
}
wp_reset_query();

// With get_post()

$get_content = get_post( 5 );
setup_postdata( $get_content );
the_title();
the_excerpt();
wp_reset_postdata();

One of the first things that you might notice is that the WP_Query example uses a loop and the get_post() example does not. The second thing you might notice is that get_post has a simpler way of specifying the post id. Let’s dig deeper into these two visually apparent differences.

On selecting the post object: get_post() vs WP_query

With WP_query you have to take into consideration what post type the object is that you are fetching. It is not enough to supply the ID or name of the post object. For example if it’s a post, you pass a parameter ‘p’ with the value of the post id, or ‘name’ with the name of the post. If it’s a page, you have to supply the parameter ‘pageid’ or ‘pagename’ respectively*. If it’s a custom post type, you have to pass along the post type of the object as a parameter, along with the parameters ‘p’ or ‘name’. With get_post() on the other hand, it’s suffices to supply the ID, name or slug of the post object: it doesn’t matter what post type the object is.

All in all, get_post is simpler that way. If you are coding functionality that lets a user supply any kind of post type, you have add some logic to build your query arguments correctly for WP_query.

Loop vs Non-Loop

With the WP_query example, we are using a loop, with get_post we are not. Why would it matter? Loops are a fundamental part of how typical WordPress themes render content, it’s handy to know a little more about their inner workings. Using a loop comes with some perks, such as the ability to use conditional tags that relate to the post being shown. Various functions provided by WordPress, the theme or a plugin might only work inside a loop and this is something to keep in mind.

If all you want to do is show some basic content from a post object, you might not need the loop and it will be simpler and more efficient to not use a loop.

Under the hood

There is a big difference in the way get_post() and WP_Query fetch content. When using WP_Query, we are running 4 queries to the database by default. One query fetches the data from the posts table, another fetches the custom fields from the meta table, a third query grabs author data from the user table and a fourth query gets data on comments relating to the post object from the comments table. While it is fairly efficient, you may not need all of the extra data and so those calls to the database might be a bit of an unnecessary waste.

With get_post() on the other hand, only one database query is made. You’ll note in the example above though that I’m using the setup_postdata() function (which enables the use of template tags such as the_title() ), which actually makes a database query of its own to grab info about the author. If you want to display author info, custom fields and/or comment data, you might favour WP_Query as it grabs this info for you in one swoop.

If you want to limit database queries to an absolute minimum and you’re only showing content contained in the posts table, there’s another way of writing the above get_post() implementation.

// accessing and rendering raw post data with get_post
$get_content = get_post( 5 );
echo apply_filters( 'the_title', $get_content->post_title ); 
if( $get_content->post_excerpt ) {
   echo apply_filters( 'the_excerpt', $get_content->post_excerpt );
} else {
   echo apply_filters( 'the_excerpt', $get_content->post_content );
}

This example should produce the same result as the previous examples, but it gives you a bit more control over what is going on.

Decision time

So when it comes to picking get_post() or WP_Query for displaying data from a specific post object, here’s a summary of considerations to keep in mind:

  • What data do you need to display? If you want to show comment counts, author data and custom fields, might as well use WP_Query. If you just need the data from the posts table, go with get_post(). You can save database queries with a get_post implementation.
  • Do you need a loop? If you need loop-specific functionality (conditional tags or certain plugin functionality that only works inside a loop), go with WP_Query. If you specifically want to avoid conditional tags working in relation to the post being grabbed, you should go with get_post().
  • UI consideration: Need to let users pick multiple kinds of post type in your user interface? It will be easier to code with get_post as passing parameters with WP_query is a bit more involved (you need to pass the post type as an argument). You’ll get slightly leaner, more elegant code with get_post().

Lastly – especially if you are going with WP_Query – and are concerned about performance you could consider a caching method to improve performance. This is pretty useful if, say, you want to show a certain post snippet in the sidebar on every page.

* With WP_Query you can also use the ‘p’ post id parameter to query a page providing you also set the ‘post_type’ parameter to page.

DesktopServer Review

If you do any kind of development on WordPress, you probably are using localhost to develop on your local machine. It’s noticeably faster than working with a live server, especially while working in the Admin screens of WordPress. For this reason, many people will be familiar with the oh so fun process of setting up local sites and moving sites to live servers. Well in this post I’m going to cover a product that makes local development a much more productive and efficient experience.

The process of setting up a local site for development and moving changes up to an online server is a tedious, painful, needlessly time consuming process. Just setting up a fresh WordPress site on your amp stack is annoying as it involves having to create a database manually, making changes to some configuration files, updating the hosts file and then running the WordPress installation. I was pleased to find a tool that automates all these tasks and it happened to be a tool that is perfect for WordPress development.

Enter DesktopServer

DesktopServer is a brilliant piece of software that is essentially a regular server stack that you will be used to if you have used WAMP, LAMP, XAMPP, MAMP or Uniserver. It actually is packaged with XAMPP Lite, the lite version of XAMPP. The real magic however comes from the logic they’ve included to work with XAMPP Lite. It comes with some powerful automation tools that make it very easy to create, import and export sites and do development on WordPress sites using popular tools.

Turning 10 minutes into less than a 1 minute

Setting up a locally hosted WordPress site in a snapSetting up a locally hosted WordPress site in a snapNow manually setting up a local site on your own machine isn’t terribly difficult once you know all the different steps, but it is a pain. If you’re used to something like Cpanel, which makes installing WordPress really easy, it feels even more annoying to have to manually create a database, configure a virtual host, adjust your hosts file and run through the installer. It can take a good 5-10 minutes if you know exactly what you are doing.

With DesktopServer you can painlessly create a new local site through a simple UI in a matter of seconds. It does all the configuration for you. That in itself is worth jumping for joy, but that’s only a start.

Quickly installing a preconfigured WordPress setup

DesktopServer uses a blueprint model for creating WordPress installations. In that blueprint you can preconfigure WordPress to install with certain plugins and themes. You can even auto-import settings. This is just awesome stuff and saves so much time having to install sets of plugins manually.

Quick Deploy a local site to a live server

A recently improved feature in DesktopServer Premium called quick deploy lets you upload a WordPress site complete with files and database directly to any server that supports Filesystem Direct (supported by many hosts). The resulting magic is facilitated through a plugin that you install on the destination site (you need to have WordPress pre-installed, a fresh install is fine). This is a really nice feature that cuts out a bunch of steps you would otherwise have to perform.

Migrating or moving a site is not a fun task and can be quite challenging. This built in solution let’s you do things at the push of a button while taking advantage of DesktopServer’s automatic scrubbing, so you don’t need to worry about fixing URLs after moving a site online.
Mobile Development options

Another great feature provided by DesktopServer solves the tricky issue of testing local sites on mobile devices. Through Lan sharing (which makes use of the computers IP address on the network), you can make a local site accessible on your mobile phones and tablets. The only caveat here seems to be that you can only share a single site at a time. While I haven’t given it a test turn yet, it also looks like you can make a site available to the web so that people outside your network can view your development site. This feature also uses an IP address which viewers will have to know to access the site. (Side note: I’ve previously covered some other ways to share local sites)

My concerns, squashed

I had a number of concerns prior to trying DesktopServer Premium and I figured I’d write it up in Q&A form.

I want to run a local site that has an extension other than .dev, is that possible?

No problem as it turns out. As you’re really running XAMPP lite, you can manage your own virtual host mappings as you see fit along side any .dev site DesktopServer creates. Setting up non .dev sites can be done manually like you would normally on any AMP setup. I use pagekite to host a private site straight from my computer and I was able to do so without any conflicts. Perfect! The only downer is that DesktopServer only manages and installs .dev sites through its GUI as far as I can tell.

Will it mess with my custom hosts file?

Got a hosts file that you’ve customized with a certain configuration? You won’t have to worry about DesktopServer overwriting anything. It’s smart enough to manage it’s own additions within the file without touching any pre-existing mappings in the file.

Does it automatically adjust hardcoded site urls when migrating?

One of the beautiful things about DesktopServer is that you don’t have to run any kind of find and replace scripts  when you move a site to a different domain. It will do it for you and it even will search your php, css and js files so you’re covered all around.

Minor Niggles

My first month of using DesktopServer was largely positive, I did note a few minor things I’d love to see work their way into an upcoming release.

Live Deploy Progress Indicator

This is what happened when my hosting server failed during quick deploy. My Starcraft honed APM came in good hand closing all these alert boxes.
This is what happened when my hosting server failed during quick deploy. My Starcraft honed APM came in good hand closing all these alert boxes.

The live deploy feature is missing an informative progress indicator. As deploying can take a long time and it is co-dependent on whatever hosting you are using, it would be great to know what it is actually doing or where it is slowing down. Deploying to a live site can be unnerving experience. In my tests I did notice things do take quite long to transfer, but this is very much dependent on the hosting provider and the server’s upload speeds. If you happen to run into a problem during the transfer process, you might have a bit of a problem on your hands.

During one of my tests my (shared) hosting happened to crash, which left me with an incomplete install and a white screen. Of course, no matter what method you use, any migration process won’t fare well under those conditions, but it’s useful to have some kind of indication in case the connection does go wrong. If you’re uploading up a large site, it’s even more important.

One PHP version

DesktopServer ships with the most common PHP/Mysql configuration seen in the wild. If you want to test different versions of PHP, you’re out of luck as DesktopServer doesn’t let you do this out of the box. That would be a fantastic feature to add in the future.

Unmentioned goodness

DesktopServer plays very nicely with a host of other common developers tools, such as Dreamweaver, Xdebug, Coda 2, PHP Storm and popular backup utilities such as Backup Buddy, Duplicator and Infinite WP. So far I have only tested Duplicator, a fantastic free backup plugin and that worked very smoothly indeed.

It’s also worth noting that DesktopServer is not just for WordPress stuff. You can use DesktopServer to create non-WordPress sites for all your other site development and testing purposes

Bottom Line

If you are building WordPress themes/plugins or developing entire sites or applications on WordPress, this software should be part of your tool kit. It’s amazing to me how long this product has been around and I hadn’t really discovered it until recently. More people should be spreading the word.

* Note *
This review was written after using DesktopServer version 3.5 for about a month (I managed to get a review copy). I wasn’t paid to do this review and I do not have any financial ties to Virtuosoft, the company behind of DesktopServer.