Make WordPress Core

Recent Updates Page 4 Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 6:12 pm on October 5, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for October 5 (4.7 week 7) 

    This is the agenda for the weekly dev meeting on October 5, 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!

  • David A. Kennedy 10:46 pm on October 4, 2016 Permalink |
    Tags: , ,   

    Twenty Seventeen Features Meeting Notes: Oct. 4 2016 

    Here’s the summary for this week. The meeting was busy, so feel free to add anything missed in the comments.



    The group:

    • discussed #37974 (Add multi-panel feature to pages through add_theme_support) for the majority of the meeting. The goal was to find a minimum viable product that could be developed in the time left.
    • decided to shoot for this feature to be 1. limited to the front page only. 2. exist in the Customizer 3. provide basic markup, created by Core.
    • decided this story board stood out as the strongest to be iterated on and mocked up as a design.
    • decided live preview in the Customizer wasn’t critical at the current time.
    • @helen and I will work on marshaling people to help with the project.
    • @karmatosed will work on the initial mock-up of the feature.
    • briefly discussed #38172 (Enable video headers in custom headers) It also needs to have a minimum viable product defined and those interested were encouraged to comment on the ticket with that in mind.
    • brought up #19627, and that could be worked on but it’s not a priority over the other major features for Twenty Seventeen.

    Next steps

    • For Add multi-panel feature to pages through add_theme_support, the mock up will be created and developers are needed to work on it.
    • For Enable video headers in custom headers, a clearer scope needs defining and more developers are needed to work on it. A basic patch exists for this ticket. 

    Call for help

    Twenty Seventeen needs you. Home pages should be fun to create and a heck of a lot easier. Headers can be even more captivating. If you’re interested in working on either of these projects, please let me or @helen know.

    • Nick Halsey 12:45 am on October 5, 2016 Permalink | Log in to Reply

      On #37974, “decided live preview in the Customizer wasn’t critical at the current time” is in conflict with “decided to shoot for this feature to be … 2. exist in the Customizer”.

      To be clear, if it’s in the customizer it needs to support live preview with selective refresh transport at a minimum. My suggestion there was that it may be more appropriate as part of the content editing flow given the restriction to pages for now.

      I can help with video headers development, particularly on the customizer side. Let me know when and exactly what you’d like me to work on there so we don’t patch at the same time.

    • Ahmad Awais 10:39 pm on October 5, 2016 Permalink | Log in to Reply

      Looking forward to helping maintain code standards and Customizer panels in TwentySeventeen.

  • Eric Andrew Lewis 3:57 pm on October 4, 2016 Permalink |

    Using Custom Bulk Actions 

    Sorry it’s been such a long time since my last blog!

    I’m happy to tell you that in WordPress 4.7, developers can register their own bulk actions on list table screens.


    Let’s walk through the steps required to add one.

    An option in the dropdown

    To add an option in the Bulk Actions dropdown HTML element, register a callback on the bulk_actions-{screen_id} filter that adds the new option onto the array. Replace {screen_id} with the ID of the admin screen to offer the bulk action on.

    To add a bulk action “Email to Eric,” we could use the following code:

    add_filter( 'bulk_actions-edit-post', 'register_my_bulk_actions' );
    function register_my_bulk_actions($bulk_actions) {
      $bulk_actions['email_to_eric'] = __( 'Email to Eric', 'email_to_eric');
      return $bulk_actions;

    Handling the form submission

    To handle a bulk action form submission, register a callback on the handle_bulk_actions-{screen_id} filter for the corresponding screen. The filter expects the redirect URL to be modified, so be sure to modify the passed $redirect_url. This allows us to carry success or failure state into the next request to display a notice to the user. The other callback arguments will differ depending on the screen here to include contextually relevant data.

    To add a bulk action handler for emailing the selected posts, we could use the following code:

    add_filter( 'handle_bulk_actions-edit-post', 'my_bulk_action_handler', 10, 3 );
    function my_bulk_action_handler( $redirect_to, $doaction, $post_ids ) {
      if ( $doaction !== 'email_to_eric' ) {
        return $redirect_to;
      foreach ( $post_ids as $post_id ) {
        // Perform action for each post.
      $redirect_to = add_query_arg( 'bulk_emailed_posts', count( $post_ids ), $redirect_to );
      return $redirect_to;

    Showing notices

    We could use the existing notice hooks to let the user know what happened, depending on the state we set in the URL:

    add_action( 'admin_notices', 'my_bulk_action_admin_notice' );
    function my_bulk_action_admin_notice() {
      if ( ! empty( $_REQUEST['bulk_emailed_posts'] ) ) {
        $emailed_count = intval( $_REQUEST['bulk_emailed_posts'] );
        printf( '<div id="message" class="updated fade">' .
          _n( 'Emailed %s post to Eric.',
            'Emailed %s posts to Eric.',
          ) . '</div>', $emailed_count );

    For the curious, see the related changeset and Trac ticket.

  • Boone Gorges 3:55 pm on October 4, 2016 Permalink |  

    Proposal: Status API for taxonomy terms 

    Below is a proposal for a Term Status API. Feedback and comments are welcome below.


    Of WordPress’s four main content types – posts, comments, users, and terms – only terms does not have the concept of “status”. The wp_posts, wp_comments, and wp_users tables all have status columns. The semantics and implementation details differ across posts, comments, and users. But in each case, the idea of “status” has allowed for new and improved user experience: autosave for posts, pending user registrations, spammed comments, and so on. It’s time for terms to have their own ‘status’ too.

    Use cases

    The immediate use case for term status comes from the customizer. Recent developments have made it possible to draft nav menus and other content in the customizer before publishing to your site. The post_status API makes this possible in the case of most nav menu items: items are set to ‘auto-draft’ until the changes have been saved, which ensures that they’re never visible in the Dashboard. This corresponds nicely to the driving philosophy of the Customizer project, which is that it should be possible to preview changes to your site, with the confidence that the changes will be discarded if you choose not to save them.

    Taxonomy terms, on the other hand, cannot yet have corresponding nav items created in the customizer; see #37915. Without resorting to odd techniques (such as a “shadow taxonomy” that is hidden from normal view), it’s not possible to create a taxonomy term that is not immediately available in all relevant interfaces: metaboxes, term queries, etc. Allowing the creation of auto-draft terms will create parity between term-related nav items and other types of nav items, creating a more consistent experience for users setting up their sites in the customizer.

    Once the fundamentals of the term status API have been built, it’s possible to imagine a number of other following user-facing improvements:

    • “Trash” status for terms, including the ability to restore items from the trash
    • Private terms, which can only be seen and assigned by users with the proper capabilities
    • Autosave when editing terms in the Dashboard
    • “Pending” terms, submitted by Contributors but not generally available until approved by an Editor
    • AND SO MUCH MORE!!!!1!

    Technical outline and proposed implementation plan

    I’ve reviewed the developer-facing parts of the Taxonomy API to catalog those areas that would need adjustment with the introduction of term status. I’ve also reviewed the post_status API to get a better sense of what a relatively well-rounded implementation of “status” has to recommend (and recommend against!). Here’s how I see the implementation process, broken down into phases that may span releases.

    1. Database schema upgrade
      While it’d be possible to implement term status using termmeta, it’d almost certainly result in significant performance problems. A dedicated ‘status’ column in wp_term_taxonomy is fastest, and best parallels the other content types.
    2. Upgrade routine
      The upgrade routine would include the schema update, as well as the filling-in of the new database column for all existing terms.
    3. Status registration and fetching API functions
      The minimal functions needed for ‘auto-draft’ support are probably as follows:

      • register_term_status() (‘publish’ and ‘auto-draft’ would likely be the first two statuses implemented)
      • get_term_status(), _status_object() and _stati(), to be used when whitelisting, etc
    4. ‘Status’ support when creating or updating terms
      Presumably, this will be a ‘status’ argument in wp_update_term() and wp_insert_term(), with checks against a whitelist of registered statuses.
    5. ‘Status’ support when querying terms
      For backward compatibility, get_terms() and wp_get_object_terms() should default to returning only those terms with the ‘publish’ status. A ‘status’ parameter will allow more fine-grained filtering. This parameter will work similarly to other item queries, with support for arrays of statuses as well as magic terms like ‘any’. More specific functions like get_term_by() and term_exists() will either ignore status or presume ‘public’; more discussion is needed. We’ll also need to make decisions about how non-public terms are handled in hierarchical queries – get_pages() and friends may be helpful benchmarks.
    6. Status “transition” logic
      Similar to wp_transition_post_status(), we want hooks that fire on term status transitions.

    I take items 1-6 to be a minimal API for term statuses. Next are the details related to the first use case: ‘auto-draft’.

    1. ‘Auto-draft’ and slugs
      Posts with status ‘auto-draft’ do not get slugs, so that they don’t interfere with the creation of other posts. See wp_unique_post_slug(). ‘Auto-draft’ should probably act similarly.
    2. ‘Auto-draft’ terms should be excluded from XHR exports
      Just like posts.
    3. ‘Auto-draft’ deletion on a schedule
      Posts with ‘auto-draft’ are deleted when they’re older than 7 days. This is not likely to be a huge problem for terms, but should probably be addressed anyway.
    4. Protect auto-draft (and other terms from non-public statuses) in canonical, permalinks, and rewrites
      Things that it (probably) shouldn’t be possible to do:

      • Get a permalink of the archive for a non-public term
      • Load the archive of a non-public term on the front-end
    5. Convenience functionsSomething like wp_publish_term() would be convenient. Maybe others.

    I believe that 7-11 are pretty close to what we need to support the Customizer use case. There are a few more obvious things that can happen in future releases, independent of any specific feature:

    1. Status interface when editing/creating a term
      Auto-draft won’t be a ‘public’ status, but once another ‘public’ status is available, a dropdown should appear.
    2. Status filters for the Terms list table
      Like we have for posts.
    3. Integration with capabilities
      Work is being done on fine-grained capabilities for terms #35614. Certain statuses will probably integrate with this.

    These last items aren’t necessary for the initial use case, but are the kinds of things that developers will expect as they start using term statuses in plugins.

    Potential problems

    A couple of potential gotchas:

    • Performance. Term queries are currently pretty fast. Adding a status column, and including an additional WHERE clause with every query, is not going to make things faster. We should think about the proper use of indexes, etc.
    • Direct database queries. Plugins making direct queries against the terms tables will not properly exclude non-public terms. Not much we can do about this from a technical point of view, but we should write some good documentation to help avoid problems.
    • How to handle single term-fetching functions. get_term_by(), get_term(), and term_exists() could all be used in ways that expect the returned value to be a public term (since all terms are now, in fact, public). It would be bad if someone got back an ‘auto-draft’ term for get_term_by( ‘name’, ‘foo’ ). We can explicitly blacklist ‘auto-draft’ terms. Or we can always exclude non-public terms. Either way, we probably want to offer flexibility for developers who want to return non-public terms. I’m not sure of the strategy here: we want something that balances developer expectations with backward compatibility.

    Next steps

    #38227 will be a parent ticket for work on this project.

    There will be a meeting for all interested parties at Tuesday, October 11 18:00 in #core on Slack.

    • chatmandesign 4:20 pm on October 4, 2016 Permalink | Log in to Reply

      This sounds excellent. I look forward to seeing this feature implemented.

    • Aaron D. Campbell 4:32 pm on October 4, 2016 Permalink | Log in to Reply

      Wow @boonebgorges, this is fantastic!

      First off, looking at this I don’t particularly see a need for 1-6 to be done in a separate release prior to 7+. Obviously they’re prerequisites for 7+, but do you see any need for them to be in separate releases?

      Thoughts on Potential Problems:

      • It’s kind of too bad we can’t rely on the ability to manipulate tables. It seems like something like enum would be especially efficient here. As is, the new column with probably need to be indexed, but we can probably also look at potentially useful multi-column indexes that involve it if needed.
      • I think that we’ve set the precedent for long enough that we can’t account for direct queries when we worry about backwards compatibility.
      • My first reaction here is that it would be best for these single-term functions to ignore all non-public statuses unless someone specifies otherwise. Since we currently don’t have non-public statuses, it seems like this would be most in line with the current functionality.
      • Boone Gorges 4:36 pm on October 4, 2016 Permalink | Log in to Reply

        Thanks for the feedback, @aaroncampbell!

        Re separate releases: I agree that 1-6 doesn’t need to come before. I separated them out because, as you note, they’re a prerequisite for what comes after. If 1-11 came in a single release, that would be fine.

    • FolioVision 4:47 pm on October 4, 2016 Permalink | Log in to Reply

      Seems like making the simple complicated for the sake of the Customizer (not everyone is a fan). How about just making taxonomy changes in the Customizer permanent. This way we can maintain the current speed and not overload WordPress with more optional code and slowing performance further. Concrete5 smokes WordPress these days in head to head performance. I’d rather see us fighting for performance improvements than compromising performance further.

      • Boone Gorges 5:09 pm on October 4, 2016 Permalink | Log in to Reply

        Thanks for the feedback. As noted in the proposal, the customizer is the initial use case, but there are lots of other reasons why such an API might be helpful.

        As for processing speed, we should absolutely run benchmarks on different schemas and strategies, and take the result into consideration.

        I can’t say anything about Concrete5, but I do know that the developer experience of having disparity between content types has the potential to be an impediment that’s worth trade-offs in other areas. For this reason alone, the proposal is worth considering.

      • Nick Halsey 8:52 pm on October 4, 2016 Permalink | Log in to Reply

        This is not about the customizer. Terms are created in many places in core, and for most of them, they probably shouldn’t be published to the site immediately. Term status would allow that functionality in addition to the numerous future features outlined in the proposal.

        I tried Concrete5 once and it quickly became extremely unpleasant. Regardless, there may not be a lot of value in performance comparisons between inherently different platforms.

    • Dominik Schilling (ocean90) 7:16 pm on October 4, 2016 Permalink | Log in to Reply

      And here comes the party killer: Do we really want another status API while #12706 isn’t resolved yet?

      • Boone Gorges 7:40 pm on October 4, 2016 Permalink | Log in to Reply

        I don’t fully understand #12706, but it seems that at least part of the issue has to do with the way that statuses are exposed and used in the user-facing publication flow. The basics of what I’m proposing above (at least, the first 11 items) don’t expose anything to the user at all. And in any case, the publication workflow for terms – such as it currently exists – is pretty different from, and simpler than, the post workflow.

        That said, #12706 and related tickets may suggest that we should take a step back and consider what a “status” really is. In the case of posts, status plays a lot of roles, some of which are at odds with each other. (See: ‘future’ vs ‘private’.) Comment status is a bit clearer: it’s primarily about moderation status. User status is not really fleshed out in a meaningful way, and so doesn’t do much. It would be helpful to discuss what term status ought to be – and ought *not* to be – both at the outset and in the long run.

      • Aaron D. Campbell 8:17 pm on October 4, 2016 Permalink | Log in to Reply

        I honestly don’t think this will make that any harder to fix. It won’t make it any easier either, but I don’t think that really prevents this from happening.

        The big thing we need to avoid so we don’t make that particular issue worse, is hard coding any statuses (with the exception there being to hard code “publish” as the initial status to be used during the upgrade routine). When we ignore “private” statuses, we should make sure that a developer can decide whether a status is private or not, etc.

      • John James Jacoby 6:08 pm on October 5, 2016 Permalink | Log in to Reply

        What’s proposed here must happen, and I am in support of it.

        I do not think it’s best for WordPress core to start term statuses until post statuses are finished, and user statuses need untangling, too: #34316.

        I’d like to see this worked on outside of the constraints & pressure of core release cycles. If we have not figured post statuses out in 6 years, it’s unlikely that we will for terms in 6-9 weeks. The plugin-first approach seems to better highlight blockers in core, too.

    • John James Jacoby 6:29 pm on October 5, 2016 Permalink | Log in to Reply

      I have a plugin that also adds an order column to wp_term_taxonomy. Adding a status column is another step down a slippery slope of making taxonomy-term objects act like post objects, and still without a many-to-many relationship table between them.

      In #37686, I had proposed adding an object_type column to wp_term_relationships to allow terms to be shared between objects (posts, comments, users, etc…) — I think the same arguments against that there work against this here.

      You picked the most stable parts of the post-status API to build off of, the procedural bits, and that I think makes a lot of sense.

      It would be bad if someone got back an ‘auto-draft’ term for get_term_by( ‘name’, ‘foo’ ). We can explicitly blacklist ‘auto-draft’ terms

      I think parity with get_post/s() is more important. Arguably, if I was getting a term before, I still want it now, regardless of its status attribute. What happens if you try to get_post() an auto-draft, revision, or inherit, and what’s the history there?

      Performance will not take a hit so long as this new column is indexed.

      User impact with direct database queries should be infinitesimally small, and it’s likely only a small subset of those users that would be victimized by using this type of code naively.

      (Edited for code formatting improvements…)

    • Spacedmonkey 12:07 pm on October 7, 2016 Permalink | Log in to Reply

      I like this idea. Statuseso could be useful for a lot of things. scheduled terms right be really cool for example. Couple of points of feedback.

      I agree with above comment that we should be working towards a single apiece for statuses in wordpress. adding a new thing seems crazy at this point.

      If we are changing the database for this, is it worth thinking about adding an author as well. I know @jjj has a plugin for it. I know it has been an issue for me with sites with large editor team to backtrace bad categories and who created them.

      One thing you didn’t mention is what the api will look like for taxonomy queries. Will a new parameter be added that defaults to public.

      Two useful / related tickets

      Ticket for using taxomony query for menu items.

      Ticket for using get terms for the internals ofor tax query. This would make the api mUchiha simpler and cached

  • Mike Schroder 10:51 pm on October 3, 2016 Permalink |
    Tags: , ,   

    Media Weekly Update (Sept 30) 

    This post serves to jump-start discussion before the weekly check in, which takes place in #core-images on Slack. The next meeting is Friday, October 7 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, September 30 at 17:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

    Attendees: @joemcgill, @mikeschroder, @swissspidy, @flixos90, @azaozz

    • Unexpected change to media title behavior in WP 4.6.1 (#37989)@joemcgill noted that @sergey found a fix for the remaining UTF-8 issues and it has been committed to trunk, but needs to be backported still. @joemcgill working on getting this done. Test please!
    • Downscale to only smaller images with srcset (#36477) – It looks like a true fix is not likely to land in 4.7, since this would have likely been part of changing the way WordPress handles full size images. @mikeschroder and @joemcgill to test the current patch for performance and SSIM.
    • Better PDF thumbnails (#31050)@markoheijnen was not able to attend, but previously noted that he is continuing work on this for a week or two to try to make 4.7.
    • WordPress image’s title is not alt (#34635)@joemcgill chatted with the Accessibility team about this, and the suggestion is that WordPress should no longer guess at an appropriate alt if the user hasn’t explicitly added one. He notes that this shouldn’t be that difficult to patch, but the change will need to be well communicated.
    • image_send_to_editor filter is not fired when an Image is edited or replaced in TinyMCE (#34823) – Based on @adamsilverstein‘s feedback, it looks like the ticket should be closed, as there’s a different filter intended for this purpose.
    • Usage of image_size_names_choose breaks JS attachment model attributes (#34981) – Chatted about a bit of background. @azaozz took a look and posted a new patch for review.
    • Sanitize accents in attachment filenames (#22363) – From @gitlost’s comments, it looks like there are fixes in remove_accents() necessary that should happen first, and would likely fix the base bug here. His work on it is mostly in #24661. @mikeschroder to dig into the progress of Safari’s support of these filenames. Feedback from those who have strong knowledge in UTF/character encodings would be appreciated.
    • Rotate Full Size Images on Upload (#14459 and #37140) – Would rather not destroy EXIF/IPTC in full size images (with GD), so may be better to fix this in Imagick first. Needs performance testing. Comment left on ticket.
    • Add new core media widget (#32417) – No updates here. May not be 4.7 at this point, but @joemcgill reaching out to @designsimply for status.
    • Media organization improvements:
      • Make media library searchable by filename (#22744) – @joemcgill added a patch to fix a JOIN issue found by @flixos90. Please continue testing this, especially with large media libraries.
      • @flixos90 opened a GitHub repo to work on media taxonomies/UI, and is organizing a feature project around it. @joemcgill suggests an initial meeting with @karmatosed for high level direction, followed by changes in the plugin, or core directly where appropriate.

    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-images channel.

    • simonrcodrington 10:44 am on October 4, 2016 Permalink | Log in to Reply

      Hey there Mike. Thanks for the update.

      I usually can’t make it to the slack meetings (they end up being really early where I am), but I’ve been meaning to push forward my ticket for inclusion into core: https://core.trac.wordpress.org/ticket/37535

      Basically, when you register a post type you can include the `description`. That description is never used anywhere by default. My idea was to output it right at the top of the post type listing admin page (where all your posts are displayed). The usefulness would be the description would be displayed in a practical place, with very few changes required.

      I’d be pretty keen to discuss this / put forward a pull request with how it would all work.


  • Nick Halsey 7:00 pm on October 3, 2016 Permalink |
    Tags: , , , , ,   

    Feature Proposal: A New Experience for Discovering, Installing, and Previewing Themes in the Customizer 

    This is the feature merge proposal for the new themes experience in the customizer introduced with #37661. Here’s an overview of the current proposed UI:

    Customizer themes design and user flow mockup

    Customizer themes design and user flow mockup by @folletto.

    A theme is the most fundamental aspect of customizing a site. This project seeks to unify the theme-browsing and theme-customization experiences by introducing a comprehensive theme browser and installer directly in the customizer.

    Walkthrough of the latest patch on #37661.

    Walkthrough of the latest patch on #37661.

    Background & History

    The customizer originated as a tool for previewing and customizing themes and as such, was closely integrated into the theme browsing experience in wp-admin when it was introduced in WordPress 3.4. The theme browser and installer were rewritten in WordPress 3.8 and 3.9, respectively, offering a fast JavaScript-based way to explore, install, and switch themes.

    Eventually, as the customizer’s role grew to that of a framework for live-previewing any change to a site, it became apparent that it would benefit from a more direct way to switch themes, without entering the wp-admin context. The Customizer Theme Switcher plugin was created, and after some refinement, merged into WordPress 4.2. However, while it initially included external links to install themes in the admin, these were eventually removed due to the jarring experience of unexpectedly leaving the customizer.

    Currently, there is no indication that additional themes can be installed when viewing available themes in the customizer. For new users, it may take quite a bit of time to discover the ability to install themes, via wp-admin, or they may give up on WordPress before making this discovery. This is a usability dead-end where a user’s flow is disrupted in the process of discovering, installing, previewing, and activating themes, both on initial site setup and when considering a redesign.

    When the theme switcher plugin was developed, the team made preliminary plans for a theme installation interface as a second phase of the project. Specifically, it would leave the “preview” context of the customizer but retain the same identity in the user experience. @folletto helped develop this initial concept in early 2015.

    Technical Constraints & Requirements

    There have been several technical limitations preventing theme installation in the customizer from being addressed previously. Most notably, such an interface requires “shiny” ajax-based theme installation, updates, and deletion, so that the user flow can persistently stay in the customizer themes interface rather than jumping to separate “installing” views. This is now possible with phase 2 of “Shiny Updates” in WordPress 4.6. Additionally, expansions of the customizer JavaScript and JS-templated controls APIs to better support dynamically-registered controls were needed to support theme installation within the customizer framework, and these were fully fleshed out for the customizer menus interface introduced in WordPress 4.3. With these technical constraints eliminated, theme installation in the customizer is now possible without additional significant improvements to the underlying themes or customizer APIs.

    The customizer must currently be completely reloaded from PHP to preview a different theme. To perform a theme switch without a reload, theme-defined settings, sections, and controls would need to be updated dynamically with JavaScript. While the customizer internals have been working toward making this possible for some time, significant work remains to make inline theme switches possible. Therefore, changes to this part of the theme-switching workflow are out of scope for the current project, which focuses on the user-facing flow.

    The biggest usability block that this limitation causes is that unsaved changes are lost when the theme is switched. Unsaved changes are currently handled by prompting users with an are-you-sure notice in the browser before making the switch. Unfortunately, limitations in JavaScript require the loading indicator to be hidden after the user decides to stay on the page or to continue to the new theme, causing confusion. In the new interface, this is further mitigated by displaying a warning that there are unsaved changes, with an inline button to save and publish them, at the top of the interface. With customize changesets (transactions) (#)30937, a “save draft” option could also become possible in the future, allowing changes to be saved (potentially automatically) without being published between theme previews.

    Previewing Themes

    One of the biggest challenges with theme installation in wp-admin, and opportunities in the customizer, is previewing themes. Currently, a customizer-like frame displays a preview hosted on WordPress.org, with limited content. Rather than opening this potentially-disorienting similar but different interface, the proposed flow de-emphasizes the distinction between installed and available themes. The primary action for available themes is now “Install & Preview”, which installs the theme and live previews it in one step.

    Users can now see any theme on their site with their content and play with its options in the customizer in one click. If they decide it’s the wrong theme for their site, the themes panel can be quickly reopened and another theme selected and previewed with no harm done. A secondary action allows themes to be installed without instantly previewing, so that the installed themes tab can become a personal theme library of sorts, where users can save themes that they might want to try on their site. Installed themes being a filter along with the available theme headings unifies the previously-disorienting separation of themes and add-new themes on separate screens, with confusingly-separate search and header (add new/upload theme) functionality.

    Proposed Themes Interface

    Due to the tight integration with the existing system, with the existing theme control and section as well as internal elements in the customizer manager and theme details template requiring moderate modifications, this project was implemented as a patch and cannot be reasonably converted into a plugin and back. The patch has been available on trac for six+ weeks, with iterations continuing to improve and polish the new experience.

    The technical implementation continues adapting the concepts present in the backbone.js-based themes experience in wp-admin to leverage the customizer API. With the themes experience natively built on the customizer framework, it should be much easier for developers to improve and maintain the core experience in the future as well as extending the core experience in a structured way.

    A few highlights of the proposed details:

    • Installed themes are no longer loaded every time the customizer is opened, resulting in potentially significant performance improvements by only calling wp_prepare_themes_for_js() when needed. This also allows themes in the customizer to be fully disabled with remove_panel( 'themes' ).
    • The themes experience is unchanged on the top level of the customizer, but selecting the change theme button now opens a panel that fills the entire screen, as the preview is not relevant when considering a theme change.
    • The UI diverges somewhat from what is found in the theme installer in wp-admin (which will remain), particularly around the filters.
    • The theme details view is unified between installed and available themes; clicking on a screenshot opens the details view to match the admin UI.
    • Primary buttons are used where clicking them takes you away from the current page (ie, for previews); secondary buttons are used elsewhere.
    • The loading strategy attempts to balance performance with wait time by loading theme data from Ajax in large batches (100 themes) and following up by rendering screenshots as they become visible (as the existing interface does).

    Usability Testing

    Four usability tests have been conducted so far. The full test screencasts are available on Make/Design, alongside key takeaways. These tests expose a lot of largely-known issues with themes and the customizer in general, but did not reveal any significant issues with the proposed new theme browser. Because the tests were conducted in-person with a limited set of volunteers, additional testing with a broader user base would be ideal.

    There has been design feedback since the user testing was conducted, resulting in some significant changes. @karmatosed has volunteered to coordinate additional testing in the next week to verify that the changes haven’t introduced usability regressions, and to test with a broader audience. Check out the call for user testing on make/design to help out here.

    A visual record on a phone of the revised design has been posted on make/flow.


    Because the new interface is built entirely on the customizer API, third-party plugins should now be able to integrate much more easily. This means that other theme marketplaces (including commercial themes) could realistically be browsed (and maybe even installed) from within WordPress, while leveraging the core UI exactly.

    The presentational flexibility is available via the customizer API (with custom theme sections for other theme sources, and theme controls for individual themes), but there are likely some gaps in the ability to do this seamlessly in the internals. If anyone is interested in building this sort of functionality, please evaluate whether any additional hooks are needed so that they can launch alongside the new feature.

    Review and Approval

    In addition to a general core approval of this proposal, the following sign-offs are required before the feature could be approved for merge, based on the applicable elements of this list:

    • Flow (and mobile) review (see also an initial post)
    • Docs review
    • Security audit
    • Polyglots/i18n review
    • Design/UX review – tentative approval has been provided from @karmatosed and @folletto (with additional input from others in last week’s design meeting) with an expectation that minor adjustments will continue to be required. General design feedback is still welcome, but major changes are unlikely to be feasible at this point.
    • Accessibility review – @afercia completed an initial review, with the issues fixed in a subsequent patch. A comprehensive final review would be a good idea as well, since there have been significant design changes.
    • Code review – to be handled by @westonruter once the patch is otherwise deemed “ready” based on review from other teams.

    To test, update to latest trunk and apply the latest patch on #37661. On your test site, open the customizer and “change” the theme. Try out the various filters, browse themes, and install and preview them. Also test the inline update and deletion functionality.

    To meet the feature merge deadline for 4.7 (10/19), reviews from various teams and any corresponding iterations need to be completed by October 12th, leaving a week for final code review and commit. General feedback and specific reviews and action items should be provided as comments on this post.

  • John Blackbourn 6:04 pm on October 3, 2016 Permalink |
    Tags: ,   

    Feature Project Proposal: Notifications API 

    Most of the situations where WordPress sends an outgoing email can be classified as a notification. X just happened on your website and you should be aware of it.

    Back when WordPress was a youngster, the only way to reliably notify a user was via email. In 2016 we have many more options, including push notifications to mobile platforms, desktop notifications to browsers, messages to chat apps, endless services via webhooks, SMS messages, or even notifications in the WordPress admin area. The list goes on. For many users, email is no longer the optimal delivery mechanism for ephemeral notifications.

    To that end, let’s think about replacing wp_mail() with a modern API that allows developers to route notifications to services other than email, allow them to better modify notifications and the way in which they’re formatted, and allow them to do so without stepping on each others’ toes.

    The current lack of a notifications API (or even an email sending API) can be easily summed up:

    Problem: Plugin A wants to provide HTML emails, and Plugin B wants to send emails via an email delivery service such as Mandrill. Plugin C wants to disregard emails and send Slack notifications. It’s very difficult for these to co-exist.

    Notification Destinations

    There are only two types of destination for a notification in WordPress. Most notifications are actually notifications to a user account that get delivered via email because it’s the only contact information available for every user account. The remaining notifications are explicitly notifications to an email address rather than a user account (or not yet attached to a user account), such as when a user signs up for a blog and needs to click a confirmation link before their user account gets created.

    With this in mind, you might be able to imagine a notification class in WordPress core that defaults to delivering notifications via email, but which can be extended by a plugin on a per-user and per-notification basis to deliver notifications via any of the means listed above. WordPress core would support delivery via email and provide the API that allows plugins to implement delivery via other means.

    With a well-designed API, multiple plugins can co-exist in order to deliver different notifications via different mechanisms, format email notifications as HTML, easily disable notifications, change the delivery mechanism for email notifications, or provide a UI for users to manage their notification preferences and destinations.

    Planning a Notifications API

    I’d like to begin work on a feature project with the intent of designing and implementing such an API. I’d like to get input from authors of existing plugins that provide functionality such as delivering notifications via a service other than email, that override the default email delivery mechanism, or that implement extra notifications (such as e-commerce sale notifications), in order that the API can be backwards compatible and that we can get some plugin implementations built during the API’s development.

    I already have some technical ideas regarding how the API might look, but I’m conscious that such an API needs to be well-designed before anyone jumps into writing code. Maybe we can even try some test-driven development? Who knows.

    In addition, consultation and involvement with the team that are working on the two-factor authentication feature project is important as it implements several delivery mechanisms for 2FA codes that could potentially be made simpler with a notifications API.

    Get Involved

    Feedback is most welcome in the comments. Would you like to help out? Yes? Great. Let’s plan a date and time for a meeting in Slack and go from there.

    Finally, a reminder that feature projects are not tied to a specific release of WordPress. This won’t make 4.7. It would be great if it was mature enough for 4.8, but we won’t be aiming for a particular release just yet.

    • lkraav 6:41 pm on October 3, 2016 Permalink | Log in to Reply

      I remember Stream just now working their Notification API full steam. Learnings and stuff available?


    • Greg Ross 6:56 pm on October 3, 2016 Permalink | Log in to Reply

      I think notifications need to be thought of more holistically, it’s not just about fire and forget, there should be a notifications center and the ability to view the history of your notifications.

      It could also look at the admin notices that get displayed so that they have somewhere to live that isn’t the top of every admin page 🙂

    • Mike Schinkel 6:59 pm on October 3, 2016 Permalink | Log in to Reply

      Yes. Please!

      Are you envisioning Notification Destinations to include message queuing too, or no?

    • Chad Butler 7:02 pm on October 3, 2016 Permalink | Log in to Reply

      I think it’s a great idea, John. However, where you said “let’s think about replacing wp_mail()” I assume (hope) you mean “let’s think about replacing the use of wp_mail() for notifications.” wp_mail() is quite ubiquitous throughout the plugin universe. Replacement would have repercussions, unless of course wp_mail() were to be updated to use the new API. Maybe I’m reading it wrong, but just throwing that in if I’m not.

      • John Blackbourn 9:00 pm on October 3, 2016 Permalink | Log in to Reply

        `wp_mail()` would be updated so it becomes a wrapper for the notifications API. Core may stop using `wp_mail()` but its functionality would of course remain.

        • Stephen Harris 12:47 pm on October 4, 2016 Permalink | Log in to Reply

          Hi @johnbillion,

          I think I’ve already said I’d be interested in helping out in the past – if not, consider this registering my interest ;).

          One point of concern though: would `wp_mail()` be a wrapper for the notification API? Or would the notification API (if/when configured to do so) make use of `wp_mail()`? I ask, because the purpose of `wp_mail()` is very much tied to it’s means of delivery. There will be instances where plug-ins are using `wp_mail()`, when an alternative means of transport is not appropriate or not possible.

          This really boils down to who has final say on the means of transport, and in particular whether `wp_mail()` will continue to only trigger e-mails – you hint as much in your reply to Chad. I dare say this is will get thrashed out in the details, but something to keep in mind.

          On a related note, I’ve a long-standing, and now out-dated patch for how WordPress handles emails, and it would be great to see a greater degree of flexibility: https://core.trac.wordpress.org/ticket/29513

    • Henry Wright 7:07 pm on October 3, 2016 Permalink | Log in to Reply

      I have been hoping for something like this for some time https://wordpress.org/ideas/topic/notifications-api

    • Pascal Birchler 7:39 pm on October 3, 2016 Permalink | Log in to Reply

      I have expressed my interest in this in the past and I’d love to help shape such an API.

      As mentioned in other comments, it should be possible to queue notifications, e.g. by storing them in the database until delivered. One particular use case I’m talking about is when you want to send 1 weekly digest email instead of an email for every event. See https://wordpress.org/plugins/digest/.

    • J.D. Grimes 7:42 pm on October 3, 2016 Permalink | Log in to Reply

      I have seen this idea brought up before, and I’ve been hoping that someone would pick it up. I’ll try to contribute as I have time (which sometimes won’t be much).

      I would like to point out that your example seems to me to be a bit wrong-headed, but perhaps I am interpreting it incorrectly. The impression I get is that there would be several different classes, and plugins would choose to use whichever class they wanted based on the type of notification they want to send. In other words, this would be hard-coded. I think that this is missing a huge opportunity for giving users the option (via plugins built for that purpose) to switch from one form of notifications to another. So if I have a plugin that usually sends me emails, but I want to change that to Slack notifications instead, I should be able to do that very easily just by filtering the delivery method. Perhaps this was part of the idea, but if so it wasn’t clear to me.

      • John Blackbourn 9:05 pm on October 3, 2016 Permalink | Log in to Reply

        The aim is to build a base API that also provides an email delivery mechanism by default, and which allows plugin authors to implement delivery mechanisms for any service they desire, such as Slack. It would then be up to individual plugins to determine when to override an email with a Slack message, or this logic could be provided by a standalone plugin that includes a UI for users to choose their notification preferences.

      • FolioVision 10:32 pm on October 4, 2016 Permalink | Log in to Reply

        John, a notification API is a fabulous idea whose time has come. Thank you. On the other hand, I wholly agree with J.D. that control of where the notifications go should be in the hands of users, not plugin owners. User control of destination is very, very important to making a notifications as useful as it could be. Probably the very core of the improvement.

    • Mark Wilkinson 7:55 pm on October 3, 2016 Permalink | Log in to Reply

      This is a great idea and something I would love to see in WordPress. I am also a +1 for being able to queue notifications to. I would love to help where, how and when I can.

    • Luke Cavanagh 8:14 pm on October 3, 2016 Permalink | Log in to Reply

      This is a really awesome idea.

    • Josh Pollock 8:31 pm on October 3, 2016 Permalink | Log in to Reply

      This is a great idea. I’d love to help on this. Seriously DM me (Shelob9 in Slack) when you’re ready to get started.

      In my plugin Caldera Forms, I built infrastructure for alternative delivery of email notifications. We have only implimented it for SendGrid so far, but will be adding support for other services soon.

      The code for that is here:

      Beacuse altering wp_mail() for one specific type of email is a giant pain/impossible, this system prevents sending to wp_mail() when used. Totally the kind of thing a core notifications API would be helpful for.

    • Adam Silverstein 9:08 pm on October 3, 2016 Permalink | Log in to Reply

      Exciting! I am looking forward to working on it!

    • Paul Wilde 9:26 pm on October 3, 2016 Permalink | Log in to Reply

      Laravel recently implemented support for Notifications in their latest release:

      There is also a resource available to download other packages for different services other than the built-in ones:

      Laravel is obviously more mature in terms of PHP version and code-style, but there may be a few ideas of inspiration to look at.

    • Anh Tran 3:50 am on October 4, 2016 Permalink | Log in to Reply

      This is a good idea. I’d love to have a notification hub for all events fired in the system and defined by developers. Each event can have several phases that developers can hook into to do something. Also a list of supported notification media (desktop notification, email, sms, push notifications) should be provided (or easy to be included).

      This is a game changer for the system and all plugins (like e-commerce ones).

    • Russell Heimlich 4:50 am on October 4, 2016 Permalink | Log in to Reply

      I think this would be an awesome plugin and I’m all for improving `wp_mail()` to add more hooks to make it more flexible. I don’t think a notifications API should be part of core. A message sent via email is different from a message sent to Slack. I don’t think it is as easy to say all my notifications should go to Slack. There is a lot of nuance which gets complicated. Would WordPress have an option as part of core to enable Slack notifications? Functionality that relies on 3rd party APIs sounds like a burden to have to maintain in core and is better suited as a plugin so updates can be distributed more quickly instead of pushing a point release to the millions of sites running WordPress that may or may not make use of the notification channel.

      Remember when core had a list of default IM fields in the user profile? That feature was removed (https://core.trac.wordpress.org/ticket/11541) because it was decided that they couldn’t cater to everyone. @dd32 sums it up nicely
      > In my opinion, All IM fields should be striped from core. Its impossible to cater for everyone, whilst not over-doing it.
      > Every culture group and country prefer different networks, in the past, there were a limited selection so it was fine, Today, You might as well include FaceBook, Myspace, Orkut, Tagged, Bebo, Windows Live Spaces (different from MSN AFAIK?)

      I’m curious to see what comes of a feature plugin and how it might handle the issue of trying to be all things to all people. But I still don’t think it is core functionality.

      • John Blackbourn 8:17 am on October 4, 2016 Permalink | Log in to Reply

        This proposal is about building an API that allows plugins to implement any number of destinations. Core will only implement support for email.

        With this in mind, you might be able to imagine a notification class in WordPress core that defaults to delivering notifications via email, but which can be extended by a plugin on a per-user and per-notification basis to deliver notifications via any of the means listed above.

    • Ahmad Awais 6:54 am on October 4, 2016 Permalink | Log in to Reply

      Yes! Yes! THIS! 💯
      Would love to contribute! BTW nice read.

    • Paul Gibbs 8:23 am on October 4, 2016 Permalink | Log in to Reply

      Hi @johnbillion. Thanks for getting this posted; I’ve enjoyed talking with you about it previously about how BuddyPress would make use of this if it were well-architected. I’m not prepared to commit any time at this point until your techinical roadmap/architecture plans are posted, though I understand you are probably wanting unbiased approaches from others to test your implementation ideas against. Please keep communicating frequently and often, and I’ll stick my head in when things have moved on a bit.

    • Florian TIAR 8:31 am on October 4, 2016 Permalink | Log in to Reply

      This is a nice project

    • Stefan Kremer (stk_jj) 10:38 am on October 4, 2016 Permalink | Log in to Reply

      Like the idea very, very much. Already asked the core contributors in there session @ WordCamp Nuremberg about such an development. Would be a huge achievement for admins running multiple WP instances getting notifications not by mail, but forwarded to logstash/ELK-stack, graylog, … or any other logging plattform.

    • Daniele Scasciafratte 5:43 pm on October 4, 2016 Permalink | Log in to Reply

      My question is what mean Notification?
      Today there are many way to receive a notification.
      As example I love the emails like https://lwn.net/SubscriberLink/702177/e2712c9c41c0c683/ but for the user of the website maybe it’s better to have the notification in the browser using the push notification and the html5 notification API.
      As example https://wordpress.org/plugins/web-push/ this add the notification for the user with a push notification server using the notification api of the browser in pure html5 and easy to extend https://github.com/WPBP/WordPress-Plugin-Boilerplate-Powered/blob/master/plugin-name/admin/includes/PN_Extras.php#L191 for custom notification.

    • Dennis Ploetner 9:32 am on October 5, 2016 Permalink | Log in to Reply

      That’s very interesting! I would love to help here. Let’s talk about that at #wcmil, John.

    • mattyrob 1:26 pm on October 5, 2016 Permalink | Log in to Reply

      `wp_mail()` is long overdue some attention IMO. Simply the fact that is can’t currently handle Alternative Body emails with HTML and Plaintext parts is an obvious area for improvement.

      This project has the potential to bring email functionality up to date and also allow plugins to extend notifications in new and alternative directions – I’ll happily input when my time allows.

    • tristanfaganguimond 2:16 pm on October 5, 2016 Permalink | Log in to Reply

      This would be an excellent addition.

    • Steven Word 8:20 pm on October 5, 2016 Permalink | Log in to Reply

      +1 On the consideration for 2FA. There were some big concerns brought up during the 2FA discussion roundtable at the Community Summit in 2015 that may be alleviated with a Notifications API.

    • markcallen 10:34 am on October 12, 2016 Permalink | Log in to Reply

      I’m not sure a full API is required.

      I’ve brought this up recently in this ticket – https://core.trac.wordpress.org/ticket/38028.

      Notifications are almost the very definition of an ‘action’. Hooking actions is what WordPress is great at. As developers we can add as many as we like for as many services, notification types as we want. It’s backwards compatible and can fallback to wp_mail if necessary.

  • Aaron Jorbin 4:31 am on October 3, 2016 Permalink |
    Tags: ,   

    Bug Scrubs for the week of October 3 

    There are a few upcoming bug scrubs in addition to the regular component ones that you should plan on attending. Both of these scrubs will be taking place in the #core slack room.

    There are only 3 weeks remaining until the first beta for 4.7. To hit this target, there must be no remaining enhancements or feature requests. As of today, there are 72 open tickets that must be closed or punted before October 26.

    Want to run a bug scrub? Learn about running your own.

  • Nick Halsey 1:27 am on October 3, 2016 Permalink |
    Tags: ,   

    Customize Update 2016-10-02 

    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.

    Weekly Customize Meeting Summary

    On Monday we held our weekly 4.7 customize component meeting in #core-customize on Slack [logs]. Participants: @celloexpressions, @voldemortensen, @westonruter, @karmatosed, @folletto, @aaroncampbell. This summary also contains a few notes on action since the meeting.

    4.7 Projects

    • Customize changesets (transactions) – #30937 – @westonruter
      • @westonruter has completed an initial patch, merging previous work with major updates
      • Transactions are now known as “changesets”, with a customize_changeset post type and customize_changeset_uuid query param.
      • @aaroncampbell is interested in helping here.
      • Please apply the patch from the GitHub pull request and test for any regressions and that it fixes the myriad of issues that it is supposed to fix: grunt patch:https://github.com/xwp/wordpress-develop/pull/161
      • Latest patch improves theme preview experience so that pending changes made during a theme preview aren’t lost when switching to another theme (see #36485).
    • Create pages within live preview during site setup – #37914#37915, #37916, #38002, #38013, #38164 – @celloexpressions
      • #38164 has been created for creating pages from the static front page section. This functionality can be extracted from the customize posts plugin, but we need design ideas here.
      • We still need UX feedback on providing a path to edit newly-created pages, #38002.
      • @westonruter punted #37916 to a future release.
    • A new experience for themes in the customizer – #37661 –@celloexpressions
      • There was a special meeting to iterate on the design approach, and @folletto and @karmatosed agreed on a new design that was implemented in a revised patch at the end of the week.
      • A feature proposal is ready to be published on make/core pending final review.
      • The revised mobile flow was posted in a visual record on make/flow.
      • The deadline for feedback from other teams is October 12th, leaving a week for final code review and commit.
    • Code-editing gateways, via CSS – #35395 – @johnregan3
      • This was discussed at length during the core dev chat. The consensus was that the feature is appropriate for core as proposed (pending approval of the formal proposal).
      • For security, because there is limited-to-no ability to actually sanitize CSS, a new meta capability, unfiltered_css, will be introduced. By default, this will map to unfiltered_html, but plugins can change this as needed, for example on multisite, where site admins don’t have unfiltered_html and custom CSS is particularly useful.
      • Neither CSSTidy nor CodeMirror will be used for now, as CSSTidy doesn’t actually provide CSS sanitization, and CodeMirror is a nice-to-have for syntax highlighting. There will be some primitive validation that provides user feedback for common syntax errors.
      • @folletto has volunteered to assist with the design/UX aspects here, taking inspiration from the similar feature on WordPress.com.
      • We’re schedule to post a feature proposal next week, and need to complete an updated patch soon to make 4.7.
    • Customizer browser history#28536 – @westonruter
      • Parts of this might be blocked by changesets (transactions), which is higher priority for now.
      • If it’s okay with @helen, we may want to pursue this in the week before beta, after the major feature deadline, since it’s a smaller feature.
      • During customizer themes user testing, this came up as expected behavior.
    • Improving sliding panels UI – #34391, #34343, #29158 – @delawski
      • An initial commit is in trunk, dev note published, and only a few minor bugs have come up so far.
      • #34343 is now in progress. @folletto pointed out that we might want to do #35186 instead, or in addition at some point.
      • #29158 needs design ideas for the back arrows and close button focus styles, with the possibility of eliminating the autofocusing of (pending accessibility feedback).
    • Twenty Seventeen
      • Tracking a couple of possible customizer-heavy features.

    Additional Tickets Needing Attention

    • Customizer notifications – #35210 – needs UX feedback and a patch
      • @westonruter will work on this after changesets (transactions) unless anyone else is willing to work on turning the latest proposal into a patch.
      • This ticket is holding up some of the other tickets on the 4.7 milestone, such as #22037 and #29932, as well as aspects of changesets (transactions).

    Ticket Scrub

    • #21627: Filter for custom-background CSS selector
      • Needs unit tests, looks like @peterwilsoncc is the best person to own this.
    • #30738: JS content templates for base WP_Customize_Control
      • Not critical for 4.7, but there is code in customize posts that could be adapted for this.
    • #33085: Customizer: controls description inside labels are not real labels nor descriptions
      • This is fixed with the code for #30738.
    • #37269: Introduce removed event for wp.customize.Values collection
      • Punted pending a (good-first) patch.
    • #36582: Export main query from Customizer preview
      • Punted, as it can be implemented in plugins such as customize posts for now.
    • #22857: ‘Header Image’ state isn’t removed from images previously used as header image
      • This may be more appropriate under the media component based on the direction it’s taking.
    • #38080: Focusing a customizer control from the preview should show the controls on mobile
      • Patch should be too difficults, this is a follow up to another change in 4.7, although there is no UI exposed for this functionality on mobile currently.

    Recent Customize Commits

    Here are the customize-related commits for the past week:

    • [38648]: Customize: Re-architect and harden panel/section UI logic.
    • [38649]: Customize: Opt to disable IE8 support via conditional comments instead of unreliable feature detection.
    • [38668]: Customize: Fix focusing on controls for widgets and nav menu items after [38648].

    Big thanks to those who contributed to patches committed this week: @westonruter, @delawski, @celloexpressions, @ryankienstra.

    We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved. Fun fact: we’re 7 commits away from the 1000th commit that references customize.

    Agenda for 2016-10-03 Meeting

    Our next regularly-scheduled meeting is Monday, October 3rd, 17:00 UTC. Agenda:

    4.7 Projects

    Additional Tickets Needing Attention

    • Customizer notifications – #35210 – needs UX feedback and a patch
    • Customizer UI Contrast/Focus Styles – #29158 – needs UI ideas for focus styles on back buttons

    Ticket Scrub

    • 4.7 Customize non-bugs without owners. We’ll assign these all to an owner or punt to a future release. Beta 1 is three weeks away.
    • We’ll pick a different query to triage each week. For example, bugs awaiting review (need verification).

    We’ll see you next week!

  • Joe Hoyle 5:33 pm on October 1, 2016 Permalink |
    Tags: , ,   

    WordPress REST API – 2.0 Beta 14 

    Hey folks! I’m excited to announce the release of Beta 14 of the REST API. It’s been a while since our last release, beta 14 is jam packed with general improvements, bug fixes and general refinement to polish the feature plugin before core merge.

    Get it at WordPress.org or GitHub. View all changes on GitHub; here are the highlights:

    • Add support for password protected posts. There is now a protected attribute in the content and excerpt fields in post response. To view password protected posts via the API, use the password query parameter to provide the post’s password.
    • Allow returning an error from field update callbacks.
      Simply have your update_callback return a WP_Error.
    • Add relevance orderby to posts endpoint
    • Ability to order by slug, email and url on the users endpoints.
    • Add sticky parameter to the posts endpoint.
    • Update the wp-api.js client from the client-js repo.
    • Many many more

    Thanks to all the contributors and special thanks to @chopinbach, @kadamwhite and @websupporter for their effort this release.

    We’ll be kicking Beta 15 which will be focused on meta support for posts, terms, comments and users as well as a brand new settings endpoint. These are currently in review awaiting feedback, check out the meta pull request and the settings pull request and let us know what you think.

    In addition we will be publishing a merge proposal for WordPress 4.7 this week, stay tuned!

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