Pipping Williamson with some tips on how you can improve the chances of getting your plugin approved in the WordPress Plugin Directory.
Quotes on Design fetches Quotes using the WP-API
May 13, 2015Quotes on Design is a page that serves quotes about design, curated by Chris Coyier. They just rebuilt it using the WP-API to fetch posts from WordPress.
Up to this point, Quotes on Design (QoD) used a bit of custom code to query the WordPress database and serve up quotes. This was used for the site itself, and for its API to allow use on external sites. With the excitement surrounding the upcoming WordPress JSON REST API, we thought it would be fun to rebuild the site to use the WP API instead of our own custom code.
It’s nice to see more and more real world examples using the WP-API popping up lately. In this post on CSS-Tricks, Andy Adams details exactly how they built it which makes it a perfect tutorial if you want to get familiar with the WP-API.
OptinMonster – from WP Plugin to SaaS
May 12, 2015Last week, OptinMonster quietly announced their new stand-alone SaaS tool. In a post on his personal blog, Syed Balkhi shares some more of the reasoning behind that step as well as a little bit about the technical side of things.
Many of you may know OptinMonster as a powerful WordPress lead generation plugin that we created. Well, it’s no longer just a WordPress plugin.
OptinMonster is now a stand-alone (SaaS) lead generation tool that can be used on any website platform. Yup that means WordPress, Drupal, Joomla, Shopify, Magento, BigCommerce, and basically any HTML website.
He also promised to share some more technical details very soon.
A curated collection of tips and tricks for Chrome Developer Tools.
Pippin Williamson on Backwards Compatibility
May 8, 2015Pippin 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.
Ghost after 2 Years
May 6, 2015A 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.
Rewriting URLs in WordPress
May 5, 2015The Rewrite Engine of WordPress is one of the parts of WordPress that can be confusing at first and that i personally never liked to customize at the beginning. Basically just because it normally worked the way it should and i didn’t want to break anything by adding custom rules. But custom rewrite rules can be a very powerful thing, especially if you’re building custom solutions for clients or a web app on top of WordPress. This post covers the basics and various code examples of how to implement your custom rewrite logic in WordPress.
Web Design Stack
April 28, 2015A nice collection of resources and Cheat Sheets on many different aspects of web design. I already found something interesting in there: Sauce Labs, which could be a cheaper alternative to my (fairly underused) BrowserStack Account.
Yoda Conditions
April 25, 2015Have you ever heard of Yoda Conditions? Maybe you saw some code written like this:
if( true ==$the_force) {$victorious= you_will($be);}
I never really got why it could be useful to write a condition in that order until i found this part of the WordPress’s PHP Coding Standards:
In the above example, if you omit an equals sign (admit it, it happens even to the most seasoned of us), you’ll get a parse error, because you can’t assign to a constant like
true. If the statement were the other way around( $the_force = true ), the assignment would be perfectly valid, returning1, causing the if statement to evaluate totrue, and you could be chasing that bug for a while.
Now that makes a whole lot of sense, so make sure to write your conditions in that order from now on, even if it sounds strange at first. Or, as it is appropriately stated in the Coding Standards:
A little bizarre, it is, to read. Get used to it, you will.
Optimizing a Custom Query in WordPress
April 14, 2015With 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?