THE PENDING DRAFT

Code Examples by WordPress Theme Review Team

June 18, 2015

The WordPress Theme Review Team released a library of code examples on GitHub. The first section is all about the Customizer and they plan to add more code snippets in the future. If you build themes and want them to meet the guidelines for the official WordPress.org Repository, you should definitely keep an eye on this.

GitHub – Code Examples

Pro Plugin Directory

June 14, 2015

Premium WordPress plugins have a price and are ineligible for the official plugin directory. Pro Plugin Directory is a place to discover premium WordPress plugins. 100% GPL.

A growing directory of Premium WordPress Plugins.

Pro Plugin Directory

Automattic acquires WooThemes

May 20, 2015

Today Automattic announced the acquisition of WooThemes. With a rumored price of $30 million in cash and stock and the integration of 55 employees into their existing teams this is by far the largest acquisition for Automattic as well as in the larger WordPress space. Yet for a company that dominates the e-commerce world like Woo does, with a quarter of all online-stores running on WooCommerce, this still seems like a reasonable price. I’m sure those two teams are a great fit and i’m looking forward to what they can build together.

WooThemes – Official Announcement
Some more words about the acquisition from Matt Mullenweg

Pippin Williamson on Backwards Compatibility

May 8, 2015

Pippin Williamson with a great presentation at LoopConf about Backwards Compatibility and why it’s such an important thing to think about when you develop plugins. He covers many examples of what could happen if you break things and how to avoid those issues.

Backwards compatibility is a cornerstone of WordPress core development philosophy. It is, unfortunately, not something nearly enough plugin or theme developers take seriously. When a plugin or theme project gains 10s or 100s of thousands of users, backwards compatibility can be crucial to the overall health of the project.

Ensuring backwards compatibility is more of a mental mindset than anything. Developers have to mentally make the commitment and say to themselves “I will NOT break installs during upgrades”.

As we are building our own plugin at the moment, Backwards Compatibility is something i think about a lot lately, because as soon as we have it released, some things will be impossible or much harder to change so we better try to get it right the first time.

A Commitment to Backwards Compatibility

Ghost after 2 Years

May 6, 2015

A lot of interesting facts about the first two years (yes, it has really been that long already) of Ghost since they launched on Kickstarter. John O’Nolan goes into great detail about the campaign, the money they raised and how they spent it and the future of Ghost.

April 29th is a very special day for us. It’s the day on which, two years ago, Ghost launched on Kickstarter and went on to raise $300,000. It’s the reason we’re here today!

To celebrate, we’ve got an enormous post in store for you, sharing exactly how we spent the Kickstarter money1, where we’ve gotten to so far, and what’s coming up next for Ghost.

An interesting view behind the scenes of an interesting project.

Ghost 2 Years

Tesla Energy

May 3, 2015

This is the most exciting Keynote i saw in a very long time. If you release something and feel the need to call your product “revolutionary“, “game changing” or any other superlatives (yes, Apple, i’m looking at you!), please go stand in the corner watch this keynote again and think about what you just said.

I just read that a professor at the ETH in Zurich calculated that for the first time in history, solar energy will be cheaper than electricity from the grid, thanks to those Tesla batteries.

Optimizing a Custom Query in WordPress

April 14, 2015

With the WP_Query class WordPress provides a powerful tool to query things from the database. But as with most powerful things, you can also mess things up quite a bit if you’re not careful enough.

With great power comes great responsibility.

(Voltair, Yoda, Uncle Ben in Spiderman or whoever said it first)

Let me give you an example of a query we needed in a project and how we implemented it.

The Goal

We want to get the IDs of all Attachments (images in this case), that are attached to any post of a particular Custom Post Type.

The Wrong Way

The good thing about WordPress is that you can find a snippet for pretty much anything with a simple Google Search. The bad thing about WordPress is that you can find a snippet for pretty much anything with a simple Google Search. Often it’s as easy as throwing a snippet into your plugin or functions.php in your theme and it just magically works.

Here’s the first “solution” i found somewhere on StackOverflow:

// Query for all posts of post_type 'post-type-name'
$cpt_query = new WP_Query(
  array(
    'post_type' => 'post-type-name',
    'posts_per_page' => -1 // get everything
  )
);

// Create an empty array for our attachment ids
$attachment_ids = array();

// Run a Loop through our CPT-Query
if( $cpt_query->have_posts() ){
  while( $cpt_query->have_posts() ){
    $cpt_query->the_post();

    // Inside the Loop, get all attachments which are children of this post
    $attachments = get_children(
      array(
        'post_parent' => get_the_ID(),
        'post_type' => 'attachment'
      )
    );

    // Add the attachment id to our array
    foreach ( $attachments as $attachment ) {
      $attachment_id = strval( $attachment->ID );
      array_push( $attachment_ids, $attachment_id );
    }
  }
  wp_reset_postdata();
}

 

While this worked perfectly as it should, it had a pretty expensive overhead. Right now we query for all posts of that Post Type, then load all information about that post, loop through every single one of them and inside that Loop we query again for all attachments, load all data and again loop through every single one of them to get the ids.

We add a lot of queries post per post while looping through them, not good! This might not be a problem when you only have some posts with a handful of attachments. But because of the way this query was built the queries would increment for every post which would easily lead to thousands of queries when more posts and attachments are added.

So, what can we do to fix this? Let’s see.

First of all, it’s important to realize that you have a problem, preferably before anyone else does. I use the Query Monitor Plugin during development to display the amount of queries (among other useful information) in the admin bar. On top of that, it’s a good idea to test your plugin/theme not only on a blank installation but also to create, delete, add, move as much as you can to check if there are issues you won’t notice otherwise.

‘fields’ => ‘ids’ to the rescue

Inside WP_Query we can define which fields we want to retrieve by adding 'fields' => '...' to the query. That way we won’t load every single piece of information about the posts we find, but only what we need: the IDs.

$cpt_query = new WP_Query(
  array(
    'post_type' => 'post-type-name',
    'posts_per_page' => -1,
    'fields' => 'ids'
  )
);

 

This will get us an array of IDs. We don’t have to loop through them anymore and can directly make a second query to get our attachments.

$attachment_query = new WP_Query(
  array(
    'post_type' => 'attachment',
    'posts_per_page' => -1,
    'post_status' => 'any', // Not sure if this is needed, but it makes sure we really get every attachment
    'post_parent__in' => $cpt_query->posts, // Look for children of the ids from our first query
    'fields' => 'ids' // Again, we only want to get the ids
  )
);

 

This second query gets all attachments that are children of (attached to) one of the posts we got in the first query. The result of $attachment_query->posts will again be an array of IDs, this time for the attachments.

This means instead of potentially thousands we will only ever have two queries, regardless of the amount of posts and attachments.

The Solution

To sum up here’s the complete code we use today in our plugin (we added some more parameters and checks, but it’s technically identical).

function pdr_get_attachments_from_cpt( $query ) {
  $cpt_query = new WP_Query(
    array(
      'post_type' => 'post-type-name',
      'posts_per_page' => -1,
      'fields' => 'ids'
    )
  );

  $attachment_query = new WP_Query(
    array(
      'post_type' => 'attachment',
      'posts_per_page' => -1,
      'post_status' => 'any', // Not sure if this is needed, but it makes sure we really get every attachment
      'post_parent__in' => $cpt_query->posts, // Get children of the ids from our first query
      'fields' => 'ids' // Again, we only want to get the ids
    )
  );
}

 

In our case we hooked that function to the pre_get_posts filter to exclude those attachments from all queries, I left that part out for the sake of simplicity. Let me know if you want to see the complete code.

This is exactly the kind of thing I meant when I wrote about taking things apart as a regular learning habit. It didn’t took a whole lot of time to figure out what was going wrong with the original function, I fixed a piece of code which would have gotten us into trouble later on and I learned a few things about how queries in WordPress work.

What did you learn today?

Git Structure for WordPress Projects

April 9, 2015

A great post about whats the best git structure for WordPress projects. I completely agree with Peter Suhm on this one.

I have ranted about the subject of repository structure before and I have strong opinions about it. In my opinion there is one – and only one – way to structure Git repositories in a WordPress context. That one way is the one-package / one-repository approach. Let me explain why.

Putting the complete WP core into your repo is something i see a lot, but it always feels wrong and bloated to me. One plugin/theme = one repo is the way to go.

Plus i learned about .gitattributes in his post which seems to be a good way to specify which files should get bundled in the final .zip when your project gets downloaded.

Git and WordPress: 3 Tips to Do It Better

A comprehensive Guide to WordPress Core Contributing

March 20, 2015

It’s great to see more and more companies giving back a portion of their time to contribute code back to the WordPress Core. If you’re just starting out and want to dedicate some of your time, it can be confusing at first to find the right things to work on. Delicious Brains (the makers of the awesome WP Migrate DB Pro Plugins) are dedicating one day each month to core contributing and they just wrote this really comprehensive Developers Guide to Contributing to WordPress Core. Read this if you want to contribute and don’t know how to start.

A Developer’s Guide to Contributing to WordPress Core

Automatic Updates for WordPress Plugins and Themes

March 16, 2015

Last week, a security vulnerability in Yoast’s WordPress SEO Plugin was discovered and fixed. It was responsibly disclosed and a bugfix was released promptly.

So far so good. But i – as well as many others – was surprised (to say the least), when i found out that the plugin was already updated without me or my clients doing anything.

It turns out that the WordPress.org Security Team decided that this vulnerability was severe enough to justify an automatic rollout for all sites which have the plugin installed.

By default, automatic background updates only happen for plugins and themes in special cases, as determined by the WordPress.org API response, which is controlled by the WordPress security team for patching critical vulnerabilities.

In principle i appreciate the possibility to push out important security related updates to all WordPress Installs around the world and i’m aware that we already do something similar with minor core updates, but the way this happens needs some refinement.

Notifications

It needs to be clear when something has been updated automatically. Period. Admins need to get an email (like they do for automatic core updates) and maybe there should also be a notification in the admin area / dashboard on next login.

Documentation

The whole process of automatic Updates for Core and Plugins needs proper documentation in the Codex so everyone is on the same page what happens, when it happens and why it happens, when it happens. This alone would have calmed down the whole confusion a lot last week. I know there are people working on this and the according Codex has already been updated since last week, which made it a lot more clear. The quoted description on top of this post was added after last weeks Update.

An Option to disable automatic updates?

It should be easily possible to disable automatic updates altogether and it should be crystal clear which auto-updates (core/plugins/themes) are affected. I’m ok with this being opt-out, but it needs to be possible in an easy way. Right now you could disable auto-updates by setting a filter like this:

add_filter( 'auto_update_plugin', '__return_false' );

Maybe even a UI-Option to opt-out should be considered.

(This, as said above, has also been updated in the Codex to better explain how to disable certain updates)

Idea: Opt-In Auto-Updates, but different / better Notifications for Admins

I think automatic plugin updates should be a last resort. First of all, i just don’t like the idea of messing around with someone else’s site without their consent. What if something goes wrong with their site during the update? What if they edited some lines in said plugin and the update overwrites their changes? What if a site doesn’t have any kind of backup in place? I know, i know, that’s all awful bad stuff and no one would ever do such terrible things. And yet those things happen! They happen all the time, whether we like it or not.

So, why don’t we implement a better way for admins to distinguish severe plugin updates from normal updates. The only thing it would need would be some kind of a “severe” flag which states that this update is really, really important and then we could add a prominent notification to the Dashboard. Of course, this should also send an email to admins to notify them that they should login and update this particular plugin.

Maybe a combination of this and Auto-Updates could also be done: A notification sent out to admins to let them know that in 48 hours plugin X will be updated automatically if no action is taken and an explanation why this update is important and so on.

This way the admin still has full control of his site, as he should, and would still get notified to take some action if needed.

Another Idea: Auto-Disabling?

Basically the same idea as the last, but instead of updating, the plugin would get disabled, instead of updated, after a certain period of time (e.g. 48h) when no action is taken.

I’m not yet sure what the best solution will be. But what i’m sure is we will have to find a better way than messing around with anyone’s site without letting them know.

Nick Haskins – On Automatic WordPress Updates