Press This Revamp Merge Proposal

What is it?

Press This is a redesign of an existing feature with a focus on automation, speed, and mobile usability.

Download the plugin and check it out for yourself!


One of the requirements of core is at least feature parity with the old version of Press This. Here’s a comparison chart of where the new Press This is.

Feature Old New
Drag & drop install on desktop Yes Yes
Editor, including: title, image/gallery addition Yes Yes
TinyMCE buttons (minus kitchen sink) Yes Mostly [1]
Ability to publish or save as draft Yes Yes
Post formats Yes Yes
Categories Yes IYes
Tags Yes Yes
Content Scraping Yes Improved [2]
Media Discovery Yes Improved [3]
Alert before closing/navigating away Yes Yes
Can add to bookmarks Yes Yes
Responsive, clean design, updated icons No Yes
Fast loading (speedy!) No Yes
Mobile installation No Yes

[1] A number of TinyMCE buttons are removed intentionally. Only necessary WYSIWYG buttons are shown now.
[2] Not only is it included, but it’s quite a bit smarter than the previous one.
[3] Now is actually quite exposed in the UI.

More generally

  • Trimmed down UI for extra-speedy reposting of your favorite left shark gif
  • Core architecture of the plugin/tools is an as-pure-JavaScript-app as possible
  • Currently AJAX-driven, but ready to be switched to using the WP-API endpoints as they become available in the future
  • Backward compatible with the current version of the Press This bookmarklet as bundled in WP, but also bring its own, more powerful one with it
  • Can blog content from any web page found online
    • highlighted text gets pulled in as a blockquote
      • if nothing is highlighted, it makes a good guess as to what should be quoted
    • in-page images get pulled in to choose from
      • Said images are augmented with meta data to sort them in the order the site advertises to be best
    • audio, video, and and twitter embeds are also listed in the suggested media to insert at your whim
  • Saving draft sends you into the full editor (and saves) so you can do your fancier WYSIWYG-y things
  • Publishing is awesome and quick
  • Image side-loading
  • Ultimate (the best ever probably) WYSIWYG toolbar that’s trimmed down to just B, I, Blockquote, Link/unlink, undo, redo (and lists on wider screens)
  • 2 modes
    • Direct access: Like quick post, but awesome and totally usable on a fancy phone
    • Bookmarklet
      • Similar to the older Press This in use. Save as bookmarklet > Press a site for quick reposting of things
      • If no content detected (new tab), you can use it like a quick post application

So which problems are we solving?

  • Outdated UI –> Updated
  • No responsive styles –> ultra responsive
  • Decent automation –> better automation (suggested media, blockquote, etc)
  • Pretty dang near impossible to add as a bookmark and use on a tablet/phone –> Added our own tool page (temporary) to add improved markup (still could use a bit of finessing)
  • Suggested media was hard to find –> Now is hard to miss
  • A bit rough and slow to use and compose with –> Pretty dang streamlined

What brought us to this solution and what other potential solutions did we explore?

When we were initially exploring designs and ideas, a few people suggested just improving Post New. The main reason we opted not to was speed. Post New comes with all of wp-admin and its files. It’s a bit of a beast. We wanted an extremely light, extremely fast (both in performance and in usability) way to post and keeping Press This was a good way to go. We can also pull the ideas and techniques we like back into Post New if successful and useful.

We experimented with SVG icons (one less http request, but ultimately removed as Dashicons are required for the editor). We planned to use the upcoming API. We have trimmed down stylesheets and JS (only the styles necessary for a PT view). There is no extra UI that could get in the way of going from 0 to published post. Press This also has the luxury of being able to fall back to the full editor (via Save Draft) for those that have plugins and other features the need to set before posting.

Usability testing (not user testing y’all)

We did a couple rounds of usability tests. One for a11y and another with some new users.

Both had tremendous difficulty in even adding the bookmarklet. @marcelomazza did a pretty solid job fixing up the add bookmarklet screen.

We ran into a number of a11y issues and addressed as many as we could. Could still use another round of a11y testing.

Once the new users figured out how to install it, they didn’t have many issues creating a post. I’d like to do more with ultra Space Jam pro users like yourselves.

 Mega thanks to everyone involved so far:

@stephdau @azaozz @marcelomazza @ryan @kraftbj @afercia @iseulde @melchoyce @folletto @georgestephanis @helen @drewapicture @danielbachhuber @dd32 (for epic Github > SVN sync)

And thanks to all the testers so far!

#4-2, #feature-plugins, #merge, #press-this, #proposal

Press This update 2/10

The merge window is supposed to open tomorrow for feature plugins. That means it’s crunch time. Here’s where the new Press This is.

Feature Parity

one of the requirements of core is general feature parity with the old version of Press This. Here’s a comparison chart of where the new Press This is.

Feature Old New
Drag & drop install on desktop Yes Yes
Editor, including: title, image/gallery addition Yes Yes
TinyMCE buttons (minus kitchen sink) Yes Mostly [1]
Ability to publish or save as draft Yes Yes
Post formats Yes Yes
Categories Yes In Progress
Tags Yes In Progress
Content Scraping Yes Improved [2]
Media Discovery Yes Improved [3]
Alert before closing/navigating away Yes Todo
Can add to bookmarks Yes Yes
Responsive, clean design, updated icons No Yes
Fast loading (speedy!) No Yes
Mobile installation No Yes

[1] A number of TinyMCE buttons are removed intentionally. Only necessary WYSIWYG buttons are shown now.
[2] Not only is it included, but it’s quite a bit smarter than the previous one.
[3] Now is actually quite exposed in the UI.

Before Core Merge

Prior to merge, there’s a bunch that still needs to be done. With that in mind, @DrewAPicture has given us an extra week to accomplish this. Even still, we have a list of things that need to be done prior to devchat tomorrow, with the rest of the list done in a week.

Before Tomorrow’s Devchat (February 11)

Before Next Wednesday’s Devchat (February 18)

  • Categories functional and live
  • Install flow functional and live
  • Side navigation JS improvements (functional)
  • Flows posted to make/flow comparing the old and new design (@ryan)
  • Another round of accessibility testing (when UI is finished)
  • All accessibility concerns addressed
  • Categories functional and live
  • JS inline docs
  • HTML validation
  • Security audit
  • Usability testing reviewed and any issues addressed
  • Verify localization (including rtl) is functional
  • Browser testing on all browsers (support parity with old Press This plus mobile)
  • Unit tests?

If we’re able to accomplish all of the above, we should be ready for merge on February 18.

Daily Chats

In this final rundown, let’s meet daily in #feature-pressthis at 17:00 UTC to make sure we’re on track for merge. Anyone interested in helping, please join us.

All development is done on Github:

Plugin on the plugin repo:


Dev Chat Summary, February 4th


Chat Archive

Decisions, Announcements

  • @drew will lead a NUX working group during the 4.2 cycle. The first chat will be held in #core-flow next Tuesday at 19:00UTC / 2:00 pm EST.
  • @ryan (hey, that’s me) will attempt to be UX lead for 2015. 🙂


Links Mentioned

Screen Shot

Continue reading


New chapters for Ryan and Westi

WordPress lead developers Ryan Boren (@ryan) and Peter Westwood (@westi) started contributing to WordPress more than a decade ago. Ryan and Peter, along with Mark and Matt, served as the foundation for much of the early years.

For some time now, Ryan and Peter have avoided weighing in on technical matters. Very simply, when you aren’t able to be active in development, you know you’re not up to speed, and you realize your words shouldn’t carry the weight that they do. Being able to make this judgment is one of the things that makes both of them such great leaders.

We’ve all been there, at least for particular features or releases. It’s worth noting, for example, that my own time on core has been cyclical for years, as sometimes I end up working full time on the security team, maintenance releases, the site, or related projects.

The great thing is, there are a lot of fantastic developers who have stepped up over the last few years to seamlessly fill in the huge holes they’ve left. Some of that culminated in promoting Helen and Dion to lead developer yesterday, and my own promotion three years ago.

When I started contributing, I received a lot of advice and learned a lot from both of them. Peter reviewed a lot of my code and was the guy who would revert my code when I broke something. 🙂 Ryan became my mentor and pushed me to become the engineer I am today.

And so, it is with mixed emotion I share that Ryan and Peter have stepped down as lead developers.

Peter will be moving into a dormant/inactive/emeritus status. We hope to have him back when his life and work allows. In the meantime, you may see him committing a bug fix here and there, as he is wont to do.

Ryan has been focusing all of his energy on improving UX for more than a year, especially for mobile and touch devices, and especially for workflows like media management. So I’m pleased to say he’ll continue to do that: Ryan will be spearheading UX for WordPress in 2015. It’s been a while since we’ve had someone truly focusing on just UX, so this is really exciting.

Along with yesterday’s announcement, the active lead developers are @markjaquith, me, @azaozz, @helen, and @dd32.

Please join me in congratulating Ryan and Peter on an epic run. 🙂

Dev Chat Summary, January 28th



  • Jumpstart posts will be posted every Monday.
  • Weekly bug scrubs will occur on Fridays at 16:00 UTC in #core.
  • Each feature plugin will have a core mentor.


  • @drew will post a Jumpstart to make/core on Monday.
  • @mark will be the core mentor for Customizer Theme Switcher.
  • @azaozz will be the core mentor for Press This.
  • @boone will relay term splitting doc plans to the docs team this week.
  • @pento will post a Shiny Updates update post to make/core by the weekend.
  • @ryan will post to make/core about contributing to mobile flow improvements.

Links Mentioned

Continue reading

#4-2, #meeting

Open Update Thread

What’s going on in your core development world this week? Drop a comment. Let it OUT.


Dev Chat Summary, October 8th

Agenda, IRC log.

User/Post Dropdown Performance (#)
@helen, @ericlewis
No code movement as of recently, but they’re laying out a plan to get both working in plugin form by this time next week. User dropdown works in the plugin already.
Barring further feedback, still appears that select2 is our best option in terms of a JS helper library.

Editor Focus (#)
@markjaquith, @avryl
Coming together well. At this point as many people as possible just need to test the plugin. There’s also a preview of focus. Mark considered that the existing DFW button could turn into a toggle for the new DFW, not to turn it on/off, but whether to allow its auto behavior or now.

Meta/Term/Date Query Enhancements (#)
After last week’s meeting, Boone posted an overview of the Query projects on make/core. Since then, he chugged along on the multi-relational rewrites of the Meta, Tax, and Query classes. He has got a patch ready to post for WP_Date_Query #29822 within the next day, which will complete the set.
Major blocking issue at the moment is that he needs high-level feedback on the WP_Recursive_Query proposal.

Session Manager (#)
@nacin @johnbillion
Feature plugin to display a user’s active sessions. Not a lot of dev has happened on this but there’s been several bits of discussion on its GitHub repo. One of John’s concerns is how to ensure this UI isn’t too intrusive for most users, because most users will only ever have one active session at a time. It may be best to shove this to the very bottom of the user editing screen. Screenshot. Privacy concerns were voiced over sending I.P. addresses to While it’s not saving anything in 4.0, it will be saving IPs in 4.1. Nacin suggested to use a geoip API so the page loads with IPs, and then if geoip works, locations show up.

UI Improvements for Core/Plugin/Themes Updates (#)
Nacin posted about improvements to the UI for installing/updating plugins/themes/core. @melchoyce tried to do some initial mockups for this week but it looks like they’re still in the ideas stage. Sketches, rough prototype. Further discussion in #29820.

Open Floor (#)

#4-1, #meeting

Agenda for October 1st dev chat

We’ll be discussing 4.1 in today’s dev chat (October 1 2014 20:00 UTC). The release schedule can be found here.

Here’s the agenda:

We won’t be touching on 4.0.1 this meeting unless something specific comes up (nacin will be on a flight). An RC for 4.0.1 is expected by the end of the week.

Anything else you’d like to discuss? Leave a comment.

#4-1, #agenda

Press This Meeting, 2014/09/30



  • Press This will use WP API. Part of the Press This mission will be furthering WP API.
  • PT will use wp_editor() and leverage wpviews and wplinks.
  • Media, preview, and links were recognized as especially important. Media should be visual and embedded in the editor. No short codes or placeholders or out-of-band representations. Thus, wp_editor().
  • A settings page is needed but low priority right now.



#feature-plugins, #meeting, #press-this

JSON REST API: Version 1.0

I’m incredibly excited to announce the availability of version 1.0 of the JSON REST API.

This version is a huge release and introduces a bunch of new features, such as user, revision and post meta endpoints. It also introduces our long-term backwards compatibility policy, aligning with WordPress core backwards compatibility.

Here’s a selection of the new stuff:

  • Add user endpoints.

    Creating, reading, updating and deleting users and their data is now possible
    by using the /users endpoints. /users/me can be used to determine the
    current user, and returns a 401 status for non-logged in users.

    Note that the format of post authors has changed, as it is now an embedded
    User entity. This should not break backwards compatibility.

    Custom post types gain this ability automatically.

    (props @tobych, @rmccue, #20, #146)

  • Add post meta endpoints.

    Creating, reading, updating and deleting post meta is now possible by using
    the /posts/<id>/meta endpoints. Post meta is now correctly embedded into
    Post entities.

    Meta can be updated via the Post entity (e.g. PUT to /posts/<id>) or via
    the entity itself at /posts/<id>/meta/<mid>. Meta deletion must be done via
    a DELETE request to the latter.

    Only non-protected and non-serialized meta can be accessed or manipulated via
    the API. This is not predicted to change in the future; clients wishing to
    access this data should consider alternative approaches.

    Custom post types do not currently gain this ability automatically.

    (props @attitude, @alisspers, @rachelbaker, @rmccue, @tlovett1, @tobych,
    @zedejose, #68, #168, #189, #207)

  • Add endpoint for deleting a single comment.

    Clients can now send a DELETE request to comment routes to delete
    the comment.

    Custom post types supporting comments will gain this ability automatically.

    (props @tlovett1, @rmccue, #178, #191)

  • Add endpoint for post revisions.

    Post revisions are now available at /posts/<id>/revisions, and are linked in
    the meta.links.version-history key of post entities.

    Custom post types supporting revisions will gain this ability automatically.

    (props @tlovett1, #193)

  • Respond to requests without depending on pretty permalink settings.

    For sites without pretty permalinks enabled, the API is now available from
    ?json_route=/. Clients should check for this via the autodiscovery methods
    (Link header or RSD).

    (props @rmccue, #69, #138)

  • Add register post type argument.

    Post types can now indicate their availability via the API using the
    show_in_json argument passed to register_post_type. This value defaults to
    the publicly_queryable argument (which itself defaults to the
    public argument).

    (props @iandunn, @rmccue, #145)

  • Remove basic authentication handler.

    This breaks backwards compatibility for clients using Basic
    authentication. Clients are encouraged to switch to using OAuth
    . The Basic Authentication plugin can be
    installed for backwards compatibility and local development, however should
    not be used in production.

    (props @rmccue, #37, #152)

  • Require nonces for cookie-based authentication.

    This breaks backwards compatibility and requires any clients using cookie
    authentication to also send a nonce with the request. The built-in Javascript
    API automatically handles this.

    (props @rmccue, #177, #180)

  • Clean up deprecated methods/functions.

    Functions and methods previously deprecated in 0.8/0.9 have now been removed.
    Future deprecations will take place in the same manner as WordPress core.

    This breaks backwards compatibility, however these were marked as
    deprecated in previous releases.

    (props @rmccue, #187)

  • Only expose meta on ‘edit’ context as a temporary workaround.

    Privacy concerns around exposing meta to all users necessitate this change.

    This breaks backwards compatibility as post meta data is no longer
    available to all users. Clients wishing to access this data should
    authenticate and use the edit context.

    (props @iandunn, @rmccue, #135)

  • Add json_ensure_response function to ensure either a
    WP_JSON_ResponseInterface or a WP_Error object is returned.

    When extending the API, the json_ensure_response function can be used to
    ensure that any raw data returned is wrapped with a WP_JSON_Response object.
    This allows using get_status/get_data easily, however WP_Error must
    still be checked via is_wp_error.

    (props @rmccue, #151, #154)

  • Use version option to check on init if rewrite rules should be flushed.

    Rewrite rules on multisite are now flushed via an init hook, rather than
    switching to each site on activation.

    (props @rachelbaker, #149)

As always, you can view all commits or the longer changelog.

For those interested, here’s the list of contributors to this release:

$ git shortlog --summary 0.9...
     1  Chris Marslender
     1  Eric Lanehart
     2  K.Adam White
     1  Kat Hagan
     2  Matth_eu
    41  Rachel Baker
   139  Ryan McCue
     5  Taylor Lovett
    10  Toby Champion

There’s a few really important things to note with this release.

Authentication Changes

Authentication has changed significantly in 1.0. If you’ve been using Basic authentication previously, you’ll now need to install the Basic authentication plugin. This plugin is designed for local development, as Basic authentication requires sending your plaintext credentials over the wire, which is unsafe for production.

Production users have two choices: built-in cookie authentication, or OAuth authentication. OAuth 1.0a is an authorization protocol that allows you to authorize clients to act on your behalf, and does not require giving your username and password to the client. It does, however, require a significantly more complicated authentication/authorization process, and clients are required to register on the site beforehand. We’re working on long-term solutions to this.

Plugins and themes can also use built-in cookie authentication. This is the normal WordPress login process, however requires a nonce for authentication to the site. This is automatically handled for you when using the built-in Javascript client.

Backwards Compatibility

From this release forwards, backwards compatibility will not be broken. This includes both the internal PHP API, as well as the REST API we expose. New endpoints may be added, as well as new data, but responses will continue to be supersets of the current response.

The exception to this is for security concerns. As we continue development, we may need to change some endpoints for security issues, as we did with post meta for this cycle. These will be announced well before release where possible.

Please note also that this release has removed some previously deprecated methods and changed some internal implementation details. This only affects plugins or themes that extend the API.

Core Integration

We’re pushing hard for integration into 4.0 this cycle, and we need your help. Our core integration plan outlines the motivation behind the project and the specific plan for integrating it into core. We’re currently working on a comparison document for the API compared to the API and others, and will be publishing that soon.

We need your help to make it into 4.0. Developers, we’d love to know what you’ve built with the API, whether public or internal (even vague details help!), and we’d especially love to see things built with the API. We’re currently in danger of not making it in this cycle, so anything you can do to help us here would be fantastic.

As always, we’re also looking for help. The main API always needs help, and the other related projects do too. Both the WP-CLI client and Javascript client need help here.

You’re always welcome over at the team o2, and our next meeting will be at Tuesday, 00:00 UTC; we’d love to see you there. If not, see you soon for version 1.1!

#json-api, #rest-api