Make WordPress Core

Welcome to the official blog of the core development team for the WordPress open source project.

Here, we make WordPress core. Follow our progress with general updates, status reports, and the occasional code debate.

We’d love for you to help out.

Looking to file a bug?

It’s easy to create a ticket on our bug tracker.

Want to contribute?

Get started quickly. We have some tickets marked as good first bugs for new contributors. There’s more on our reports page, like patches needing testing.

We also have a detailed handbook for contributors, complete with tutorials.

Weekly meetings

We use Slack for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day.

We have a project meeting every Wednesday at 20:00 UTC in the #core channel on Slack. (Find out more about Slack.)

You can find meeting agendas on this blog. You’re welcome to join us or listen in.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Nick Halsey 2:49 am on October 24, 2016 Permalink |
    Tags: ,   

    Customize Update 2016-10-23 

    This is the weekly update post for the customize component. It includes a summary of this week’s meeting, recent commits, and next week’s meeting agenda.

    4.7 Feature Proposals & Merges

    Three proposal posts have been published and approved since our last update:

    Customize Changesets (formerly Transactions) Merge Proposal

    Customize Changesets Technical Design Decisions

    Feature Proposal: Better theme customizations via custom CSS with live previews

    All five of the major customize feature projects proposed for WordPress 4.7 have been successfully merged (in order):

    Work continues on follow up tickets for many of these projects. Please test everything in the customizer and report any bugs to trac. We still have a few pending enhancements that need to be completed by this Wednesday, 10/26, 4.7 beta 1, sorted by priority:

    1. #27403 Improve UI for linking areas of Customizer preview to corresponding controls (desktop and mobile) – has-patch, needs testing and adjustments
    2. #38263 Color picker: add a hue-only mode – has-patch, needed for Twenty Seventeen
    3. #28536 Add browser history and deep linking for navigation in Customizer preview – needs-patch
    4. #38164 Customize: assign static front page and posts page to new pages – has-patch
    5. #37964 Allow customizer controls to be encapsulated by accepting pre-instantiated settings – has-patch, needs adjustments
    6. #22058 Improve custom background properties UI – has-patch
    7. #29158 Customizer UI Design lacks contrast for visual hierarchy and does not match wp-admin – has-commit, has-patch for revisions

    Weekly Customize Meetings

    Our past two weekly meetings have focused on preparing our projects for commit. We’ll continue our weekly 4.7 meetings into beta and RC pending the volume of customize tickets remaining in the milestone. For this week’s meeting, our priority will be ensuring that the 7 remaining customize enhancements for 4.7, listed above, are committed before beta 1.

    Our weekly update posts will continue on a reduced schedule now that the bulk of 4.7 development is complete, and we’ll also continue posting dev notes for changes in 4.7.

    Recent Customize Commits

    Here are the customize-related commits for the past two weeks:

    • [38765]: Customize: Ensure `customize_validate_{$setting->id}` filters apply on input post_values for WP_Customize_Setting subclasses that neglect to apply the filter themselves.
    • [38766]: Customize: Improve message displayed in widgets panel when there are no widget areas currently displayed in the preview.
    • [38767]: Customize: Show Pages section first and pre-expanded in list of available menu items.
    • [38794]: Customize: Move Pages below Custom Links in available nav menu items panel.
    • [38807]: Customize: Skip triggering initial click on pages section for available nav menu items if already open.
    • [38810]: Customize: Implement customized state persistence with changesets. 
    • [38811]: Customize: Split out link `click.preview` and form `submit.preview` event handlers…
    • [38813]: Customize: Introduce a new experience for discovering, installing, and previewing themes in the customizer.
    • [38829]: Customize: Introduce custom CSS for extending theme styles.
    • [38830]: Customize: Fix unit tests when `twentyfifteeen` is `WP_DEFAULT_THEME` instead of twentyfifteen.
    • [38831]: Customize: Improve the labeling of background and header images in the list mode of the media library.
    • [38837]: Twenty Seventeen: Fix a PHP warning on fresh installs.
    • [38850]: Tests: Prevent Twenty Seventeen from interfering with Customizer tests.
    • [38851]: Tests: Prevent Twenty Seventeen from interfering with Customizer ajax tests.
    • [38853]: Customize: Add sticky headers for panels and sections.
    • [38862]: Customize: Revert part of [38859] which caused sections to get deactivated in the customizer.
    • [38867]: Twenty Seventeen: Add theme support for customize selective refresh.
    • [38881]: Customize: Keep previously uploaded header images in place.

    Big thanks to those who contributed to patches committed this week: @johnregan3, @celloexpressions, @folletto, @westonruter, @deltafactory, @coreymcollins, @desrosj, @pento, @delawski, @davidakennedy, @afercia, @karmatosed, @ryankienstra, @valendesigns, @utkarshpatel, @stubgo, @lgedeon, @ocean90, @mihai2u, @dlh, @aaroncampbell, @jonathanbardo, @jorbin.

    We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved. Tickets in the Future Release milestone will be considered first for 4.8 if they have a patch.

  • K.Adam White 1:55 am on October 24, 2016 Permalink |
    Tags: , ,   

    API: Agenda for October 24 Meeting 

    Here’s the agenda for Monday’s weekly meeting for the API project, at 2016-10-24 14:00 UTC in the #core-restapi channel in slack. The meeting will run for one hour.

    • Discuss post-merge Process Changes & the future of the WP-API GitHub Repository
    • Review Trac tickets: what hasn’t been migrated from GitHub?
    • Clarify priorities & responsibilities leading up to Beta 1
    • Open floor.

    Meetings are every Monday at 1400 UTC. See you there!

  • David A. Kennedy 11:14 pm on October 21, 2016 Permalink |
    Tags: , ,   

    Twenty Seventeen Meeting Notes: Oct. 21 2016 

    Here’s the meeting summary for this week. If I missed anything, let me know in the comments.



    • General theme update: The theme merged to Core this week, and now has a demo. The site pulls updates from trunk every 10 minutes. All GitHub issues remaining that needed to be addressed were ported to Trac.
    • In the tickets, there are a lot of small issues on different devices. I encourage everyone to test and help on those if you have the appropriate devices.
    • #38375: Flatten/rename TwentySeventeen directory structure: The group decided to keep the assets directory as is and rename `components` to template-parts. The ticket will be updated.
    • #38390: Twenty Seventeen: Playlists don’t render on blog/archive pages: The group decided the best option here for now is to update the core function get_media_embedded_in_content() to check to make sure there’s actually a src in the tag before pulling out content. The ticket will be updated. @joemcgill offered to help there.
    • The group discussed video headers some, #38172. A new patch has been added that helps mitigate large file sizes, but should be tested. Adding the functionality to add videos from a URL, like YouTube, would help this feature progress. It still needs more work though.
    • #38426: Twenty Seventeen: Improve user and developer experience with the customizer integration: This ticket needs to be addressed, but best to do it there since it covers a lot.


  • David A. Kennedy 5:49 pm on October 21, 2016 Permalink |
    Tags: , ,   

    Twenty Seventeen: Agenda for Oct 21, 2016 Meeting 

    Here’s the agenda for today’s weekly meeting on Twenty Seventeen. It will last 30 minutes, and I’ll be around in the #core-themes channel for at least 30 minutes afterward to answer any questions.

    Reminder: Meetings are every Friday at 18:00 UTC.

  • Andrew Rockwell 3:13 pm on October 20, 2016 Permalink |  

    Week in Core, October 5 – 18, 2016 

    Welcome back the latest issue of Week in Core, covering changes [38736-38810]. Here are the highlights:

    • 74 commits
    • 76 contributors
    • 129 tickets created
    • 20 tickets reopened
    • 124 tickets closed

    Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.


    • Accessible Tags autocomplete: [38797] #33902
    • Better consistency for the Media, Add Plugins, and Add Themes toolbars. [38795] #38010

    Build/Test Tools

    • Continue eliminating randomness in tests. [38763] #37371
    • Begin eliminating unnecessary randomness in tests. [38762] #37371
    • Revert [38759]. PHPUnit’s @requires syntax was introduced in PHPUnit 3.7, but the tests for PHP 5.2 use PHPUnit 3.6 because it’s the latest version that supports PHP 5.2. [38761] #38256
    • Make use of PHPUnit’s @requires notation. [38759] #38256
    • HTTP API: Remove an unnecessary duplicate HTTP request in the HTTP tests. [38758] #30017
    • HTTP API: Convert the POST redirect test to use a dataProvider in order for its speed to be more accurately measured. [38757] #38237


    • Allow _canonical_charset() to handle mixed-case strings. [38809] #38337


    • When checking comments, returned error object should include HTTP status code. [38783] #36901
    • Abstract die() calls from comment submission routine. [38778] #36901
    • Pass $comment to the comment_max_links_url filter. [38748] #37955
    • Account for the comment_order option in get_page_of_comment(). [38740] #31101
    • Improve check for previous comments for authenticated users in check_comment(). [38738] #28603


    • Implement customized state persistence with changesets. [38810] #28721, #31089, #30937, #31517, #30028, #23225, #34142, #36485
    • Skip triggering initial click on pages section for available nav menu items if already open. [38807] #36984
    • Move Pages below Custom Links in available nav menu items panel. [38794] #36984
    • Show Pages section first and pre-expanded in list of available nav menu items. [38767] #36984
    • Improve message displayed in widgets panel when there are no widget areas currently displayed in the preview. [38766] #36922
    • Ensure customize_validate_{$setting->id} filters apply on input post values for WP_Customize_Setting subclasses that neglect to apply the filter themselves. [38765] #37638
    • Add workaround for Safari bug causing preview frame to be unscrollable via mousewheel after a refresh. [38742] #38149



    • Add a role button to the Tags meta box tag cloud links. [38800] #38318
    • Do not send the request for releasing the post lock on unload when post_ID or active_post_lock is missing. [38772] #38271


    • Docs: In get_pages() and wp_list_pages(), note that post_status argument can also be an array. [38798] #38136
    • XML-RPC: Re-add a global $wpdb missed in [38768]. [38775] #37699
    • Restore usage of $wpdb, instead of $this->db. [38768] #37699
    • Login: Don’t rely on wp_is_mobile() for functionality. [38739] #33704


    • Media modal: make it possible to reorder images by dragging on devices with both touch screen and mouse support. [38793] #31652
    • Correct the hostname used in the wp_get_attachment_metadata() test. [38760] #36246



    • Emoji: Update Emoji CDN filter default for resource hints. [38764] #38724
    • Updates for 4.6. Merge of and to the 4.6 branch.

    Networks and Sites

    • Multisite: Maintain switched state in site icon/logo functions. [38786] #38253
    • Multisite: Clarify that get_site_by_path() does not return exact matches. [38781] #38152


    • Add new pre_trackback_post action before a trackback is added to a post. [38791] #37007
    • Trackbacks: Allow the error message strings passed to trackback_response() to be translatable. [38741] #38214


    • Docs: Improve documentation for install_plugin_install_status(). [38805] #36912
    • Correctly display the current plugin in the plugin editor. [38745] #24122, #17552

    Posts, Post Types

    • Docs: Document global variables used by get_the_content(). [38746] #37173


    • Allow the hyphen-prefix-for-search-exclusion feature to be disabled by filter. [38792] #38099


    Rewrite Rules

    • Make sure rewrite rules are not written until wp_loaded has fired [38751] #37892


    • Disregard the order of capabilities when testing that single site and multisite capability tests match. [38802] #38191
    • Add tests for all user roles that check custom capabilities that do not have any form of handling (eg. in a map_meta_cap filter). [38769] #38191



    • Cache results of term count queries. [38784] #38295
    • Specify taxonomy when populating cached object terms. [38779] #37291
    • Avoid a fatal error in the_tags() in the event that get_the_term_list() returns a WP_Error. [38777] #37291
    • Better error handling when fetching object terms from cache. [38776] #37291
    • On wp-admin/term.php, don’t show a ‘Back to’ link which links to the current page. [38753] #37573
    • Remove paged argument from referer and add it only if current page is greater than 1. [38752] #38194
    • Don’t drop term order and current page when bulk deleting terms. [38750] #38194
    • Introduce WP_Taxonomy and use it in register_taxonomy() and unregister_taxonomy(). [38747] #36224, #36217
    • Docs: Improvements to register_taxonomy() docblock. [38737] #38007


    • Improve the inline documentation for the get_*_template() functions by providing examples instead of verbose explanations. [38789] #38249, #37770
    • Do not show an update button if there’s no update package. [38788] #37774
    • Remove paged.php from the theme template hierarchy. [38755] #38162


    • Remove the calls to getBookmark() and moveToBookmark() in IE. [38808] #38335
    • When editing pages, add body class with the page template, or page-template-default. [38803] #37599
    • Restore the monospace font in textareas in the TinyMCE UI. Make it same as in the Text editor. [38801] #38125
    • Prevent applying Indent and Outdent while an image with a caption is selected. [38796] #38313
    • Prevent iOS Safari from expanding the iframe width beyond the container width. [38782] #38289
    • Update the charmap plugin to the latest dev. version. [38780] #37936
    • Add support for custom dashicon for wp.mce.View.setLoader(). [38774] #37900
    • Update to 4.4.3, changelog: ​https://www.tinymce.com/docs/changelog/#version443-september12016 [38773] #38081, #38245, #37507, #37808, #38000
    • Allow pasting in image captions. Remove blocks and insert “ tags instead, also remove elements that would break the caption like other images, video, audio, etc. [38756] #36211


    • Show correct time of last checked update. [38743] #37554
    • Updates: Remove the ‘Download’ button on the Updates screen. [38736] #36811


    • Use the role name instead of the role display name when fetching the list of users with no role. This avoids false positives when dealing with user roles that, for example, contain spaces in the display name. [38787] #38234

    Thanks to @aaroncampbell, @abrightclearweb, @achbed, @adamsilverstein, @afercia, @akibjorklund, @aniketpant, @azaozz, @birgire, @bobbingwide, @boonebgorges, @boonebgorges for review, @celloexpressions, @Cheffheid, @choongsavvi, @choongsavvii, @Chouby, @chriseverson, @clarionwpdeveloper, @dd32, @desrosj, @dlh, @dmsnell, @DrewAPicture, @dshanske, @dungengronovius, @flixos90, @goranseric, @helen, @jamesacero, @jayarjo, @jdgrimes for initial patch, @jeremyfelt, @johnbillion, @jonathanbardo, @jorbin, @karmatosed, @koenschipper, @kraftbj, @lgedeon, @mattking5000, @MattyRob, @michalzuber, @mihai2u, @mikeviele, @morganestes, @mt8.biz, @needle, @ocean90, @pbearne, @pdufour for research, @pento, @peterwilsoncc, @PieWP for initial patch, @procodewp, @rachelbaker, @ryankienstra, @ryankienstra for initial patc, @sayedwp, @SergeyBiryukov, @solarissmoke, @stevenlinx, @stubgo, @sudar, @swissspidy, @tristangemus, @tristangemus for initial patch, @tywayne, @tyxla, @utkarshpatel, @valendesigns, @voldemortensen, @webmandesign, @websupporter, @westonruter, and @WraithKenny for their contributions!

    • programmin 3:27 am on October 22, 2016 Permalink | Log in to Reply

      Nice! Will the fix making galleries draggable in media modal on all browsers be fixed in 4.6.something or in 4.7?

  • Jeff Paul 4:00 am on October 20, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: October 19 (4.7 week 9) 

    This post summarizes the dev chat meeting from October 19th (agenda, Slack archive).


    Dev Notes / Field Guides

    • In general, if you worked on something that needs to be called out for testing or building upon, there should be a post about it.  These are all tagged as `dev-notes` on the Make/Core site.  The target is everything written before beta 2 so we can get a field guide summarizing them and an email sent to all plugin developers while we are still in beta. In general all active components should have at least one post about what has changed.

    Final Merge Decisions

    • Twenty Seventeen (@davidakennedy)
      • Merge Proposal & Trac ticket
      • 59 contributors. Merging later today.
      • There are 34 issues left, some of which will be moved to Trac. There are 0 pull requests left.
      • A code review was performed by @aaroncampbell, and he didn’t find anything that should hold up merge.
      • Theme does not depend on any core features being merged before/at the same time, but will greatly benefit from any completed.
      • Video headers (#38172) needs consensus on the best approach and testing of functional patches
      • Merge proposal accepted. 🎉
    • REST API: Content API (@kadamwhite)
      • Merge ProposalSuccess metrics
      • 99 contributors. 25 merged PRs in the past 3 days. 27 issues left in the current milestone and a few stray PRs, which will be closed out shortly or moved to Trac.
      • Monday meeting in #core resulting in conditional merge approval
      • Conditions:
        • 1) 4.7: Press This / Quick Draft Core feature (#38343 and #38342)
        • 2) 4.7: Object / non-single level meta. @joehoyle, @jnylen and others have been working on this, tracking via GitHub.
        • 3) 4.7: Define success metrics (see link above)
        • 4) 4.7: Continuing to ensure the API forward compatibility (EVERYONE should be building things with it).
        • 5) 4.7: Review .com API settings discrepancies, determine how to resolve or where to document. @joehoyle, @jnylen and others have been working on this; Progress/documentation.
      • WP-API is code-frozen at this time; open enhancements will be ported over by @rachelbaker as appropriate.
      • Merge proposal accepted (“Let’s do it.”). 🎉

    Components and Other Enhancements

    • i18n (@swissspidy)
      • Nothing newsworthy from the i18n side which isn’t already on Make/Core.
    • Make it easier to visualize where to put your content in a given theme (aka “dummy content”)
      • If there are people out there interested in content writing and stuff like customizer integration, hit up @helen.
    • Media (@mikeschroder, @joemcgill)
      • We’re working on trying to get #31050 (Better PDF Upload Management) into shape for commit this week. Still some issues to iron out, but it’s getting close.
      • I want to call out that we’ve removed the automatic fallbacks for generating `alt` attributes from images with consultation from the a11y team to improve the user experience for screen readers. See: #34635 for details.
      • We have a few other things we’re looking at this week, but if there is anything pressing that needs eyes specifically from someone on the Media team, please reach out in #core-media.
    • Customize (@westonruter, @celloexpressions)
      • Remaining three major 4.7 feature projects merged in the last 24 hours.
      • #27403 and #38164 are our larger remaining tickets needing attention currently, with #29158 and #22058 pending final patches for review and discussion.
    • Editor (@azaozz, @iseulde)
      • TinyMCE: allow pasting in image captions (#36211) needs some more testing
        • Add an image in the editor, add a caption, then try pasting different things copied from another web page in it. This makes some assumptions of what the user expects, and what should happen, i.e. when pasting an image into a caption it should remove the image but let the text in, or keep all that is pasted but move it under the caption?
  • Jeff Paul 3:59 am on October 20, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: October 12 (4.7 week 8) 

    This post summarizes the dev chat meeting from October 12th (agenda, Slack archive).


    Feature Proposals for 4.7

    • REST API: Content API (@kadamwhite)
      • REST API Team Update
      • Content API endpoints have been stable for some time and now have the missing functionality established at the start of this development cycle
      • We pitched merging in the OAuth 1 server alongside those content endpoints, to simplify the process of authenticating from remote applications
      • The auth method in core right now is cookie/nonce-based, so it’s available to any code running within the same domain as the main WordPress install and leverages the existing login cookie
      • plugins and themes that utilize JS to enhance the editing experience within their admin UI have full read/write access, restricted to the capabilities of the authenticated user
      • External applications, e.g. a mobile app, desktop app or external server, would have read-only access
      • readers, aggregators, etc are possible without authentication, and more complex read-write apps can be written by installing one of the available authentication plugins, of which OAuth is but one
      • Reference for options and when/how to use
      • 90 contributors for the rest-api plugin
      • automated test coverage currently at 90.44%
      • 37 more open tickets
      • weekly meeting on Monday at 1400UTC in #core-restapi
    • Discovering and installing themes in the customizer (@celloexpressions)
      • Related Make/Design and Make/Flow posts, but best to post all feedback to the Make/Core feature proposal
      • Working through the accessibility feedback, but it’s a bit unclear what’s specific to this feature versus the customizer in general, and which issues are also present in the admin theme installer
      • Haven’t heard anything from polyglots, security (unlikely to have any issues), or docs
      • There is one known i18n concern where we’ll need a compromise until we have JS i18n in core
      • @celloexpressions to do a final iteration to pick up any remaining feedback on Thursday, then pass to @westonruter for the code review process
    • Custom CSS with live previews (@celloexpressions)
      • seems to have decent support as a feature, with the biggest question in the comments being how to store and output the CSS
      • CSS is output from the db via a style tag, use of `style` tag is key for targeting for `postMessage` live preview
      • Post-based storage allows for revisions built in (ensuring that there are hooks for a plugin that wants to write a file would alleviate many concerns)
      • CSS is theme-specific in the proposal for this, with a post object for each theme that has CSS
      • Scheduling a meeting to go through these concerns and make a decision, coordination to occur in #core-customize
    • Customize Changesets (née Transactions) (@westonruter)
      • Technical Post (audience is developers who have extended the customizer significantly, as there may be impacts to any heavy customizer integrations since changesets touches some very low-level stuff in the customizer)
      • Users will be able to bookmark a customizer session since the changeset UUID will be part of the URL
      • Theme switches will no longer result in changes being lost (no more AYS dialog)
      • a few other open questions and issues that have been noted


  • Joe McGill 9:36 pm on October 19, 2016 Permalink |
    Tags: ,   

    Media Weekly Update (Oct 14) 

    This post serves to jump-start discussion before the weekly check in, which takes place in #core-media on Slack. The next meeting is Friday, October 21 at 17:00 UTC and agenda for these meetings includes moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    Summary from last week

    The last meeting was Friday, October 14 at 17:00 UTC. You can read the entire chat log in the #core-media channel on Slack.

    Attendees: @mikeschroder, @karmatosed@adamsilverstein@paaljoachim, @mapk, @flixos90, and @azaozz.

    • Media organization improvements:
      • Last week, we chatted about starting up design for Media organization improvements. @paaljoachim and @flixos90 started sketching flows in GitHub.
      • @karmatosed mentioned focussing on documenting the current flows this week.
    • Add new core media widget (#32417) – No progress was made this week and it’s now too late for 4.7, but work should continue so it’s ready for a future release.
    • Rotate Full Size Images on Upload (#14459) – @mikeschroder planned to do additional profiling re: complete resize+rotate times for upload vs editing.
    • Better PDF Upload Management (#31050) – @mikeschroder is putting more attention on trying to get this in this release after chatting with @helen.
    • Drag/Drop Ordering of Media Does Not Work in Chrome on touch enabled devices (#31652) – @adamsilverstein noted that the patch to enable sortable on touch devices was ready to commit, which was handled in [38793] this week. Additional discussion about reducing reliance on `wp_is_mobile()` is happening on #33704.
    • Accents in attachment filenames should be sanitized (#22363) – @gitlost has been working on updates for this ticket, which is now closely related to fixing #24661 (`remove_accents()` is not removing combining accents”).
    • Usage of `image_size_names_choose` breaks JS attachment model attributes (#34981)@azaozz suggests using srcset in the media library to make sure full size images aren’t used if a smaller image is available (as described in the ticket description).
    • Responsive images (srcset) can include images larger than the full size (#36477) – The latest patch, which utilized `Imagick::getImageColors` adds a significant performance concerns. @mikeschroder punted this out of the current milestone for now.

    Agenda for the next meeting

    This week, discussion will continue on priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-media channel.

  • Helen Hou-Sandi 7:40 pm on October 19, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for October 19 (4.7 week 9) 

    This is the agenda for the weekly dev meeting on October 19, 2016 at 20:00 UTC:

    If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

  • Brian Krogsgard 4:37 pm on October 19, 2016 Permalink |
    Tags: ,   

    WordPress REST API Success Metrics 

    This post is part of the conditional merge of the WordPress REST API.

    Tracking and measuring specific success metrics is a priority for the WordPress REST API Content Endpoints project. The aim is to be able to look back at the implementation of the feature project to see how it went after the fact, and to utilize that information to inform future decision making.

    A submission form will be created to help track implementations, in addition to automated scripting and analysis. Feedback will be grouped based on which metric it applies to. Developers and implementers will be polled to determine usage, where automation is a challenge.

    It is very important to note prior to analyzing individual goals, that these goals and the achievement of them does not automatically indicate success, or that not achieving them means a lack of success. For instance, one metric that’s very hard to capture in goals like those that follow is the impact of a singular implementation. One highly impactful implementation could indicate a great deal of success, but would not be fully captured by the following metrics. These goals are established to help identify success metrics that would offer clear insight on the project, but they are not all encompassing or definitive alone.

    Metric #1: Plugin utilization

    Per the “Popular” plugins page of the WordPress Plugin Directory, the following can be determined:

    • 21 plugins have 1m+ active installs
    • 126 plugins have 200,000+ active installs
    • 232 plugins have 100,000+ active installs

    Many of these are not good candidates for utilizing the REST API, but there are a number of plugins that are.

    The following goals are proposed:

    • 15% utilization of plugins with more than 1 million installs.
    • 7% utilization of plugins with more than 200,000 installs and fewer than 1 million.
    • 3% utilization of plugins with more than 100,000 installs and fewer than 200,000.

    Additionally, it is proposed to seek 5-10 examples of non-directory or otherwise prominent plugins, that may not fit the above metrics, to showcase their utilization of the API, and how it has benefited them. This may include commercial plugins.

    Timeline for analysis: three major releases after merge (5.0 release day).

    Metric #2: Distributed theme utilization

    Popular themes are a bit of a misnomer in the WordPress landscape. The default themes or themes that have been around for a very long time account for a significant percentage of all active themes. And feature development isn’t as common for existing themes as it is for existing plugins.

    In addition to polling free theme makers, top theme shops (according to Alexa) should be polled to determine usage of the API for theming purposes.

    Additionally, coordination can occur with the Theme Review Team to identify usage of the API in newly submitted themes, to determine adoption.

    The API could be useful in themes themselves, as well as complimentary plugins, which are not likely to be picked up by the plugin analysis. However, it’s difficult to know exactly how WordPress themes may use the content endpoints in a distributed theme context. It could be part of efforts within the customizer, page building, custom widgets, etc.

    A goal of 2% adoption of the API in new themes is proposed, determined within three major releases, and analyzed amongst distinct ecosystems:

    • New WordPress.org theme review submissions
    • Third party theme shops (A shop using the API in any capacity, likely new releases, would count as “yes”, rather than theme by theme)
    • Analysis of page builder or helper plugins
    • Distinct theme communities with “builder”, “framework”, or “starter” themes.

    Metric #3: Custom development implementations

    The WordPress REST API is immediately useful for custom development projects, where the developer has control over the environment. The REST API in core provides a vote of confidence to outside developers that they are building with an API that has the full backward compatibility and stability expected of features in the core project.

    It is proposed to identify 50+ projects in production or under development utilizing the Content Endpoints, within two major release cycles.

    The likelihood is that there will be far more consumption-only applications, versus those that manipulate content. Within the same two release timeframe, the goal is to identify at least 12 custom projects that utilize the Content Endpoints beyond a read-only use case.

    Metric #4: Core development and feature projects

    The WordPress REST API can aid core development and feature projects. Items like Quick Draft, Press This and a menu bar revisions browser are test cases for using the API in a core context with WordPress 4.7.

    Utilization of the API for additional core features and feature projects will be tracked over the next three major release cycles. It is proposed to identify 6 core features or patches than can utilize the API, as well as 1 feature project, within three major releases.

    • Boone Gorges 6:06 pm on October 19, 2016 Permalink | Log in to Reply

      Many thanks to the API team for work on this excellent document.

      A couple of questions and comments:

      • What counts as “utilization” in a theme or plugin? Will you be grepping for a certain string (‘wp-json’?) in the plugin source? Relying on self-reporting of some sort?
      • You propose to “identify” custom projects using the endpoints. Will these projects exclude those that are using a publicly-available plugin/theme to integrate with the API (since those projects would be counted as part of Metric #1 or #2)? Are we just collecting project names, or is the plan to get more significant details about the project? How will the data be collected? (Details aren’t necessary – just want a gesture in the direction of the mechanics.)
      • Brian Krogsgard 6:21 pm on October 19, 2016 Permalink | Log in to Reply

        @boonebgorges Good questions.

        What counts as “utilization” in a theme or plugin? Will you be grepping for a certain string (‘wp-json’?) in the plugin source? Relying on self-reporting of some sort?

        We plan to scan those top few hundred plugins for “wp-json” or similar, as well as allow for self reporting through a form and potential surveys. I have several ideas on the self-reporting front that I didn’t get into very much with this post.

        Will these projects exclude those that are using a publicly-available plugin/theme to integrate with the API (since those projects would be counted as part of Metric #1 or #2)? Are we just collecting project names, or is the plan to get more significant details about the project?

        The way I imagine custom projects is someone is using the content endpoints within a non-distributed codebase. So no, it wouldn’t include someone using a plugin that has the endpoints — as you mention, those would be counted in #1 and #2.

        There’s been a floating Google Doc with information on plugin usage that’s a good start, but I want to make it easier and a nicer display than that.

        How will the data be collected?

        Self reporting (forms and surveys) mostly. We also discussed working with hosts to determine API calls but just theoretically so far.

        • Aram Zucker-Scharff 6:45 pm on October 19, 2016 Permalink | Log in to Reply

          Just going to note here, I have a plugin that builds extensively on the WP-API and it doesn’t use the string “wp-json” even once. Why not scan for “rest_api_init” as well, as that seems a more likely indicator of a plugin having extended the API?

    • Mike Nelson 6:19 pm on October 19, 2016 Permalink | Log in to Reply

      How were the numbers for these goals determined? Eg why not “50% utilization of plugins with more than 1 million installs.” or “1% utilization of plugins with more than 1 million installs.”?

      Might it be useful to compare utilization of the REST API to other features/APIs of WP? Eg what is the adoption of the XML RPC? Usage of admin-ajax? Usage of the settings API, or filesystem API, etc?

      I think having a ballpark for usage of these other systems might help determine the usage goals for the REST API.

      • Brian Krogsgard 6:28 pm on October 19, 2016 Permalink | Log in to Reply

        How were the numbers for these goals determined? Eg why not “50% utilization of plugins with more than 1 million installs.” or “1% utilization of plugins with more than 1 million installs.”?

        I know your numbers are for example only, but to answer nonetheless…. Many of the 1M+ plugins are non-starters for the REST API, so 50% of 1mm+ is actually much higher (maybe close to 100%) when you consider which would be candidates to utilize it anyway. 1% would be a non-integer less than 1 🙂

        The numbers are based on looking at the plugins and using our best judgement. It’s not all-encompassing, and while I would love to work with more data, these numbers have a degree of “best guesses” applied, based on collective experience in the WordPress world and familiarity with the API as well as plugin landscape.

        The reason we kept it limited to the plugin groups we did was so that we’d have a more targeted sample that’s more definitive and measurable than all plugins anywhere. Hence, that’s why we have the additional goal of 5-10 specific cases outside that plugin sample.

        As noted at the top of the post, we hope these numbers can help offer insight, but they are not an all-encompassing measurement of the APIs success, and one area they can miss is impact of a single use case.

        We don’t know exactly how the API will be used yet, but we think these goals set some realistic, but in some ways ambitious, goals that we can measure against, so that in a year or so we can look back and compare what we thought might happen versus what actually happened.

        And while this may be new for WordPress with this project, it could provide an interesting model for other feature projects as well.

        • Mike Nelson 12:10 am on October 20, 2016 Permalink | Log in to Reply

          > Many of the 1M+ plugins are non-starters for the REST API

          meaning there’s really no obvious way for them to use it right? It might be good to have it recorded what percentage of plugins/themes etc are non-starters for REST API usage (eg so we can have a guess at the upper limit of how many will use it).

          > in a year or so we can look back and compare what we thought might happen versus what actually happened.

          Ok so these numbers are “what we think adoption will be, if it’s ‘successful'”-ish.

          > And while this may be new for WordPress with this project, it could provide an interesting model for other feature projects as well.

          Yeah I think certainly having some estimates of how to measure success is good, even though it’s obviously really hard to boil down success into numbers

    • Mike Nelson 12:14 am on October 20, 2016 Permalink | Log in to Reply

      Another usage that could be measured would be non-WordPress projects using the REST API. Eg a Django module that works with the REST API, or an iOS app, or zapier integration, etc.

      This might fit under “Metric #3: Custom development implementations”; and admittedly might be difficult to track considering these developers are probably not terribly involved in the WP community.

    • Darren Ethier (nerrad) 5:14 pm on October 20, 2016 Permalink | Log in to Reply

      This might be something you’ve already considered as a part of your self-reporting. But it’d be nice if there was a dedicated place where anyone could post about something they’ve come across using the REST API. That way we could enlist (through various avenues of promotion) the WordPress community to document places where they see the REST API being used.

      It’s likely that there will be developers outside the WP community who might build something using the REST API that would have no clue that the community is wanting to know about projects using it, but someone who IS aware of this and sees this developer’s work could report it.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar