Custom post type and metadata support in the REST API

We’ve recently made some updates to the REST API which is available here on WordPress.com and for any Jetpack-enabled site that have the REST API module activated. The API now has full read and write support for custom post types and post metadata.

You can specify a post’s post type when you create or edit it. If you’re fetching a single post, you will receive it’s post type in the response. Of course, you can also specify a post type when fetching a series of posts. In all cases the parameter to use or look out for is type.

You can also query posts by metadata using the new meta_key and meta_value parameters. You can add, update, delete or retrieve a post’s metadata when creating, editing or getting a single post, using the new metadata parameter which accepts an array of metadata keys, ids, previous_values, values and operations, based on the operation you are trying to perform.

In order to enable your custom post types to work with the REST API on your Jetpack enabled sites, you will need to whitelist them using the new rest_api_allowed_post_types filter available in Jetpack, which is a simple array of the post type names that should be allowed to work with the API.

By default, all metadata keys are allowed in the API, as long as they are not protected keys. Any metadata key that starts with _ is by default protected. Protected metadata keys can, however, be accessed and edited by users with the edit_post_meta (used for editing and viewing), add_post_meta and delete_post_meta capabilities as appropriate for each operation. We’ve also added a filter rest_api_allowed_public_metadata that allows you to specifically whitelist certain metadata keys to be accessed by any user, even if that key is protected.

Here’s a quick rundown. If the user performing the request is unauthenicated, he or she will not be able to add, edit or delete any metadata; will be able to read any metadata for which the key doesn’t begin with _ but will not be able to read any metadata which begins with _ unless it is whitelisted.

If the user performing the request is authenticated and has the above listed capabilities, he or she, will be able to read, add, edit or delete any metadata, even if it begins with _ and is not whitelisted.

In order to make it easier for you to add support for custom post types and metadata in your own plugins and themes, we’ve also added a third filter jetpack_rest_api_compat in the main Jetpack file, which allows you to load additional files where you can then add all of your REST API compatibility code, using the filters above.

Because we love bbPress, we’ve bundled in support for bbPress and the REST API directly into Jetpack, so that you can read, write and edit bbPress forums, topics and replies right out of the box. You can also use this file as an example on how to bundle support in your own plugins or themes.

Check out our documentation, create an app, and get started today!
Let us know if you have any questions in the comments below.

Developer plugin 1.2 released: UI Improvements and New Plugins

Version 1.2 of the Developer plugin is hot off the press!

1.2 includes a host of UI improvements as well as two new plugins, Log Viewer by Markus Fischbacher, and Jetpack by Automattic, plus a new Jetpack constant,  JETPACK_DEV_DEBUG. This release aims to improve the usability of Developer by adding:

• Detailed messages in case of an error while installing or activating a plugin
• Plugin descriptions on installation steps, so it’s more clear what you’re installing actually does
• A link to the plugin details page on installation steps
• A more obvious button to close the post-install modal window

Also included are some behind the scenes improvements to make recommended plugins and constants more flexible down the road as we continue to add to the plugin.

If you’d like to stay up to date with the latest on Developer, please join us on Github where all feedback, plugin suggestions, bug reports, and pull requests are always welcome!

Meet Justin Shreve

Justin Shreve

Meet Justin Shreve: self-taught coder, cat daddy to Harris and Skylar, Google Summer of Code grad, and all around awesome guy.

What motivated you to become a developer? What do you like best about coding?

When I was little I used to sit in on the HTML classes that my parents would teach during the summers. I found it fascinating and wanted to learn more. By the next year I was answering questions that their students raised. From there I taught myself PHP and Javascript and eventually began working with WordPress.

Teaching himself PHP, probably.

I was so enthralled with how the different pieces worked together. That’s what really made me want to become a developer. To figure out how things were built, and how I could take them apart, rebuild them, and improve them.

The thing I like best about coding is there’s always something to do. Coding doesn’t get boring because there’s always a feature to add or a bug to fix.

Describe the killer app you’d build, if your wildest fantasy came true.

It’s a vague idea but I’d love to do some kind of augmented reality (AR) game. Maybe an app for something like Google’s Project Glass. I’ve always been interested in games and game design. I think AR and AR games could really be brought to a whole new level with the stuff that’s being developed. It’d be amazing to be a part of that and build a “killer app/game.”

If you could share just one piece of hard-won advice with young coders, what would it be?

Don’t be afraid to break stuff. It’s how you learn. Just jump in and start coding. There are plenty of resources available to you and plenty of people willing to help you learn.

Also, seriously consider playing with open source projects. I learned a lot more once I started working with WordPress and moved away from proprietary code bases.

Meet Justin Shreve is the second in our developer interview series. We’d like you to meet Beau Lebens, too.

Meet Beau Lebens

Hello there! Welcome to a new feature of the WordPress Developer Resources Blog — interviews! In this inaugural instalment, we’d like to formally introduce you to Mr. Beau Lebens, though he insists you can call him Beau. Beau is famous for many things, including Krav Maga, and instituting burrito Fridays at Automattic headquarters in San Francisco.

How did you get into working with WordPress and how long have you been at it?

Beau Lebens

I kept an eye on WordPress just out of casual interest more than anything else (in the beginning). The first time I really used it for something serious was to make a blog for a company I was working for at the time.

That was in 2005. (I had probably been following WordPress loosely for about a year before that.) When I left that company, I started a startup with a friend which was all based on WordPress (MU, as it was called at the time) and bbPress. It was called MyBabyOurBaby.com and was basically a shared scrapbooking site for families to save memories around a child.

While building that, I worked for about eight months, day and night on nothing but WordPress. I was trying to make it do a lot of things that it wasn’t supposed to, and trying to integrate with bbPress (which was really rough at the time), so it was a pretty huge learning curve. That exposure gave me pretty solid experience with WordPress though, and I was hooked. Once MyBabyOurBaby was built, but not really taking off, I started doing a lot of WP freelance work on the side. I ended up mostly working on performance and larger-scale sites since I had a bit of background in server management in addition to WP. That ended me up at Mashable.com for about six months, helping them get their site stable, building out some custom statistics/reporting systems and a few other plugins.

After that I ended up at Automattic and the rest is history

What’s the most important advice you can impart to a young person who wants to get into coding and development?

Dive right in. It’s just code, so you really can’t break anything too serious. Get a copy of an open source project in your language of choice (oh hai, WordPress.org!) and you can start pulling it apart to see how it works. Never be afraid to try something, even if you think it will probably break everything — that’s what “undo” is for. And backups. And source control.

What’s the most important challenge currently facing WordPress developers?

I think WordPress provides a lot of the components required to build amazing products (themes, plugins, entire web applications), including everything needed to make them secure. This is where the challenge comes in for developers — ensuring what they build is as secure as the core software is. Almost every security vulnerability or exploit that I hear about is via a plugin or theme. It’s up to WP developers to build software that lives up to the platform that it’s running on and to help ensure that we’re all running a safe, secure system. Having a good understanding of a few core concepts around security (especially within WP) can go a LONG way.

Knowing these two documents inside out and applying the ideas to your code will put you ahead of most other WordPress developers:

• WordPress Nonces
• Data Validation

For more on Beau, check out his blog, Dented Reality, and follow him on Twitter.

Platform Updates: Posting Endpoints

We have made a few recent additions to our posting APIs that allow more control when creating posts.

You can now

• Set a custom slug for the post permalink using the slug parameter.
• Disable or enable the publicizing of posts, or only publicize to certain services (Twitter, Facebook, etc) using the publicize parameter.
• Pass a custom message to the above publicize services using the publicize_message parameter.
• Set the status of a post as “pending review” by passing pending to the status parameter.

When getting a post you can now

• Find the featured image for a post using featured_image which will return a URL.

New Color Picker in WordPress 3.5

Some of you may have noticed the shiny new color picker in WordPress 3.5. This was a great example of collaboration between a commercial service and open source: we developed a color picker for WordPress.com to scratch our own itch, then offered it to WordPress.org. They then pushed us to make it so much better than it would have been otherwise. Everybody wins.

Find out more, including how to use it in your next WP project, on make/core: New Color Picker in WP 3.5.

Using the REST API with WordPress.org self-hosted sites via Jetpack

As of Jetpack 1.9, the WordPress.com REST API can now access self-hosted WordPress blogs with the Jetpack plugin installed.

Instead of just building for the WordPress.com platform, you can build awesome applications that interact with WordPress in general. Any applications built using the API for WordPress.com will automatically work with Jetpack-enabled sites running Jetpack 1.9 or higher.

Check out our documentation, create an app, and get started today!

Developer plugin v1.1: Themers are developers too!

We’ve pushed out v1.1 of the Developer plugin, which is packed full of goodies for WordPress theme developers.

You can now indicate that you’re working on a theme for a self-hosted WordPress install to get recommendations on a number of must-have plugins as suggested by the WordPress.com Theme Team.

We also cleaned up a few things, fixed some bugs, added some new plugins (User Switching by John Blackbourn and Pig Latin by Nikolay Bachiyski) and some other useful resources (like the _s starter theme).

(Note: we also pushed out v1.1.1 shortly after to fix an issue with the plugin slug for the Pig Latin plugin. Thanks bobbingwide for the fix.)

As always, if you’d like to check out the code and contribute, join us on Github; pull requests, bug reports, and plugin recommendations are more than welcome.

New P2 Plugin: P2 Hovercards

We’ve released a new plugin for the P2 theme that we’re calling P2 Hovercards. Hovercards are like extra bits of information about particular links that show up when you hover the corresponding inline link or object (for example, check out our Gravatar Hovercards).

With this plugin you can add hovercards to your self-hosted P2 sites. A good example of this is core trac tickets. If you look at the Make WordPress Core blog, you’ll notice that tagged Core Trac tickets are automatically linked up. So, something like #12345 links to http://core.trac.wordpress.org/ticket/12345.

With P2 Hovercards, we took this a step further. I can set it so that #12345 links to the right place, but then also show some additional information when you hover over the link. The following image is an example of what a hovercard could look like for that ticket:

You’ll notice that it gives all the necessary details about the ticket: description, recent comments, and related metadata like owner, status, and so on.

You can extend hovercards, of course, and use them for whatever service you want with a bit of code. Internally, we’re using the plugin to add details to links to support tickets, for example.

The plugin comes with a handy p2_hovercards_add_services() function for adding services:

if (function_exists( 'p2_hovercards_add_service' )
	p2_hovercards_add_service( $service, $pattern, $url, $ticket, $callback );

(Note: We recommend creating a child theme of P2 and adding the additional code to your functions.php file.)

Here’s a quick breakdown of the arguments:

• $service is a string that is the name or slug of the service being added.
• $pattern is a string that is the regex pattern for finding and linking up tags. For our Core Trac ticket example, you would use $pattern = '#(\d+)'
• $url is a string that contains the regex replacement for the anchor tag that gets generated. Again, for the core trac ticket example, you would use $url = '<a href="http://core.trac.wordpress.org/ticket/$1">$0</a>'
• $ticket is a string that contains the regex replacement for a ticket. Following the same example, you would use $ticket = '$1'
• $callback is a callback function for generating the hovercard

The most basic callback looks something like this:

function core_trac_callback( $args ) {
	$id = (int) $args[ 'id' ];
	$url = esc_url( $args[ 'url' ] );
	$service = esc_attr( $args[ 'service' ] );

	// Do stuff with $id, $service, and $url

	return compact( 'title', 'subtitle', 'url', 'description', 'comments', 'meta' );
}

The first four things in the array ($title, $subtitle, $url, and $description) are just strings that will be displayed in the appropriate place on the card. The last two are a little more customizable depending what you want to do though.

Comments are stored in a 2-dimensional array with author, date, and comment fields. Meta is displayed as “Key: Value” in the black bar at the bottom of the hovercard.

More in-depth examples can be found in the examples.php file in the Github repository. As always, we invite you to join us on Github; pull requests and issues are always welcome.

Developer Plugin v1.0: Helping WordPress developers develop

Reblogged from WordPress.com VIP:

One of the great things about developing for WordPress is the number of tools available for developers. WordPress core ships with a bunch of useful features (e.g. WP_DEBUG) with many more built by the community (like our own Rewrite Rules Inspector and VIP Scanner) that make development and debugging a breeze. The hardest part is getting your environment set up just right: knowing what constants to set, what plugins to install, and so on.

Read more… 126 more words