A brand new Developer Site

As you may have noticed, we’ve just relaunched the WordPress.com Developer site (the very one you’re reading right now!) with a brand new look and feel!

We’ve rebranded the site to match the overall WordPress.com aesthetic as well as to align with the new user management and insights sections we launched just a few weeks ago.

E5A0rwxNNg-3000x3000

The goal of the redesign was not only to modernize the site but make it easier for you, our partners and third-party developers to find the information you are looking for. In addition, we’ve reviewed all of our existing documentation and past blog posts to make sure the information is accurate and relevant.

Over the next few months, you’ll see more updates to the site and more frequent blog posts from our team.

I’d personally like to thank the team that worked on the relaunch with me: Raanan, Kelly, Kat, Justin, and Stephane.

If you’d like to let us know what you think of the new site, report a bug, or have suggestions for future improvements, please comment below, tweet at us @AutomatticEng or contact us privately.

Introducing WordPress.com Insights

We love stats at Automattic. They’re key to understanding our users, and a driving force behind a lot of what we do.

When we make a change, we measure its impact and use the metrics to make data-informed decisions. For example, we recently improved how our Publicized posts look on other services. Using our own data as well as data provided by our partners, we made further improvements and tweaks to increase click throughs to your posts.

Our partners and those building on our platform should have the same ability. That’s why we spent the past few weeks creating tool to support them: WordPress.com Insights.

Check it out in the short video below:

Music Credit: Anthony Vitale

Insights provides data and graphs for a variety of metrics: Connections/authorizations, API calls, API errors, posts published, WordPress.com Connect Logins, and the reach of posts published from your app. By exposing this data, developers can measure the impact of their integrations over time.

In addition to graphs, we’ve also built in export functionality allowing you to get your data in CSV format. Since Insights is built using the REST API, you can pull data out in JSON format as well.

To accompany Insights, we also added the ability to allow other users and developers access to your app. To edit your permissions, head to the Apps Manager, select an application, and click “manage users.” If you want to provide temporary access you can also generate sharable URLs.

For more information and a walkthrough of Insights, check out our documentation.

An efficient alternative to paging with SQL OFFSETs

Challenge

Running WordPress.com means having multimillion-record database tables. Tables which we often need to batch-query.

Provided we could hardly select (or update, etc) millions of records at once and expect speed, we commonly have to “page” our scripts to only handle a limited number of records at once, then move on to the next batch.

Classic, but inefficient, solution

The usual way of paging result sets in most SQL RDMS is to use the OFFSET option (or LIMIT [offset], [limit], which is the same).

SELECT * FROM my_table OFFSET 8000000 LIMIT 100;

But on a performance level, this means you’re asking your DB engine to figure out where to start from all on its own, every time. Which then means it must be aware of every record before the queried offset, because they could be different between queries (deletes, etc). So the higher your offset number, the longer the overall query will take.

Alternative solution

Instead, of keeping track of an offset in your query script, consider keeping track of the last record’s primary key in the previous result set instead. Say, its ID. At the next loop instance, query your table based on other records having a greater value for said ID.

SELECT * FROM my_table WHERE id > 7999999 LIMIT 100;

This will let you page in the same way, but your DB’s engine will know exactly where to start, based on an efficient indexed key, and won’t have to consider any of the records prior to your range. Which will all translate to speedy queries.

Here’s a real-life sample of how much difference this can make:

mysql> SELECT * FROM feeds LIMIT 8000000, 10;
  [...]
10 rows in set (12.80 sec)

mysql> SELECT * FROM feeds WHERE feed_id > 12958559 LIMIT 10;
  [...]
10 rows in set (0.01 sec)

I received the very same records back, but the first query took 12.80 seconds, while the alternative took 0.01 instead. :)

PHP/WordPress example

<?php
// Start with 0
$last_id = 0;

do {
    $blogs = $wpdb->get_results( $wpdb->prepare(
        'SELECT * FROM wp_blogs WHERE blog_id > %d LIMIT 100;',
        $last_id // Use the last ID to start after
    ) );

    foreach ( $blogs as $blog ) {
        // Do your thing!
        // ...
        // Record the last ID for the next loop
        $last_id = $blog->blog_id;
    }
// Do it until we have no more records
} while ( ! empty( $blogs ) );
?>

Like elasticsearch? We do too!

Elasticsearch tools

Elasticsearch, if you’re not familiar with it, is defined as a distributed restful search and analytics tool.

When it comes to implementing such an infrastructure, our developers not only face the challenges involved in indexing tens of millions of sites with grace and skill, they also write quite extensively about their related adventures, so others can benefit from their experiences.

You can find a plethora of posts on Greg Brown’s blog, under the appropriate tag. Subjects ranging from performance and scaling, all the way to “Elasticsearch, Open Source, and the Future“. And in true Automattician fashion, he isn’t even shy about recognizing his mistakes.

But Greg is not alone! Xiao Yu also recently wrote about the tools he uses, and a plugin he concocted for his own needs:

I’ve taken all that I wished I could do with both of those plugins and created a new Elasticsearch plugin that I call Whatson. This plugin utilizes the power of D3.js to visualize the nodes, indices, and shards within a cluster. It also allows the drilling down to segment data per index or shard. With the focus on visualizing large clusters and highlighting potential problems within. I hope this plugin helps others find and diagnose issues so give it a try.

How’s that for advanced? :)

Embed WordPress.com or Jetpack blogs on other websites with timelines

Today we are making it easier for you to bring your other websites closer to your WordPress.com or Jetpack blogs.

The new embedded timeline tool allows you to put a timeline of your blog posts on your website, connecting your visitors with the content you are writing here.

It only takes two pieces of HTML to embed a view of your blog directly on your website. The embed is interactive and allows your readers to follow your blog or like your posts without leaving the page. Both WordPress.com and Jetpack blogs are supported.

Our embedded timelines documentation contains directions on how to implement the timeline on your own site.

We also have a tool that allows you to create timelines without any coding at our creation page.

PS: The timelines are built using the REST API – take a look and start building your own app today!

You can also use a shortcode to Embed the timeline on a WordPress.com blog:
[wptimeline url="http://developer.wordpress.com" showgravatars="true"]

Here is an example of a timeline in action:

Recent Posts on http://developer.wordpress.com

Platform Updates: Batching Calls, Privacy Settings, and IDs

We’ve made a few more updates to our APIs recently that we wanted to share with you.

The biggest update is a new query parameter that’s now available on all endpoints. The new parameter allows you to batch certain calls together, so you only need to make one request to get related data instead of two or three.

Since we released our APIs, we’d always return a list of related endpoints in the “meta” response with a series of links:

"meta": {
        "links": {
            "self": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907\/posts\/21238",
            "help": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907\/posts\/21238\/help",
            "site": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907",
            "replies": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907\/posts\/21238\/replies\/",
            "likes": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907\/posts\/21238\/likes\/"
},

Now, by passing ?meta=site, you can automatically get the data from the above endpoints in the original response. Let’s take a look at an example.

Say you’re loading a specific post but you want to know the name and description of the site the post was on. You can do this by making a call to: https://public-api.wordpress.com/rest/v1/sites/en.blog.wordpress.com/posts/21238/?meta=site.

Which will give you a response like the following:

"meta": {
        "links": {
            "self": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907\/posts\/21238",
            "help": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907\/posts\/21238\/help",
            "site": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907",
            "replies": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907\/posts\/21238\/replies\/",
            "likes": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907\/posts\/21238\/likes\/"
        },
        "data": {
            "site": {
                "ID": 3584907,
                "name": "WordPress.com News",
                "description": "The latest news on WordPress.com and the WordPress community.",
                "URL": "http:\/\/en.blog.wordpress.com",
                "jetpack": false,
                "subscribers_count": 8396934,
                "meta": {
                    "links": {
                        "self": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907",
                        "help": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907\/help",
                        "posts": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907\/posts\/",
                        "comments": "https:\/\/public-api.wordpress.com\/rest\/v1\/sites\/3584907\/comments\/"
                    }
                },
                "is_private": false
            }
}

You can also pass multiple values in the meta query string. If you wanted the site endpoint and a list of likes for a post you can just pass "site,likes".

Two other updates we made are new responses:

  • We now include the value of privacy setting in the site information endpoint. A boolean value will be included as is_private.
  • We now include a global_ID response for all posts. This is a unique ID that you can use to identify posts if you are loading posts from multiple blogs in your application.

We hope you enjoy these updates. We’ll be making more improvements soon!

Developer Plugin 1.2.2 Released: New WP-CLI Command

Version 1.2.2 of the Developer plugin was recently released. The big feature of this release is a new WP-CLI command. If you’re not familiar with WP-CLI, it is “a set of command-line tools for managing WordPress installations.” These command-line tools let you do anything from download and install WordPress to manage options for your site. The command we’ve introduced will let you install and, optionally, activate the recommended plugins.

For example, the following will install and activate the Developer plugin and all the recommended plugins for WordPress.com VIP.

wp plugin install developer --activate
wp developer install-plugins --type=wpcom-vip --activate

As always, pull requests are welcome on Github. If you want to introduce a new WP-CLI subcommand or just stay up to date with the latest on the Developer plugin, join us there.