A European WordCamp

Last night I got home at 3:00 from the first ever multi-nation WordCamp, WordCamp Europe 2013 in Leiden, The Netherlands. The weekend was packed with many inspiring talks, but above all it was a unique chance to meet other developers and designers from around Europe and the world. Based on discussions I had during the past two days, advanced use cases of WordPress as an app platform are becoming more and more common. I also had the opportunity to talk to many WordPress “superstars” like Andrew Nacin, Nikolay Bachyisky and The Matt.

Putting together a conference of over 700 people can not be an easy task, but everything went pretty much without a hiccup (there were occasional wifi problems but that’s almost to be expected). A big thanks to the international team of organisers!

Sublpress: Manage WordPress Sites in Your Text Editor

Sublpress is a new extension for Sublime Text by Nic Dienstbier that makes it possible to manage your WordPress site (or multiple sites) in the editor. Currently you can edit settings, create and edit posts and manage taxonomy terms. All features can be easily accessed via the Command Palette.

Creating a new post with Sublpress
Creating a new post with Sublpress

I tested Sublpress in both Sublime Text 2 and beta of Sublime Text 3, and my initial impressions are it seems to be a bit more stable (ironically) in the latter. This could be just something relating to my setup however.

Sublpress options
Sublpress options

I’m still not entirely sure whether I want to manage my WordPress sites in my text editor, but if it sounds like fun to you, go get Sublpress on GitHub. 🙂

My Dev Setup, part 4: Version Control and Deployments with WordPress

In an earlier post, I promised to shed some light on our git workflow for WordPress projects. The above image sums it up pretty nicely, but read on for the details.

Most of the development we do happens in a local Apache + PHP + MySQL environment, using MAMP Pro. That means I have a local copy of each site I’m developing, which creates some overhead compared to everyone just working on a central dev server. It’s worth it though because it makes working on different features and code branches easy.

Repository structure

Every project has its own git repository, which we set to the WordPress root directory. This is because most of our projects involve a combination of custom themes and plugins, and it makes sense to group them in a single repository. We still don’t want any of the core WordPress code in git, so we use a .gitignore file based on this excellent template by Joe Bartlett:

https://gist.github.com/jdbartlett/444295

The above means that in practice the contents of a typical project repository structure looks somewhat like this:


/
+-- wp-content/
    |-- plugins/
    |   +-- custom-plugin/
    |
    +-- theme/
        +-- custom-theme/

Sharing code and automated staging with Beanstalk

When I want to share code with my colleagues or am ready to something to a client, I do a git push to a central repository hosted on Beanstalk. Beanstalk has loads of useful features, but the best thing about it has to be the simple deployments it offers. For all projects, we set up automated deployments to a staging server, where we have copies of each site. Deployments to production are also set up in Beanstalk, but (intentionally) require a manual click in the web app.

Going to production

Finally, moving from staging to production can require some tricky search-and-replacing domains and absolute paths in the database. WordPress in Network mode tends to be particularly keen on saving the site URL in way too many places. One way to do this is to perform a search and replace on a SQL dump, but we use this nifty tool by Interconnect/IT, because it correctly handles serialised strings, which are often used in WordPress for things like widget options etc. The same tool is useful when doing the reverse, ie. creating a local copy of an existing site.

Relevant links:

Simple Conditional Loading in WordPress

Over a year ago, Jeremy Keith wrote an excellent post on enhancing the performance of responsive sites by checking for a minimum screen width before loading secondary content such as related news and latest tweets. Mobile devices would just show a link to the content, thus keeping it accessible. In this post I’ll show how to do a similar thing in WordPress.

Method 1: Custom page templates

I thought there should be an easy way to delay the loading of any secondary content, and my first thought was to use the very simple .load() method in jQuery along with a custom page. For instance you could create a special template to show related blog posts, and display a link to that page. On wide screens this link can be replaced with the content of your custom page using ajax. This is a perfectly valid way of doing it, especially if you have only one or two pieces of secondary content.

Method 2: Custom Endpoints

What if I want to conditionally load the WordPress sidebar on every page, and the contents of the sidebar is not necessarily the same everywhere? Creating page templates and pages for all that secondary content can become messy and error-prone. My esteemed colleague (and boss) Aki suggested a better way of doing this would be to check for a specific parameter in PHP and generate either the main content or the sidebar. All we need is the sidebar version of the page to have its own URL. Enter Sandman WordPress Endpoints!

URL endpoints are part of the Rewrite API, and are used for many things, among others to generate feeds (via /feed/) and paging (eg. /page/2/ to see older posts or the second part of split post). The following code will register a new endpoint /part/.

https://gist.github.com/5225955

The above code should go in the theme functions.php file, or better yet, a separate plugin. To make the endpoint actually work you might have to clear your rewrite rules — simply opening the WordPress Permalinks settings and saving should do the trick.

Now the endpoint is registered, you can access it in PHP using the built-in WordPress function get_query_var(). For example, you could construct your sidebar.php template like this:

https://gist.github.com/5225892

In the above example, when we access a URL ending /part/sidebar/, the condition will evaluate to true. So now we have an accessible, functional solution with cacheable URL’s. We’ll just add some jQuery magic to load the sidebar content in place on wider screens:

https://gist.github.com/5225932

If you also want to support ajax loading on smartphones, add this to trigger it with a tap/click:

https://gist.github.com/5225940

That’s all! A functioning demo can be seen on this blog: try loading it on a small screen vs. a wide screen.

WordPress Multisite Tip: Finding and Removing Inactive Plugins

A few of our clients have WordPress Multisite installations with quite a number of plugins. For security reasons alone, it’s never a good idea to keep unnecessary plugins on the server, even if they’re not in use. With constant changes and development going on, it’s easy to lose track of them.

Going through each site manually and checking which plugins are active can be a pain, but luckily I discovered an excellent plugin called Network Plugin Auditor, available for free on the WordPress Plugin Repository. The plugin does two things: in the Plugins list of the Network Admin, it adds an extra column, showing all the sites any specific plugin is active on. It’s then trivial to remove plugins where that last column is empty. ALso, on the Sites page the plugin will show which plugins are in use on each site.

Highly recommended for Network Admins using WordPress Multisite!