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=””]
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.
Sometimes when pasting content into WordPress’ native tinymce editor, non-breaking space characters appear in the output where there should be spaces. You can verify this is this issue by inspecting the source code in your browser’s dev tools. As a result text may break outside of its container and give a disastrous look. When troubleshooting this, you look at the editor in Text or Visual mode there appear to be just normal spaces. Strange.
My first instinct is to see if there are any content filters going on at the front-end. A common instigator for markup issues can be wp_autop() or some other filtering function. This was not the case though.
So I decided to correct the problem at the source, since the issue was happening with pasted text inside the tinymce editor.
It goes like this:
1) open up dev tools in your browser (control + shift + i for Chrome on Windows)
2) go to the console tab
3) Here you can enter commands. We are going to run some manual lines of jQuery/js . Make sure you have the visual mode enabled.
var contents = jQuery('#content_ifr').contents().find('#tinymce').html();
This stores the content that tinyMCE is working with in a variable.
var filtered = contents.replace(/ /g, ' ');
This filters that content and replaces non-breaking spaces with normal spaces. Note that this also gets rid of deliberate/manual instances of non-breaking spaces. If you need to preserve these, you’ll need more complex code or you’ll need to reapply them manually.
jQuery('#content_ifr').contents().find('#tinymce').html(filtered);
This replaces the tinyMCE window with the filtered content.
4) Update the post. Check on the front-end. And now your text should look proper.
January is always a good time to think forward and I thought I’d put down some thoughts around where I think the WordPress’s products space might be headed. What makes my particular take interesting? Well, I’ve think I’ve started to pick up on a few things that haven’t been talked about too much.
Mobile
It would be hard to start projecting 2014 without first addressing the elephant in the room:
mobile has become so big that you can no longer avoid it.
If your site is not performing well for your mobile users, you really have to address that this year. Frankly, the typical WordPress site stinks in terms of performance. Even sites that are using themes that are advertised as ‘mobile ready’ and ‘responsive’ deliver poor user experience. So why is that and can we expect better this year?
The problem that the surge of mobile devices has brought to the table is the sheer complexity and difficulty of delivering good site experiences across all platforms and machines.
It’s hard.
Really hard.
There are many unsolved and perhaps unsolvable parameters involved in designing for the web. Say the words ‘responsive images’, ‘bandwidth/network performance’ and ‘typography’ and watch web developers heads crumble. There are no elegant solutions for these pain points because there are no elegant means to predict what kind of software is being used to display a site, what the capabilities are (like detecting touch), what kind of connection a user has (dial-up, mobile data plan, wifi, whatever it is, it can make a world of difference), or how poorly that neat font is going to render. There are ways and tools, but none of them are definitive, particularly clean or full proof.
In other words, it’s a mess. But we have to live with it. And do the best we can.
So having said that, I do think we’re going to see far more attention paid to performance on mobile. But I also think the typical site is going to continue to be a pretty poor experience on mobile devices. That’s not all bad, because you can really stand out if you really hit the nail on the head and deliver for your users. The main obstacle that faces clients is one of perception. There is this notion out there that WordPress can do all of this great stuff (true of course). But the notion extends to this idea that you just have to load up some responsive theme that has a few media queries and now you are done.
So here’s a reality check some clients will need to hear
If you need a strong presence on mobile, don’t expect that a turn key solution is going to do the job for you. Expect to spend a lot of time thinking through your mobile web presence. If you are making your existing site more mobile friendly, you will have to think hard on how to do that. There are no hard and fast rules to rely on. In many cases, you can’t expect to just shuffle around some boxes. To do it right requires a well thought out plan. You need to put yourself in the shoes of your mobile users and think about how they want to consume and interface with your site in that setting.
But there’s an upside to that too. Because it means putting your imagination in the brains of your audience and only good things can come from better understanding your audience. You’ll also find out that this process requires a lot of simplification and that will bring you precious clarity about what you are trying to accomplish across the board.
The Rise Of The WordPress Powered Application: Revealing a Tension
Even more interesting to me is the rise of the WordPress application. Oh yes, you better believe it, there will be more WordPress applications coming in 2014. And this idea of running an app on top of WordPress brings about an interesting dilemma. I’m not talking about how WordPress might not be suitable as an App framework. Lots of purists will say that by the way. But these same people also rubbish WordPress in general despite that it’s by far the most popular CMS on the market, showing zero signs of slowing. I think WordPress will be fine as an App framework in lots of situations, but not all. But, that’s not the issue I think.
What is the dilemma then?
Currently there are 2 familiar building blocks that are mixed to create a highly functional WordPress site. We have WordPress themes and we have WordPress plugins. The two are to be considered as accomplishing two very separate matters. The themes handle the visual presentation and the plugins provide under the hood functionality.
Of course, the lines between what themes do and what plugins do have gotten much blurrier over the years. There are plugins that do a lot of presentation stuff, there are themes that incorporate a lot of functionality. In 2013 we’ve seen lots of push back against this. Theme authors were packaging too much functionality into their themes. Especially the more expert developers in the community have pointed out the perils of doing that. And as theming has become more popular, a general emphasis on coding quality has reached beyond a niche group of developers to the wider community. The most visible evidence of this came when ThemeForest decided to raise their theme requirements, in turn causing considerable revolt among its base of theme authors.
But there’s an interesting dilemma here that isn’t quite being addressed by a pathological desire to meet coding standards and conform to best practices. This too is a perception problem.
On a code and file system level, we want to uphold the highest possible standards. This is good for everyone involved. It makes everything better and conversely, doing the opposite only serves to increase problems. The basic guideline is a golden one: use plugins for functionality and let your theme focus solely on presentation.
I’m perfectly fine with this guideline, but it doesn’t address this problem we have of dealing with situations where the lines get blurred. Think of the new users, a client perhaps, or someone just getting into WordPress. These people think in terms of solutions to what they want to accomplish. They buy, download and install solutions. They don’t go out to download plugin files and theme files.
We’ve been treating plugins and themes like separate units. That makes sense on a code and file organization level, but it doesn’t make sense in terms of selling a solution. If you want to sell a solution that involves plugin stuff along with a theme, because that’s kind of how we look at it, it’s a pain. We have to go out of our way to include some kind of plugin installer that runs when we install a theme and then ask the user if they want to add this and that plugin. It’s an entirely fragmented and overly complicated process. But we kinda have to do it that way, because, you know, it’s very important that we treat plugins and themes as separate things.
Now, some people are so against the horror of themes packing all kinds of functionality that they rail against it blindly. Now some are trying to dictate what a theme should do or not do. And I do get it. It truly is not ideal to have all kinds of functionality code in your theme folder. It locks you in, it’s hard to maintain, it makes things messier. It’s not the way to go. But we do need a way to sell solutions that feel like a cohesive unit, a combination of files that accomplishes certain things for our business. To a certain extent, maybe we need to look at how we regard the whole process of installing components in WordPress. There should be a cohesive, nice way to install solutions.
And this point is the perfect time to get back to the other trend I mentioned: the rise of the WordPress application. You see, applications perfectly highlight this weird friction in WordPress surrounding the two types of building blocks called the theme and the plugins. How can you go about installing an application on WordPress? How does a WordPress developer sell a solution without causing their customers headaches? Must the user oversee a complicated installation process that juggles plugin folders and theme folders? I should hope not.
I would love to say I have the perfect solution to offer up here. But I do think whatever is going to happen, it will also have to change the perception about how we install solutions using WordPress.
And I know the problem is real. Right now there’s a very interesting project happening called o2. It’s the spiritual successor to the P2 theme. The P2 theme is perhaps one of the earliest kinds of WordPress applications and definitely one of the most successful. It has tons of logic in its files. It doesn’t operate like a normal theme because it really is a community type tool, with front-end posting being its most prominent feature. The successor o2 is only widening that gap between what the normal theme does and what o2 does. In fact, calling it a theme is not even appropriate. It is an application with tons of client side javascript goodness. There are even rumblings of having Node.js power some of the back-end. Now we’re definitely outside of traditional WordPress solution territory! That is exciting. It will reshape how we think about WordPress.
Something I’m most looking forward to seeing is how the o2 team is actually going to package it up. What’s the installation process going to be like? Will it be a plugin? Will there be extra server requirements (node.js?), will it rely on a 3rd party service? How will it go about doing that?
Beyond Plugins and Themes
Thinking about this paradigm of plugin vs theme packages, what would be the evolution of that? How can we have people thinking of installables as solutions and have them installed that way? I’m not completely sure what it would look like. Maybe it would be called a package installer or a solution installer. It could contain plugins and theme files, but behind the scenes installation logic would handle all the specifics. To the user, they would just be installing a solution. I kind of like the idea behind that.
New terrritory
This year will also be the year many WordPress developers will get their feet wet creating actual mobile applications. This is not a terribly bold prediction because just recently a new tool as arrived on the scene called AppPresser which has the potential to be the gateway that was needed to get web oriented WordPress developers to start coding for mobile. What AppPresser does is handle a bunch of the details in meshing up with another bridging tool: Phonegap. What Phonegap does is provide a way to code an application using html, css and js and install it as a mobile application. Phonegap exposes a mobile’s device features through javascript, allowing you to really take advantage of what mobile has to offer while living in the web based technology stack you are already comfortable with.
Another not so bold prediction is this: there will be a lot of mediocre WordPress powered apps springing up. This seems a bit harsh, right? We now have the right tools for the job don’t we?
Creating really good mobile apps is not easy. People coming from developing on WordPress will face an entirely new learning curve. It requires a much higher attention to detail to performance. To give an example, with the average WordPress theme you can get away with not having to think too hard about CSS rendering performance issues, but those are magnified on mobile devices.
There is also that danger that people will think that you can just create a decent turn key solution now that the tools are here. Just because the tools make it possible, does not make it easy. I predict there will plenty of sluggish apps with less than stellar performance that are sold to clients on low budgets.
AppPresser itself also does not (yet) assist much in the way of offline support. Meaning, currently AppPresser built apps will be pretty much reliant on an internet connection. The folks have understated how important offline functionality is (because lots of other apps require an internet connection too). It means – I believe – that really good apps built via AppPresser will have to figure out how to close the gap between the performance of ‘real’ native apps and those mediated by PhoneGap and a WordPress site.
To give AppPresser some credit here, they have definitely signaled to would-be developers that this is not a solution to turn just about any WordPress theme into an app. They don’t advertise it as turn key in such. They clearly want to avoid having to be associated with low quality apps that you particularly see with tools that promise a no-coding click and build solution.
Having said all that, AppPress could accelerate the evolution of WordPress as a whole. Very exciting!
So, about 2014
In my world WordPress is a bit like building with Lego and we are growing the kinds of creations we can make with it as well as expanding on how we can reach, surprise and delight people. What I love most about using WordPress as the foundation for a rich experience is that it can be self-hosted, it’s fully open source, it’s highly adaptable and easy to install. This is such a great alternative to using a multitude of 3rd party companies that dictate what is done with your data and what can and cannot be done with an app or site.
This year will bring will be the most creative year in WordPress yet.
And 2015?
One trend I haven’t mentioned, purely because it will take at least another year, is a fuller realization of this idea of WordPress as an operating system for the web. This trend I’m talking about would bring WordPress even closer to its users. It’s having WordPress as a backbone for self-hosted applications running on small, tiny networking computers that you can buy for trivial prices. I think we may see WordPress expanding into this new area. The two key indicators here are the emergence of the affordable plug computer (such as the Raspberry Pi), an easy to use operating system, such as arkOS, and the increasing desire among users to gain more control over one’s own data. This could open the door to all kinds of cool applications that could be built using WordPress, such as a private diary, a fitness logging tool, a notepad-like tool, a social network for your family. All these things could run on your own network soon, with hardware you own and software you can use freely. The possibilities are endless.
When working with WordPress themes, child themes are the promoted way of making customizations to a theme. The logic is pretty simple on paper, the child theme inherits all the functions and styles of the parent theme, but you are now able to overwrite anything you like with your own CSS and add your own template tweaks.
There are a lot of benefits to child themes. One great thing is that you only have to deal with the stuff you want to change in your child theme directory, while you can let the parent theme take care of the rest. Often, all you want to change is some css and that makes organizing your child theme fairly easy as you can get away with using a single file. Most importantly though, the child theme method makes it so that the parent theme can be safely updated (right?).
When I first started with WordPress, it wasn’t that common for themes to get updates and if they did, it was a manual uploading process. Now, it’s far more common for themes to get frequent updates and the update api is similar to that of plugins with push button updates. Nobody really likes updating, especially if it’s a theme because you worry about whether it is going to mess with your design. But updating you must (right?) to stay current with the most recent code base and fix bugs and security issues that are uncovered. Child themes, on the face of it, are designed to protect your customizations.
So child themes are important and provide a lot of benefits. What’s not to love?
Well, consider these common scenarios that child themes can try to tackle and let’s see how well it performs.
Scenario #1: A non-designer/developer wants to make some small css edits
The problem with child themes from the perspective of a regular user who’s not familiar with WordPress coding, is that they first need to understand that they need to make a child theme. If they get that far, they have to figure out how. And to actually set one up requires a bunch of steps. You need to have a basic understanding of how parent themes and child themes relate to each other. They need to create a directory in your themes folder, setting up the stylesheet and so forth. Those are all technical tasks that require a user to work around in the file system. Now it’s important to add that some themes package up a child theme and I think there is a plugin that makes spawning a child theme with a click of a button possible. For sure, a push-button solution to setting up a child theme, that’s a wonderful thought. Even with that, child themes are kind of an abstract concept for a new user to have to come to grips with. Are child themes really needed to make some small tweaks?
Scenario #2: Tweaking templates
If there’s a great case for using child themes, it’s to change how some templates display content, right? Say for instance, you want to move the publish date display from the top to the bottom of a post. Well that’s easy with child themes. You take your template file from the parent theme, copy it to the child theme, modify to your heart’s content and voilà. Oh wait, it’s not showing up on pages, just on posts. No worries, let’s also copy page.php to the child theme directory and make the same edits. Before you know it, you are digging through all the templates and making wholesale copies and edits and your child theme directory all of sudden looks a lot like your parent theme directory. I mean, this is not a terrible thing, but has it made our world that much brighter and clearer? I don’t know.
Scenario #3: Making non-trivial changes to the theme
Let’s say you are making largish modifications to a theme. You want to create this novel front page layout, you are adding sidebars to pages, you are changing how excerpts are displayed and adding templates for some custom post type. All your modifications live in the child theme and so the parent theme can be easily updated without overwriting anything you wrote. Perfect right? Except you update your theme and all of a sudden you find your theme is broken. What?! That’s not supposed to happen. Well it can, given the right circumstances. Just because you’ve prevented updates from overwriting what you wrote, doesn’t mean it’s impervious to breaking when the parent theme gets updated. So we can throw out the idea of carefree updating just because we adopted the child theme methodology.
The other potential issue when making big changes to a theme inside a child theme is that the likelihood of veering off of how things are coded in the parent theme becomes a bit higher. Because the code is more isolated from the parent theme, some users might code things in such a different way than is done by the parent theme. This can lead to confusing situations, as well as a higher likelihood of things breaking on updates. Consider the most common alternative to child themes: copying a theme and renaming it (also has downsides, mind you), you are far more likely to fit your code into the way things are done in the original theme.
Scenario #4: Extending a base theme or framework & theme skins
Another nice use case for child themes is the way it allows theme developers to work off a base theme. That way you can build on a great foundation and create something more unique on top of it. These base themes tend to be updated frequently – all the more reason to use a child theme. What’s not so ideal about this way of creating themes is that it makes things more complicated. If a user wants to modify your child theme, it has to create… wait for it… a grandchild theme. And now we have files for our themes living in three parallel directories. Let’s say a consultant builds you such a grandchild theme and now you need to make some modifications… do you want to create a great grandchild theme? I bet you do.
So now there’s a bunch of things going on. Imagine the cognitive overhead with files living in multiple directories, inheriting stuff. Updating a parent, grandparent or even a great-grandparent theme adds a whole new layer of breakage possibilities. Happy debugging that, newbie! Oh, sorry, are you confused when browsing wp-content/themes/ and you don’t remember what theme is what among all the other themes you’ve downloaded? Yes, the theme hierarchy is not reflected in the file system where you make your edits, so stay sharp!
#holdon
Grandchild themes aren’t actually natively supported so you wouldn’t get the same ease of implementation as you do with child themes even if you wanted to go that route. It begs the question, if grandchild themes aren’t really the solution for these situations, users have to do things differently anyway. Kind of limits the child theme methodology in the first place.
Now, from a theme developer perspective, selling child themes is a tough sell. Try explaining to your users that they need this parent theme installed but not activated. If you are working with a commercial parent theme, you lock your theme’s faith to whatever the parent theme’s developers decide to do with it (or not). Instructing users on editing your child theme is not something to get excited about either.
The myth of solving theme updates
Themes can get updated. Some themes get updated often and some do not. The prevailing mantra is: updating is critically important! Child themes solves issue of people updating, supposedly. Except it doesn’t do it really that well. Stuff can break regardless of being faithful to the child theme paradigm. This is why some people don’t update. Who wants to hit the update button if you know you could be in misery the moment you see your site has been screwed up? You have stuff on your schedule, and solving problems you didn’t need or ask for wasn’t on it! So if people are reluctant to update, at best we can say the child theme setup is only partially delivering on its promise.
But wait, think about this themes getting updates thing. Why are theme updates important to start with?
Take plugins for example, if you don’t update them, you might be missing serious security fixes or performance boosting improvements. Plugins are almost always critically important to keep up to date. But if a theme needs a security patch, it’s probably doing something it shouldn’t be doing in the first place. Many themes try to stash far too much functionality in the theme. Functionality that absolutely should be living in plugins. If themes are created and chosen properly, there would be very little reason to solve a ‘critical security fix’.
Simply put, the child themes paradigm doesn’t tackle the problem of updates at the root.
There are, of course, more reasons a theme gets updates. Usability fixes, improvements, added templates, better file organization, updated support for new WordPress functions. The thing is, a particular theme update might not affect the working of your site at all, good or bad. You probably don’t care that your theme has better multilingual support, fixed bugs with it’s right-to-left language support or added some post format that you are not going to use, ever, anyway. I’m not saying that all updates are trivial, I’m just saying that the need to update a theme as they come out is not important by definition.
When an important update does come out, an alert webmaster can also check to see what the actual changes are and work that in manually if they didn’t go the child theme route. In fact, you might have to do that anyway if those updates would affect your own custom code.
If the person who manages the site isn’t alert, how likely are they to hit that update button anyway? The semi-alert webmaster might hit the update button automatically and then become embroiled in a site debugging session. If there are changes in the parent theme, the code in your child theme may need updating too – so you have to spend time investigating. The end result is the same, either you are being mindful about your WordPress installation, or you are not – hassle free updates are no guarantee. Child themes don’t really tackle the problem that beautifully.
Another road block to using child themes
So you decided you want to make some updates that warrant the creation of a child theme. Your client decided the site needs to be responsive! Let’s get to work on a child theme then. Except the moment you switch to the child theme, you lose a f&ckload of settings that you have to migrate. Oh what fun! And this is the point where I imagine many people decide to edit the parent theme instead. If child themes are so important to use, why is it such a pain?
Functions.php hell
Child themes don’t do anything to actually improve coding practices all that much. Function.php hell continues to exist. Need to tweak your theme’s functionality, stick it in the functions.php. Create a functions.php in a child theme! Yeah. Now we’re doing things proficiently. Wait, no.
Endlessly long functions.php with disorganized snippets are not the answer. Some users are smart and use file organization, but it’s still a bunch of functions living in your theme directory. It’s not ideal. Often functions end up in there, when they are theme agnostic. And even when they are theme specific, a better place to stick certain functionality code is inside plugins.
But you really can’t blame people for this practice because the better alternative is not straightforward enough. I’m all for creating small plugins that handle specific functionality. But creating plugins is a leap for new users and a slight hassle for experienced users as well. There’s no ‘create-a-mini-plugin button’ in the interface. You have to create it all yourself. But the benefits are very nice. You can create functionality that will work in your next theme (custom post type registrations for example) without moving code around. You can toggle small plugins on and off which makes troubleshooting things much easier. If you make mistake, the plugin is deactivated instead of crashing your theme. And – by having it in a plugin – you won’t have to touch your theme’s files.
Alternatives
My frustration with child themes in WordPress stems from the fact that there are better ways to do things. There are alternatives to be had. They are not all perfect, but I will cover some of them in an upcoming article out in a day or two. In the mean time, what do you think could be a better way of dealing with customized themes?
ps. Sign up to my newsletter if you are interested in catching the follow up article.
WordPress is the leading CMS on the web today, powering 1 in every 5 websites on the web according to some sources. It has become the incumbent and with that comes a truckload of daily criticism. Outsiders mock the code, or the alleged lack of security, the performance, how it is a terrible choice for anything other than a blog or how it has become bloated as a blog platform. Meanwhile, new, hip looking platforms pop up right and left, some of them outright claiming to be modern WordPress replacements. Meanwhile, one business owner with the largest WordPress community of customers outside of ThemeForest claims to be nervous about how slowly WordPress seems to innovate.
Most of these criticisms or negative viewpoints around WordPress are, to my mind, just the noise generated that come with the territory of by being a comparatively mature platform with a dominant position in the market. Sometimes we find big corporations with monopolies fall behind and crumble at the mercy of small new innovative start-ups because innovation is not embraced. One of the reasons might be because the bigger you get, the slower you can transform. Is WordPress like that?
Yes, a little, but mostly NO.
The negativity around WordPress in some circles is simply overhyped. People quickly forget or fail to understand what makes WordPress so powerful. It’s more than just the code, it’s the community and the ecosystem that has evolved out of it. More importantly, it’s the open source foundation its based on: a vision of making publishing on the web easy and inclusive to all, building something beautiful on free software principles. In a single concept, it’s about freedom.
When people demonstrate some other product that is supposed to compete with WordPress, they typically gloss over what actually WordPress provides. They say: “see this new platform, it’s more minimalist, it’s simpler and more beautiful to use! It’s so much better than WordPress.” Forget that it’s only good for simple sites that require only minimal functionality, the bigger point is that it’s a fools errand to make comparisons based on one or two features while blanking out on the enormously rich ecosystem and ethos around WordPress.
Or they say how much better the code is because it uses a trendier language, compared to the much maligned PHP. Except the trendier language is not as widely available as PHP, making the barrier to entry higher. Except the fact that PHP abundantly has proved to work despite its shortcomings. And overlooking the fact that virtually all platforms, WordPress included, are becoming more Javascript centric anyway.
It’s relatively easy to start a new, lean product that does a handful of features well and starts out with a nice looking interface and fresh code base. But when that product matures over the years, the code base will grow, features will be added (or not) and after a while, people will be lamenting how bloated it has become, or how it doesn’t adopt certain principles, or how it has lost its vision, or how it can no longer make radical changes without upsetting all its users. And that is if it gets any lasting traction. The majority of new software initiatives simply fail and wither before they even reach that stage.
WordPress is one of the biggest success stories of Open Source software. What are the odds of any open source project growing into something so large? Pretty small. That is one reason alone to not buy into the hype of any young product that is aiming to out-innovate WordPress. So many things need to align for something to grow so successfully.
Is WordPress innovating fast enough?
Let’s be real, of course WordPress needs to keep innovating or it will fall behind. But its pace of innovating is probably perfectly fine.
There will always be an urge to have a knee-jerk reaction when some other platform accomplishes some feature in a ‘sexy’ way. If anything, the desire to integrate a similar feature over too quickly leads to bad decision making. A case could be made that the efforts to integrate a new post formats UI (something Tumblr does well) has been a frustrating affair because not enough vision was applied to how it fits in with WordPress and its vast user base.
Some of the exciting developments in WordPress don’t really pop out to most end-users just by reading the feature lists. WordPress as a tool is getting better. There are tens of thousands of hours going into WordPress from developers all around the world. That’s some seriously valuable work that you get to play with when you develop on top of WordPress.
Some of the coolest developments to me involve the api improvements. These open up new possibilities that you just couldn’t easily and robustly do in the past. In the near future WordPress will integrate a new JSON api (now available as a plugin), making the creation of rich client side functionality even easier than before. The better the tool gets, the more developers can do with it. And it’s what people do with the tool that impacts innovation more than anything. What awesomely innovative things can you do with Medium? Tumblr? Ghost? Any fill-in-the-blank static site generator? Or one of the many generic click and point site builders? It doesn’t compare to what you can do with WordPress. Not even close.
There are innovation pains
It would be false to say there aren’t any issues with innovating the WordPress code base. The burden of backward compatibility does make an impact. Integrating real big changes into WordPress can take many releases. Considering that releases tend to take their time, some of the more exciting things can take a long time to materialize. Things like an api for custom comment types, a better infrastructure and api for making relationships between different types of data in the WordPress database, a less cluttered back-end experience, better front-end controls. All of these things take a long time to do properly. Take the widgets API – now being addressed as a feature as a plugin – it will not be radically improved in WordPress 3.8. Instead it will get some smaller UI improvements. A big do over for a component that is used by millions can’t be rushed. This is something all successful products have to contend with.
Another measure of innovation
While WordPress core may move slowly for some, this is not the only way to measure innovation. With every new release developers are able to do more with WordPress. Some older products that were built on top of WordPress had to work really hard to get certain functionality into WordPress. Now those kinds of functions have become much easier to implement (forums, memberships sites, ecommerce functionality). Whether it’s because the API has become better or things have gotten easier to setup, the ability to innovate on top of WordPress just grows. End-users just care about results and there is a huge user base for developers to build innovating products for, leveraging all that WordPress provides.
Let’s put this in a different way. If you are complaining about the lack of innovation in WordPress, build something more innovative. The choice is this, either start from scratch and burden yourself with the need to code up all kinds of basic functionality needed for a platform, or get a multi-million dollars worth head start with WordPress that also happens to have the biggest user base of all CMS-es. I know what platform I’m using and I’m certainly not worried about WordPress falling behind. If something radically better surfaces, would I consider using it? Frankly, the odds of that happening right now are small and it won’t happen overnight. It takes a long time to make something truly great.
Mastering Javascript is something I’ve set out to do. Truth be told, it’s a weird language. When I encounter a resource that elucidates in an exemplary fashion, I feel great gratitude. I’m compiling a list of articles and resources here that do an extraordinary job at explaining Javascript programming topics.
Understanding scope
This is the clearest tutorial on scope, contexts and the this variable that I have read.
Binding Scope in Javascript
Learning Regex
Regular expressions are used in many languages and mastering it is incredibly useful. When I first started, it was very confusing to me. This site is fantastic at helping one understand regex.
Regex 101
Javascript/jQuery Design Patterns
Learning Javascript Design Patterns is a book by Addy Osmani, who produces outstanding learning materials. The unbelievable part is that the book can be had free.
Learning Javascript Design Patterns
Javascript Video Resources
A fantastic curated list of the best video presentations on Javascript
There are a number of ways to bind event handlers to elements with jQuery, a popular one called live() is deprecated since version 1.7 so people are advised to replace this in their code. The live() method was great for committing event handlers to elements that were dynamically inserted after page load. Now the right method to use is on() which is relatively new and its benefits have been discussed at length. Just like live(), on() is able to attach event handlers to newly inserted elements, perfect right? But there’s a bit of a gotcha.
Converting instances of live() to on() is going to be straightforward most of the time (see how), but you still may run into trouble. A potential issue has to do with how event delegation is dealt with. Event delegation is important to take advantage of because it replaces the need to add a multitude event handlers attached to separate elements by applying one event handler to a single parent element. When assigning event handlers in this way – say, because you want to add some click hanlders to buttons inside the rows of a table – you usually pick the most efficient parent element. The broader the parent element, the less efficient and less robust things become, so it is important to make the parent element as near as possible.
If you are adding event handlers inside a table, the obvious choice might be the table element.
$('table').on("click", "a.addrow", function(){
// do stuff
});
That will work fine if this table element was present on page load. But what if the table was added dynamically? And this is where you might get confused (I certainly did). The thing is, it won’t work if your parent element was dynamically added. It has to be an element that was present on page load.
The problem:
When setting the parent element with the on() method, this element must be present on the page, elements added later are ignored.
Solutions
Applying event delegation to a broader parent element
One easy solution is to set a broader parent element that you know for sure exists after page load has finished. There can be some drawbacks to this which are mostly relevant in situations where you do not control all the elements on the page to start with. In these case you might be tempted to append the event handler to something like the body element, because you can be certain this element will be on the page. But the broader the element, the more likely it is that something else could prevent your event handler firing. If the environment has a lot of other scripts running, the chances increase that a conflict might occur. This is especially true if you are coding something like a WordPress plugin and have to contend with dozens of other scripts you can’t control.
In the best case scenario, you pick an element with a specific ID that is one level higher up the dom. This is going to be more efficient than say, a class name or something higher up the DOM.
// table would later be inserted here
$('#tablewrap').on("click", "table a.addrow", function(){
// do stuff
});
Attaching event handlers when elements are inserted
The second solution involves setting the event handlers when the relevant elements are inserted. There are a couple of possible scenarios that may apply and a few ways to implement this. I’ll cover one or two to illustrate the general idea.
So let’s say groups of elements are being inserted into the page with jQuery’s .clone() method and you want the new clone to have the same event handlers. If this is your own code doing so, you can easily opt to do a deep clone and copy all of the event handlers. This way all the event handlers that apply to the element that is being cloned will apply to the clone. This is as easy as setting a few parameters:
instead of using .clone() without parameters set, use .clone(true, true) and all your event handlers will apply to the new clone!
When you can’t edit the code of the script that is inserting elements
Maybe you can’t change the code (for example, to add the parameters to the clone method) because it belongs to a script you can’t edit. In this case you will have to figure out another way to bind the event handlers on insertion. The best thing is to inspect what the code looks like and see where you can hook in. Often a custom event is triggered when elements are being inserted. If this is the case, you can piggy back on that custom event.
// the addTable event triggers when a new table is inserted into the DOM
$('#interface').on("addTable", function(){
// now we can add our event handler
$("table").on("click", "a.delete-table", function(){
// do stuff
$(this).closest('table').remove();
}
});
An even better variation of this is when the triggered event passes the element as an argument. That way you can target that element and append your event handlers without the extra legwork.
// demo link here http://codepen.io/PeterKnight/pen/oknre
$("#interface").on("click", ".add-table", function(){
var $el = $('
‘); $el.insertAfter(‘button’) .append(‘New table!DELETE THIS TABLE, DO IT NOW!‘) .trigger(“addTable”, $el); }); $(“#interface”).on(“addTable”, function(e, el){ $(el).on(“click”, “a.delete-table”, function(){ // do stuff e.preventDefault(); $(this).closest(‘table’).remove(); }); });
Execute a function or method that binds the event handler after the element has been inserted
This solution is really simple a straightforward. Basically you write a function or method that appends the event handlers to the desired element and you execute this function or method after the element has been inserted into the page. A very rudimentary example (not copy paste worthy!):
// function or code that inserts element
someFunctionThatInsertsAnElement();
// function that appends event handlers
someFunctionThatAppendsEventHandlers(element);
// above function could look a bit like this
function someFunctionThatAppendsEventHandlers(element){
jQuery(element).on("click", "a.addRow", function(){
// add a row etc.
});
}
A Ninja CSS Trick
There is a very clever and effective way of detecting a newly inserted element with the help of CSS animations. This technique doesn’t require jquery but it only works in browsers that support keyframe, which all modern browsers do…of course IE6-9 aren’t party to that. The neat thing about this method is that it is great in situations where you don’t how your script is going to be used, while you can still reliably and efficiently can set a suitable parent element to use with on().
I have created a blunt demo that demonstrates the technique on codepen, be sure to read the original article linked above though!
While building an add-on for a WordPress plugin, I ran into a little javascript puzzle. I needed to perform an action straight after a table row was removed by a user. At first I tried binding an event handler to the button that deletes the row using the click event. This would normally work just fine, except the plugin was calling a confirmation dialog. When the javascript functions alert or confirm are called, it brings up a dialog box. At this point a user can choose to cancel the action. If you attach an event handler to the click event of the delete button, it will fire, but it won’t know if the user confirmed or not. In other words, this method was not going to work.
As the plugin was using jQuery’s remove() function to remove the table row, it’s possible to watch for the ‘remove’ event. This event handler isn’t widely documented yet at the time of writing. It should trigger when the selected element is removed from the DOM using jQuery’s remove() method. At first I tried to apply the event handler to table row using On() method with the ‘remove’ event. For some reason this wasn’t triggering after deleting a table row. So, the next method I tried was to bind a ‘remove’ event handler using the bind() method whenever the delete button for the row gets pressed. This does work, but you’ll need to use a recent jQuery version with jQuery UI 1.9+, specifically the jQuery UI widgets component.
And here’s an example:
DEMO @ codepen.io
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.