WordPress.org

Make WordPress Core

Updates from March, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Grant Palin 9:09 pm on March 2, 2016 Permalink
    Tags: ,   

    Week in Core, Feb. 23-Mar 1 2016 

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

    • 128 commits
    • 52 contributors
    • 115 tickets created
    • 19 tickets reopened
    • 135 tickets closed

    Ticket numbers based on trac timeline for the period above.

    Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

    (More …)

     
  • Andrew Rockwell 4:51 pm on February 24, 2016 Permalink
    Tags: ,   

    Week in Core, Feb. 16-23 2016 

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

    • 131 commits
    • 82 contributors
    • 89 tickets created
    • 9 tickets reopened
    • 140 tickets closed

    Ticket numbers based on trac timeline for the period above.

    Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

    Code Changes

    Accessibility

    • Improve the color contrast ratio for the input placeholders. [36619] #35777
    • Remove title attributes from the Plugin details modal. [36618] #35111
    • Remove the revisions limit warning from the Publish box. [36612] #35029
    • Fix displaying of Universal time and Local time info on the General Settings screen. [36585] #35064
    • Improve color contrast updating any #999 gray used for text or icons to a darker gray. [36587] #35660
    • Accessibility: after [36000] conditionally print out the aria-describedby attribute on the Featured Image postbox. [36584] #35076
    • Accessibility: Reduce the WordPress shades of grey, Episode 2. [36582] #35783

    Administration

    • Replace the custom comment form with comment_form() and reduce number of links. [36595] #35888
    • Remove extra spaces between function names and brackets [36572] #16774, #34365
    • Remove slashes from search terms and use urldecode() in non-URL contexts. [36560] #35712

    Authentication

    • Allow users to log in using their email address. [36617] #9568

    Autosave

    • Do not strip slashes from the whole &_POST when doing autosaves. [36543] #35408

    Bootstrap/Load

    Build/Test Tools

    Comments

    • Rename $linea to $remote_source for clarity. Add remote_source to comment data, so it’s available to preprocess_comment and comment_post filters. Pass the original (unfiltered) response source to the filters too (as remote_source_original in comment data). [36661] #34141
    • Pass comment data to the comment_post filter. [36660] #34141
    • Look for wp_error when checking whether $wpdb->get_col_length() has failed. [36542] #10377
    • Refresh the Moderate Comment screen for a friendlier experience with email moderation actions. [36588] #34133

    Customize

    • Let WP_Customize_Selective_Refresh class be final to match manager and other component classes. [36624] #27355
    • Ensure dynamic_sidebar() finishes with removing the sidebar ID from the current_dynamic_sidebar_id_stack. [36623] #27355
    • Prevent dropping backslashes from input on general settings and settings for nav menus and some widgets. [36622] #35898
    • Fix and extend broken ajax unit tests to account for partials being skipped from rendering. [36650] #35914
    • Skip exporting partials to client and handling rendering requests if user can’t modify associated settings. [36643] #27355, #35914
    • Add visual feedback to reorder buttons. [36641] #35041
    • Contain “No image set/selected” in dashed border. [36639] #35826
    • Update unit test for WP_Customize_Nav_Menu_Item_Setting::value_as_wp_post_nav_menu_item() to account for slashing if user can’t unfiltered_html. [36610] #35869
    • Prevent PHP notice and JS error caused by widgets and nav menus components if user only has customize capability. [36611] #35895
    • Fix previewing and updating of nav menu items containing slashed/slashable characters. [36608] #35869
    • Fix “Loading…” message from persisting in panel title when user does not have manage_options cap to edit blogname. [36606] #35579
    • Add selective refresh framework with implementation for widgets and re-implementation for nav menus. [36586] #27355
    • Prevent consecutive refresh requests from preview from causing JS error. [36583] #27355, #35866
    • In nav menus show the location name instead of slug. [36573] #34755
    • Add missing test changes for [36573]. [36574] #34755
    • Autoprefixer for [36532]. [36548] #31195

    Docs

    • Correct $number type in number_format_i18n(). [36644] #35893
    • Update the type for $callback parameters to callable in DocBlocks for add_settings_section() and add_settings_field(). [36642] #35772
    • Improve documentation for WP_REST_Request to highlight a caveat of ArrayAccess when it comes to passing similar arguments for multiple request methods. [36636] #35799
    • Improve description of get_term() return value. [36634] #35919
    • Correct param types on some filters in wp_filter_comment(). [36626] #35908
    • WP_Meta_Query accepts ‘EXISTS’ or ‘NOT EXISTS’ for $compare. [36609] #35891
    • Fix two incorrect notations of the $show_admin_bar global to specify a boolean type, not WP_Admin_Bar. [36601] #35686
    • Add missing since and access tags to get_curies method and filter from r36533 [36593] #34729, #32246
    • Add an explanation for the dynamic portion of the {$taxonomy}_term_edit_form_top hook, introduced in [36526]. [36577] #32246
    • Add formatting to a changelog entry in the hook doc for the rest_dispatch_request filter. [36576] #32246
    • Remove a duplicate @static tag from the WP_Customize_Panel->instance_count property DocBlock. [36568] #32246

    Embeds

    • Only display an iframe when it was successfully loaded. This prevents showing a blank iframe by first checking if a message was successfully received from it. [36648] #35894
    • Make the click event handler work for dynamically added links. [36637] #35630
    • Load the default site icon from the wp-includes directory. [36635] #35322

    External Libraries

    • Update Backbone and Underscore to the latest versions. [36546] #34350

    Feeds

    Formatting

    • Avoid a PHP warning when wptexturize() is called with a trailing less-than symbol. [36578] #35864

    Help/About

    HTTP API

    • Certificate bundle: Attempt to move a certificate lower in the file to allow older OpenSSL versions to parse it & communicate with WordPress.org securely again. The OpenSSL version which was failing in this case was OpenSSL 0.9.8e 23 Feb 2007. [36570] #35637, #30434, #25007

    I18N

    • Add translator comments and context to “New Site Created” email notification strings. [36669] #35716
    • Replace hardcoded URL in a translatable string with a placeholder in wp-admin/upload.php. [36668] #35743
    • Add missing periods to two strings in wp-admin/network/sites.php [36664] #35720
    • Add translators comments to wp-admin/users.php. [36621] #35885
    • Remove HTML tags from translatable strings in wp-admin/plugins.php. [36662] #35679
    • Add the ability to parse a whole directory with add-textdomain.php. [36600] #35499
    • Remove PHP4 constructor from add-textdomain.php. [36599] #31982
    • Add test for wp_dropdown_languages(). [36631] #35294
    • Respect the coding standards when adding textdomains with add-textdomain.php. [36603] #21616
    • Remove tag from translatable string in wp-admin/includes/class-wp-filesystem-ssh2.php. [36670] #35741
    • Remove tag from translatable string in wp-admin/includes/class-wp-ms-sites-list-table.php. [36663] #35676
    • Remove tag from translatable string in wp-admin/theme-install.php. [36666] #35739
    • Remove tag from translatable string in wp-admin/options-general.php[36656] #35673
    • Remove tags from translatable strings in wp-admin/install.php. [36665] #35738
    • Remove tags from translatable strings in wp-admin/custom-header.php[36658] #35675
    • Remove tags from translatable strings in wp-admin/themes.php. [36657] #35745
    • Remove tag from translatable string in wp-admin/user-edit.php[36655] #35672
    • Remove tag from translatable string in wp-admin/import.php[36653] #35671

    Media

    Menus

    • Ensure backslashes are saved in menu item fields. [36613] #14134

    Multisite

    • Make view mode sticky for network users and sites list tables. [36562] #34365
    • Avoid a PHP Notice when saving a site address without a path. [36561] #35631

    Performance

    • In wp_upload_dir() do not cache error from wp_mkdir_p() when a directory cannot be created. Keep trying to create the dirs. This happens mostly in file upload context. [36628] #34359
    • Replace wp_upload_dir() with the new wp_get_upload_dir() in all cases where a file is not being uploaded. Deprecate _wp_upload_dir_baseurl(), and replace it with wp_get_upload_dir(). [36569] #34359
    • Reintroduce term meta unit test accidentally removed in [36566]. [36567]
    • More performance improvements to metadata lazyloading. [36566] #35816
    • Improve the performance of wp_upload_dir(): [36565] #34359

    Plugins

    Posts

    • Introduce get_post_types_by_support(). Similar to get_post_types(), this new function returns a list of post type names that support a specific feature. [36652] #34010
    • Non-trashed posts should take slug priority over trashed posts. [36607] #11863

    Query

    • Search should match post_excerpt in addition to title and content. When ordering search results, exact matches in the post excerpt are weighted above those in post content, but below those in the post title. [36647] #35762
    • Allow a seed value to be passed when using ‘rand’ $orderby. [36632] #35692
    • In WP::handle_404() introduce a filter pre_handle_404 to short-circuit default header status handling. [36629] #10722
    • is_*( $int ) should not falsely match strings starting with “$int”. [36625] #24674, #35902

    Revisions

    Schema

    Script Loader

    • Don’t parse $src if the current color scheme isn’t registered. [36591] #35882
    • Pass the media attribute as an argument to the style_loader_tag filter. [36592] #34765
    • Bail if WP_Styles::_css_href() returns an empty value. [36590] #35229
    • Make sure that inline styles for handles without a source are printed. [36550] #35229
    • JSHint for [36602]. [36605] #33301
    • Fix missing script output when the groups of dependencies are different. [36604] #35873
    • Introduce wp_add_inline_script(). [36633] #14853
    • Restore loading order for wp-admin: open-sans, dashicons, etc. [36551] #35229

    Styles

    • Clarify the allowed values for the $media parameter of wp_register_style()/wp_enqueue_style(). [36649] #35921

    Taxonomy

    • Make $taxonomy parameter optional in get_edit_term_link(). [36646] #35922
    • Allow get_terms() to fetch terms regardless of taxonomy. [36614] #35495
    • In get_terms(), assemble WHERE conditions in an array instead of concatenating. [36598] #35495
    • Add changelog entry for publicly_queryable argument in register_taxonomy(). [36564] #34491

    Template

    Themes

    TinyMCE

    Updates

    • Pass locales of all available languages to the themes/plugins update API. [36630] #34937

    Upgrade/Install

    • Prevent further actions if an update button is disabled. [36558] #35257
    • Add a hook to the end of the network’s Add New User form. [36556] #15389
    • Add a hook to the end of the Add Site form. [36555] #34739
    • Enhance the language of the “Success” message. [36553] #34897
    • Improve wording on the page for the database connection details. [36545] #26879
    • Use “Username” instead of “User Name”. [36544] #35850

    Users

    • Pass the array of user IDs being deleted to the delete_user_form action hook in two places. [36640] #35063
    • Introduce _wp_get_current_user() for improved backward compatibility. [36651] #19615

    Widgets

    • Avoid a PHP notice in is_dynamic_sidebar() is a sidebar is registered but does not yet have an index in the sidebars_widgets option. [36667] #35928

    Props

    Thanks to @dnewton,@joemcgill, @abiralneupane, @adamsilverstein, @afercia, @aidanlane, @Ankit, @apaliku, @atimmer, @azaozz, @barryceelen, @boonebgorges, @charlestonsw, @chris_dev, @ckoerner, @coffee2code, @coreymcollins, @danielbachhuber, @dd32, @Denis-de-Bernardy, @dlh, @DrewAPicture, @dshanske, @ericlewis, @ethitter, @flixos90, @GaryJ, @gitlost, @groovecoder, @Gupta, @hakre, @helen, @hlashbrooke, @iamntz, @igmoweb, @iseulde, @JamesDiGioia, @jdgrimes, @jeremyfelt, @JoeFusco, @joehoyle, @johnbillion, @jorbin, @K, @karmatosed, @kjbenk, @kovshenin, @lpawlik, @mayukojpn, @mdgl, @meitar, @melchoyce, @MikeHansenMe, @mikejolley, @mikeschroder, @netweb, @nicd, @ocean90, @pento, @prettyboymp, @ptahdunbar, @rachelbaker, @ramiy, @realloc, @ryan, @ryankienstra, @salcode, @sc0ttkclark, @sebastianpisula, @SergeyBiryukov, @stevegrunwell, @stevenkword, @swissspidy, @thewanderingbrit, @thisisit, @usermrpapa, @valendesigns, @vhomenko, @welcher, @westonruter, @williamsba1, and @wpsmith for their contributions! for their contributions!

     
  • Adam Silverstein 8:14 am on January 27, 2016 Permalink
    Tags:   

    Feature Plugin chat notes for Jan 26 

    Agenda

    • Review the feature plugins for status updates from leads
    • Open floor for feature plugin proposal

    Feature Plugin Updates

    • Background Image Cropper: @celloexpressions asked for feedback for the Background Image Cropper. Current thinking is this is better explored as a standard enhancement for core. See #32403.
    • Customizer: @westonruter left status on the blog post for the Customize Pane Resizer, Customize Device preview (along with @celloexpressions), Selective Refresh, and Transactions. Please comment there if you’re interested in helping out where needed (especially requested for the Pane Resizer).
    • Fields API: @sc0ttkclark updated: term add/edit is in: props @technosailor. Team has been working on simplifying the code required for each screen implementing the Fields API. Scott posted an update on make/core and reports getting lots of feedback (especially from @helen, @drew, @technosailor & @celloexpressions)
    • Shiny Updates:  @obenland updated – Lots of progress in the last week. @ipstenu helped tremendously in getting it multisite compliant. Team decided to not pursue shiny activations/deactivations for a whole set of reasons, mostly around redirects on subsequent page loads, and fatal error protection.
      Currently working on enabling theme updates without having to open the modal, and revamping update-core.php.  An update will be posted to the make/core blog soon. The team needs more feedback and testing! Testers can get the current plugin from the wordpress.org repository.
    • WP-API: @danielbachhuber updated – released beta 11 yesterday. The team is meeting in person (minus @rachelbaker) this week at A Day of REST. Summary: in the home stretch, but there’s a ton more work to do. Friday’s contributor day (at the Day of REST) will hopefully get other people diving in and contributing to the final push.

    Open Floor

    The full logs are available on Slack.

     
    • jrf 10:52 am on January 27, 2016 Permalink | Log in to Reply

      I’d love to continue the discussion on Plugin Dependency management within WP.
      We’d very much would like to invite everyone to give their opinion on the direction we’re thinking of taking though this survey: http://goo.gl/forms/Fq1gbY9vCW

      We’d really appreciate getting as many opinions as possible about this. Thanks!

      • Felix Arntz 11:50 am on January 27, 2016 Permalink | Log in to Reply

        I just took the survey, I have a few comments on the approach.

        I certainly like that multisite will be supported, this is definitely a requirement anyway. 🙂

        About the dependency management: although I personally would prefer a JSON file, I think the theme/plugin header way is more the WordPress way, and a lot easier. People new to WordPress and even to development should be encouraged to start creating plugins/themes – external libraries/library plugins make this a lot easier, but I’m afraid a JSON file is too complex. Maybe both methods should be supported: while only the JSON approach would support the full functionality of dependency management, the file header would still allow to at least require plugins listed on wordpress.org with a minimal version number (there’s not really room in there to do more complex things). If someone needs external plugins or something like that, that should only be possible using JSON.

        The other thing is, in my opinion the recommendations feature should not be part of the feature plugin. Standard dependency management does not handle recommendations either, and I think this goes into kind of an advertising direction which I wouldn’t like to have in WordPress Core.

        I’m looking forward to this project and I’m happy you make these efforts to create a feature plugin. I think the full power of this feature however could only be leveraged if the wordpress.org plugins API would be adjusted as well to contain dependency information as this would allow notifications prior to installing which I think is even more elegant than notifications before activating (also due to the problems that this would bring on multisite). Anyway, first things first! 🙂

    • Ryan Boren 3:33 pm on January 27, 2016 Permalink | Log in to Reply

      Beta testing is much easier when feature plugins are kept up-to-date in the plugin repo. This allows using the built-in WP update mechanism to follow development. Our beta testing onboarding, such as it is, relies on feature plugins being updated regularly.

      A survey of https://wordpress.org/plugins/browse/beta/ and https://make.wordpress.org/core/features-as-plugins/:

      • Background Image Cropper: Last updated one month ago in the plugin repo. The features as plugins entry is bare.
      • Customize pane resizer: This is listed in neither browse/beta nor features-as-plugins.
      • Customize Preview Responsiveness (aka Customize Device Preview): The Customizer UI Experiments plugin was last updated two months ago. This is called three different things.
      • Customize Partial/Selective refresh: The plugin hasn’t been updated for 6 months.
      • Customizer transactions: I don’t see this in browse/beta or features-as-plugins.
      • Fields API: This is not listed in browse/beta. Does it even exist in the plugin directory?
      • Shiny Updates: This is in browse/beta and kept up-to-date. As such, I’ve been testing it.
      • WP API: This is in browse/beta and kept up-to-date. It is pretty much the only feature plugin to post on make/core regularly and do calls for testing.

      Court beta audiences. Update plugins in the plugin dir, preferably nightly. Keep features-as-plugins up-to-date. Publish calls for testing to make/core. Here’s a call for testing template and checklist. http://simp.ly/publish/XrHJDL

    • Ryan Boren 8:04 pm on January 27, 2016 Permalink | Log in to Reply

      If you have the beta tester plugin, feature plugins can be installed from Plugins > Add New > Beta Testing. Details here: https://make.wordpress.org/core/handbook/testing/beta/

  • Ryan McCue 1:03 am on September 21, 2015 Permalink
    Tags: , , , ,   

    WP REST API: Merge Proposal 

    Hello everyone! This is the post you’ve all been waiting for. 🙂

    We on the REST API team (myself, @rachelbaker, @joehoyle, @danielbachhuber, and newest member and core committer @pento) would like to propose merging the REST API into WordPress core. We’ve been working a while on this, and think it’s now ready to get your feedback.

    This is our first iteration of the proposal, and we’re actively looking for feedback. If you have thoughts on the project, or on this proposal, let us know! Only with your feedback can we make progress. 🙂

    What is the REST API?

    The REST API is a nice and easy way to get at your data in WordPress externally, whether that’s from JavaScript in a theme or plugin, mobile and desktop applications, or importing and exporting data. The API offers up all core data types (posts, terms comments, and users), plus support for meta and revisions; we’ve got plans to eventually have access to everything the admin and frontend have access to.

    The REST API differs from existing WordPress APIs in that it is explicitly designed from the ground up for modern mobile and browser usage, using the lightweight and widely-supported JSON data serialization format with a modern REST interface. Both of these are already familiar to most developers: JSON is a subset of JavaScript intended purely as a data interchange format, and REST is a set of best practices around HTTP. Both are supported natively by almost every programming language and platform.

    Why do we need a new API?

    WordPress already has external APIs: XML-RPC, designed for desktop clients; Atom and RSS feeds, designed for post syndication; and the venerable admin-ajax, designed for Ajax requests in the admin and frontend. These APIs all serve different purposes, but often have a great deal of overlap. In addition, these have all been stretched beyond their original intentions: XML-RPC now contains site management tools, RSS has been extended into the WXR export format, and admin-ajax is the catch-all of any sort of browser-server communication in plugins and themes.

    The REST API builds upon the heritage of these APIs to provide better support today for using these, as well as laying the groundwork for expanded use in the future.

    XML-RPC is the closest analogue to the REST API in terms of usage and capabilities. Originally designed back in 1998 to allow desktop clients to create and edit posts on blogs, WordPress has extended this with both other specifications (such as MetaWeblog) and with its own proprietary additions. Fundamentally, XML-RPC is built around Remote Procedure Calls (RPC), essentially a way of calling a function externally. It then uses XML to serialize the data for passing back and forth.

    Unfortunately, XML serialization can be problematic at times. XML has lots of power, but support for custom entities and DOCTYPEs can cause parsing problems and security attacks, including billion laughs, and XXE exploits. (Currently, WordPress has to disable parts of the XML parser and apply regular expression replacements to be able to parse these safely.) XML is also very verbose, and represents data in a way which doesn’t map easily to programmatic data structures. JSON on the other hand is both concise and well-represented in memory, as it’s based on JavaScript’s native syntax.

    The admin-ajax API is also very commonly used in WordPress, albeit typically only by plugins and themes. This is a very lightweight API that essentially acts as a mini-router. Typical usage of this API uses JSON, since it’s a browser-based API, but all usage is completely custom. A lot of the usage of this involves retrieving or updating posts on-the-fly, but due to its nature as simply a framework, these are done in completely different ways. This doesn’t lead itself to extensibility, and requires a lot of duplication every time developers want to get data in or out. We don’t want to replace all of admin-ajax though, since some use cases don’t map exactly: UI-related interactions or things like the Heartbeat API are great examples of this.

    The REST API can help to supplant these uses. Our aim is to eventually replace the XML-RPC API completely, to act as a secondary import/export format, and to replace most (but not all) uses of admin-ajax. The REST API offers an easier to use interface than the existing solutions.

    Why this project?

    We’ve been working on this project ever since the first WordPress Contributor Summit back in 2012. Since then, we’ve had lots of feedback from core developers, the community at large, and further beyond in the form of client developers. We believe that the REST API has an immense amount of experience behind it, and plenty of viewpoints have contributed to the project’s direction.

    The API has seen great usage in the community, from various mobile apps to large news sites. This usage has helped to battle-test and prove out the API. In the process, we’ve found plenty of bugs, and some security issues. Thanks to this feedback, the API is incredibly stable and secure. (The most recent security bugs we fixed were relatively minor bugs.)

    We also designed the API from the ground-up to be part of core, following a core-like mentality to our processes. The API is intended to be both a great feature and a base to build off in plugins. We undertook a significant refactoring and partial rewrite in version 2 to make this extensibility even better. This open process also means that most of the design decisions are documented publicly as we’ve engaged stakeholders to gauge feedback.

    We believe these pieces combined make this a fantastic feature for WordPress core, and we hope you all agree. 🙂

    What’s the plan?

    The plan we’re aiming for is a two part merge of the API. For the first stage, the infrastructure code would be merged into wp-includes and made available for plugins and themes. This is an internal API only, but offers an “API construction kit” for developers to use. For the second stage, the endpoints would be merged, and the API would be enabled for sites by default.

    This plan splits the API into two parts, infrastructure and endpoints:

    • Stage One: Infrastructure: The infrastructure is the code responsible for routing requests and handling the “meta” layer of the API, including JSON serialisation/deserialisation, linking, embedding, and REST best practices. This adds a simplified routing layer outside of WP’s rewrites, allowing non-query-var rewrites easily, acting as a base for building APIs inside WordPress.
    • Stage Two: Endpoints: These are where much of the complexity of the API lies, as they’re responsible for mapping data from the external JSON format to the internal data structures, and vice versa. The “business” logic of integrating with WordPress is almost entirely contained within the endpoints. These are the more complex part of the API, as they require using deep APIs in WordPress, and handling security and privacy concerns.

    With this plan, we would aim to have the infrastructure merged in 4.4, and the endpoints merged one release later in 4.5.

    The slow nature of this plan allows a longer review time on the API for core committers. It also gives extra time for reviewing the endpoints, since they would be delayed one release.

    Merging the infrastructure now would allow third-party code to begin using the API to build upon it, including migrating from existing custom code. It would also help to increase developer confidence in the API (as it represents a commitment by the project towards a REST API).

    In this plan, the first stage would not include any of the base controllers (such as the posts controller). This may limit the utility of the infrastructure for plugins and themes, however as the endpoints would be merged a cycle later, it’s expected that this wouldn’t have a huge impact.

    The infrastructure of the API is approximately 2700 lines of code (roughly a third of the API codebase), and the endpoints make up the remaining 5500 lines of code.

    What would happen after merge?

    After merging the REST API into core, we’d spend approximately two weeks partying and celebrating. 🙂

    Once we’re done with the parties, one major question would be how we manage the API in the future. The existing management and contribution process via GitHub has been extremely successful, as we’ve had 61 people’s pull requests merged into the API. Contribution via GitHub is especially useful for the API, as it’s a heavily developer-focussed project, and is aimed at external (non-WordPress) developers. On the other hand, all other contribution to WordPress is done via SVN and Trac, so integrating with this process is important for existing developers, as well as core’s general processes. We need to ensure the API is an integral part of core, not a separate project.

    Given the team’s experience with GitHub as well as Trac, we can bring the best of both worlds by helping integrate the two. This would also improve contribution for WordPress as a whole, and benefit the whole community. This will be especially important as we encourage more contributions from the wider community (client authors, for example). We think we can make good progress here, and we’d love to try and help improve the process. 🙂

    In addition to the project management, there are still further API projects we need to tackle. Authentication is the most important of these, as a huge focus on OAuth and similar would be needed to make the API more useful for external clients. Currently, we haven’t had enough time to spend on this as well as managing the API project, however the API is now reaching a finalised stage, so this should be able to improve quickly. Centralised authentication is a huge part of this, as the regular OAuth registration process is cumbersome for a distributed system like WordPress.

    Important note: We don’t believe authentication is required for the API merge, and we treat it as a separate project. The authentication is a completely separate system to the API itself. This is something we’d give more time to in the future, but we want to focus on shipping the API for now.

    Let’s go!

    This is our merge plan for the API, however it’s not finalised. If you’ve got comments, thoughts, suggestions, opinions, or words of encouragement, let us know. We’d love to know what you think. Thank you all, you’re wonderful, and stay golden.

     
    • Ahmad Awais 3:13 am on September 21, 2015 Permalink | Log in to Reply

      “After merging the REST API into core, we’d spend approximately two weeks partying and celebrating.” 🎉✨💥 Just like that 🙂 Hoping for REST API to get merged as soon as possible.

    • Jon Brown 3:37 am on September 21, 2015 Permalink | Log in to Reply

      One the one hand this can’t happen too soon or too fast… on the other hand I understand the slow and staged approach.

      I’ve never seen it happen but would it be feasible to merge it into core and flag it as “beta” for a release? I know that wouldn’t be “normal” but then this big of a merge hasn’t happened in a long while and I’m just wondering if something like that was considered?

      The GitHub issue is a big one and I’m glad you touched on it, but I’m entirely unclear what you’re actually proposing here going forward? Are API devs going to continue to have a way to contribute via GitHub post merge?

      • Ryan McCue 3:51 am on September 21, 2015 Permalink | Log in to Reply

        I’ve never seen it happen but would it be feasible to merge it into core and flag it as “beta” for a release?

        I believe the Heartbeat API was handled this way, but I can’t speak as to whether it’d be feasible here; that’s something for the core team to consider. 🙂

        Are API devs going to continue to have a way to contribute via GitHub post merge?

        The plan would be that the API will become an integral part of core, and that contributing to the API would be just like contributing to WordPress. However, we’d like to help people contribute to WP via GitHub, which would allow contributions to the API (or any other part of core) via GitHub. 🙂

        • borekb 7:02 am on September 21, 2015 Permalink | Log in to Reply

          > However, we’d like to help people contribute to WP via GitHub, which would allow contributions to the API (or any other part of core) via GitHub. 🙂

          Yes yes yes! That would be a nice by-product of the API project 🙂

      • Gary Pendergast 3:56 am on September 21, 2015 Permalink | Log in to Reply

        The GitHub issue is a big one and I’m glad you touched on it, but I’m entirely unclear what you’re actually proposing here going forward? Are API devs going to continue to have a way to contribute via GitHub post merge?

        To add to @rmccue‘s comments – the REST API team already have a well established workflow in GitHub. We’d like to experiment with combining their workflow with an (as yet undecided) method for syncing Pull Requests with Trac tickets.

        By experimenting with a small part of WordPress, we can hopefully create a model that could be expanded to work for the entire WordPress project.

    • kstover 3:47 am on September 21, 2015 Permalink | Log in to Reply

      +1

      We’re currently re-writing the moderately successful Ninja Forms plugin using primarily Backbone, and this would be amazing for our plugin. As you say in the proposal, we currently have to stretch admin-ajax.php to the limit.

      Hoping this happens!

    • kdpuvvadi 3:59 am on September 21, 2015 Permalink | Log in to Reply

      what happens to the releases on github, what pull requests and issues? will you handle those?

      • Ryan McCue 4:56 am on September 21, 2015 Permalink | Log in to Reply

        See comments above on how we want to handle GitHub integration. The existing issues on our tracker will either be migrated over, or closed out.

    • Ionel Roiban 4:31 am on September 21, 2015 Permalink | Log in to Reply

      Ggreat news. Where is the API documented?

    • markkaplun 5:08 am on September 21, 2015 Permalink | Log in to Reply

      +0.5 for inclusion, but the only reason is that is serves as a wrapper to Alax API which can speed up AJAX related development.

      OTOH I am still trying to find what does the RST API does that a seasoned developer can’t easily do by himself with the AJAX API.. It is not a replacement to XML-RPC as XML-RPC is a standard adopted by all major platforms and therefor do not required 3rd party (lts say flickr) an extra effort to support different platforms (another more popular usage is trackbacks). With the REST API, it is a wordpress specific thing and to be used by a 3rd party an extra development will be required.

      So the question is why do we need a 4rd way to do computer to computer communication, what is the use case that make the REST aPI shine, something that either impossible or is just so much better then doing it with other protocols? Right now caching of AJAX requests is the only thing I can come up with and that is the reason for the “include but the feature is a meh” above.

      • Ryan McCue 5:59 am on September 21, 2015 Permalink | Log in to Reply

        I am still trying to find what does the RST API does that a seasoned developer can’t easily do by himself with the AJAX API.

        The REST API is a much simpler API for interacting with, and doesn’t have a lot of the problems that XML-RPC does (although it has problems of its own). It’s typically much easier and faster to work with on almost every platform, and it’s a bunch less data that needs to be sent over the wire, which is especially important for mobile applications.

        The XML-RPC we have currently is actually significantly custom to WordPress: XML-RPC is just a standard for an over-the-wire API (similar to REST). The actual APIs for blogging are Blogger, MetaWeblog, Movable Type, and WordPress. (Plus the pingback API.) MetaWeblog is the only actually standard API, but offers very limited utility, which is why the others exist.

        That said, XML-RPC is going nowhere in the short term. It’s still very useful due to compatibility, although I wouldn’t recommend creating a new client using it, due to the complexity.

        a seasoned developer can’t easily do by himself

        Just to note: there are plenty of female developers, so “themselves” would be a better pronoun to use. 🙂

        • markkaplun 4:33 pm on September 21, 2015 Permalink | Log in to Reply

          I think you avoided the main question of use case in which the API shines. The problem with not having a use case is that without one it is impossible to compare if an full REST API is better then some other APIs, or maybe the main benefits can be achieved by some wrapper around the Ajax and rewrite APIs without the added bloat and increasing the attack surface.

          For example a simple use case is a scrolling news feed which refreshes every 10 minutes.With what I see in the API for each new post I will have to do 2 request, one getting the post and another getting the featured image. If I will code it by myself it will do it in one request. The difference between 1 and 2 requests can be the difference between shared hosting and VPS.
          Another variation of the same problem is that AFAICT post meta is not retturned as part of the post request,why is that?

          The point is that the API is huge and every piece of it should be justified IMHO before added to core. 90% (made up the number by myself!) of wordpress sites are not going to use this functionality in any way, at least not before the IOS and android apps will be changed to use it, so why should this bloat be added to core?

          as for male/female thing I can go into how ridiculous it is to expect people that english is not their mother tongue to use english correctly and be aware to all the small cultural assumption behind each word, but I am not PC Principal (people who do not watch south park should be ashamed of themselves)

          • Pete Nelson 6:32 pm on September 21, 2015 Permalink | Log in to Reply

            Using the rest_prepare_post filter, you can add featured image details to each post, thus preventing a round-trip to the server on the front-end. Could also be used for post meta.

            Here’s a link to the relevant slide from a talk I did at WordCamp DFW on extending the REST API: https://docs.google.com/presentation/d/1o4gJnEcq1vbDUsjZu_zRfh8D7crxzU45gTCquZOFODw/edit?pli=1#slide=id.ga423abea2_1_61

            • markkaplun 5:54 am on September 22, 2015 Permalink

              But this requires me to write a plugin that has to be installed server side, and them my JS is not compatible to other wordpress sites, so except for saving some coding what is the difference from now?

              I think your comment helped me to understand my own position. I fully on board with using the core code of the plugin in core in order to make it easier to deploy json based REST API, but I don’t think that the current endpoints are fully baked, it seems like they return too much internal information which no one should know about except for the admin (like list of post types) but also not sure that they give enough information for the most common use cases.

          • Matthew Eppelsheimer 11:42 pm on September 21, 2015 Permalink | Log in to Reply

            I think the key point here is that nearly anything developers can do with XML-RPC or admin-ajax APIs, they can do more easily with the JSON REST API. So it shines across the board, for many use cases.

            The iOS and Android apps can’t start to use this until it is in core. Core itself, and default themes, will also likely use the API in the future. So someday, most and perhaps even all WordPress installations will eventually use the API.

            • markkaplun 6:14 am on September 22, 2015 Permalink

              IOS and android apps will keep using XML-RPC as long as there will be sites that use WP versions 4.3 and below, which is years in the future, and even then why would they rewrite the code for no actual benefit? There is nothing wrong with XML-RPC except for being old and XML note being hype anymore.

              I am not even sure that there is a parity in capabilities of both protocols right now (doesn’t seem like there is an end point for options).

            • Ryan McCue 1:12 am on September 23, 2015 Permalink

              IOS and android apps will keep using XML-RPC as long as there will be sites that use WP versions 4.3 and below

              The iOS and Android apps only currently support 3.6 and 3.5 respectively, so they do have the ability to move faster. In addition, you can progressively support the API, with an XML-RPC fallback if you want.

          • Ryan McCue 1:08 am on September 23, 2015 Permalink | Log in to Reply

            One of the key benefits of the API is that it can remove the need to write anything at all on the server. In addition, data’s provided in a standard way across the wire, making it much easier for plugins to extend. Right now, custom bespoke APIs are unlikely to work across the board with plugins, or even with the edge cases in core. (For example, handling password protected posts is super painful right now.)

            With what I see in the API for each new post I will have to do 2 request, one getting the post and another getting the featured image.

            For the specific example here, try adding ?_embed to your request, and you’ll get back the linked resources as well. http://v2.wp-api.org/extending/linking/ has more detail on that.

            Another variation of the same problem is that AFAICT post meta is not retturned as part of the post request,why is that?

            Answered below; see https://github.com/WP-API/WP-API/issues/1425 for why the current situation is what it is, and what our plans are for improving it.

            The point is that the API is huge and every piece of it should be justified IMHO before added to core. 90% (made up the number by myself!) of wordpress sites are not going to use this functionality

            We can almost immediately begin removing custom Ajax handlers in the admin, such as the code that handles trashing comments. wp-admin/includes/ajax-actions.php might be able to disappear entirely (fingers crossed), and that single file is ~3000 lines just by itself.

            If we can replace all of this code with well-tested code, I think it’s already worth it.

      • Ipstenu (Mika Epstein) 1:32 pm on September 22, 2015 Permalink | Log in to Reply

        The xmlrpc approach is heavily targeted by ddos and brute force attacks, which makes it rather undesireable. From a host standpoint, we hate it 🙂

        https://blog.sucuri.net/2014/07/new-brute-force-attacks-exploiting-xmlrpc-in-wordpress.html Just as an example.

        While not all the issues go away with this, enough do that I welcome our new restful overlords.

    • Daniel Homer 7:03 am on September 21, 2015 Permalink | Log in to Reply

      This is fantastic news, thanks to everyone involved! A standardised API in core will simplify a lot of JS logic in plugins and will pave the way for more advanced web apps on top of WordPress.

      🎉

    • borekb 7:05 am on September 21, 2015 Permalink | Log in to Reply

      What will be the story for plugins that opt to use the API but also need to support 4.3 and below? Will there be a compat plugin for 4.3 and below? Or is that up to the plugin author to deal with that and for example ship parts of the API for older WP versions?

      • Ryan McCue 7:07 am on September 21, 2015 Permalink | Log in to Reply

        The plan is to turn the existing plugin into one that progressively enhances your WP install. It’ll include the infrastructure for sites that don’t have it, but will use core’s otherwise. Once the endpoints are merged, it’ll disable itself. 🙂

        I’d expect that we’ll aim to support this at least until the next major release after the endpoints are merged.

        • borekb 7:11 am on September 21, 2015 Permalink | Log in to Reply

          Cool, thanks for the answer.

        • xavivars 5:45 pm on September 23, 2015 Permalink | Log in to Reply

          That’s the answer I was dreaming!!! We’re working on a project right now where we’re building a site that would benefit a lot from having a powerfull rest-api like the one you guys have built, but my concern was that there was no way to fully use it until it was integrated.

          Seriously, you guys are awesome 🙂

      • Ipstenu (Mika Epstein) 1:43 pm on September 21, 2015 Permalink | Log in to Reply

        Keep in mind what the ‘compatible up to’ and ‘requires’ version actually means in plugins. If you say your plugin requires 4.4, then no one on 4.3 gets updates. In theory you could back port your 4.3 compat tags (say your version 2.5 is sans API while 2.6 is with the new API), and just update 2.5.1 and 2.6.1 for each user base.

    • Hugh Lashbrooke 8:25 am on September 21, 2015 Permalink | Log in to Reply

      > This adds a simplified routing layer outside of WP’s rewrites, allowing non-query-var rewrites easily.

      I never even thought of that as a possibility with this API and I think that excites me more than anything else about this project. It couldn’t be in core sooner 🙂

    • Erlend Sogge Heggen 10:28 am on September 21, 2015 Permalink | Log in to Reply

      First and foremost: CONGRATS! Major props to everyone involved.

      Just one question: What about all these overlapping technologies (XML-RPC, the admin-ajax etc.) that you mention. Is there a deprecation plan in place for the parts that the REST API will cover?

      • Ryan McCue 1:30 pm on September 21, 2015 Permalink | Log in to Reply

        There’s no deprecation plan for them, as they’re not complete replacements. We’ll see what happens in time though; if usage of another API were to drop significantly in favour of the REST API, maybe we could look at it in the future.

    • James DiGioia 12:11 pm on September 21, 2015 Permalink | Log in to Reply

      Very exciting! One question: Will the Backbone client be merged as part of the endpoints, the infrastructure, or as a separate step entirely?

      • Ryan McCue 1:30 pm on September 21, 2015 Permalink | Log in to Reply

        The Backbone client is linked to the endpoints, so it’d be merged with them if at all; we’ll discuss whether it should be as we get closer to merging them 🙂

    • Omaar Osmaan 12:14 pm on September 21, 2015 Permalink | Log in to Reply

      😀

    • Marcus 12:21 pm on September 21, 2015 Permalink | Log in to Reply

      I’m bummed that I haven’t had the chance yet to play with the API yet and give constructive feedback, so words of encouragement is all I can offer. I’ve been following this project closely and can’t wait for this to happen 🙂 this has so much potential for WP as a whole.

      Well done to the whole JSON API team, thanks for all your efforts. Go for it!

    • Daniele Mte90 Scasciafratte 12:43 pm on September 21, 2015 Permalink | Log in to Reply

      I’m in this state http://memecrunch.com/meme/3MCTZ/excited-picard/image.jpg?w=510&c=1
      Also today I’ve written a little article about to expand that api the post type with custom fields http://www.mte90.net/en/2015/09/extend-the-wordpress-rest-api-of-a-post-type-by-custom-fields/

    • Per Soderlind 4:42 pm on September 21, 2015 Permalink | Log in to Reply

      +1 🙂

    • mojaray2k 5:20 pm on September 21, 2015 Permalink | Log in to Reply

      I am so thrilled that this is happening. As a developer I am curious on how OAuth is going to be implimented. Right now it is very difficult to implement without some third party service. Or maybe I am not understanding how to implement it the WordPress way.

    • Aaron Jorbin 5:32 pm on September 21, 2015 Permalink | Log in to Reply

      Thanks for putting this together. A couple of questions that I have:

      1) What would happen to v1 of the API upon merge? Would a new version of it be released that relied upon the routing in core? Would it continue to function by itself? Would it break?

      2) Based on your statement ” On the other hand, all other contribution to WordPress is done via SVN” are you aware that there are git mirrors that all non-committers can use? 😀

      3) Is two weeks sufficient amount of time for 🎉?

      4) Has there been any discussion about marking any of the new classes or methods in the classes as final upon introduction?

      • Ryan McCue 11:13 pm on September 21, 2015 Permalink | Log in to Reply

        What would happen to v1 of the API upon merge?

        Our original plan was to have v1 become a shell that wraps the infrastructure in core to provide compatibility, and I suspect we’ll still do this. We’re yet to get the specifics of it down. 🙂

        are you aware that there are git mirrors that all non-committers can use?

        Using git vs managing contributions via GitHub is a different kettle of fish. Right now, I already use git for making patches, but the flow for contributing those changes back is a bit cumbersome. We can do better 🙂

        Is two weeks sufficient amount of time for 🎉?

        Maybe not, but real life commitments get in the way of any prolonged 🎉ing. 😬

        Has there been any discussion about marking any of the new classes or methods in the classes as final upon introduction?

        Our intention is to keep them all extensible for now, and they’re all designed for reuse. As for forwards-compatibility though, we’ll consider this as we “finalise” (😏) the classes for merging.

    • karlazz 8:17 pm on September 21, 2015 Permalink | Log in to Reply

      Hello,

      I used the API briefly and then rejected it for a few reasons:
      1) the Oauth1 is hard to use and not well supported with examples or libraries, why not use Oauth2 like everyone else?
      2) It was awkward to get at post meta information. I used a plugin.
      3) the requests returned too much information and my programs died with a memory fault. Due to the nature of my plans for the application, this was not acceptable so I wrote simpler more specific tools that did not return mountains of unnecessary fields and require my users to increase their PHP memory limit.

      1) There is a lack of community code available for using Oauth1, and the API authors didn’t provide any guidance for setting it up, just some information thrown over the shoulder as it were. Even the endpoints were hard to find in their literature, and not quite the same as the ones described as “standard”. I hope that will be improved, or that you will switch to Oauth2, like the rest of the world. Security is a very important aspect of this project and people need to be able to use the locks. It would be great to provide a description of how to set up and use curl calls to access the API security. Salesforce does a good job of this, as does Box.com.

      2) Couldn’t access postmeta information via the API unless Oauth1 is implemented. Why? Used work around.

      3) It would be great if I could designate which fields I need to have returned using POST data and json. Box.com does this, as do others. This would save on memory when returning large numbers of records. Maybe you have this already and I missed it?

      Thanks. Good luck. This is a great idea but I chose not to use it and would not recommend it for the above reasons.

      • Ryan McCue 11:19 pm on September 21, 2015 Permalink | Log in to Reply

        the Oauth1 is hard to use and not well supported with examples or libraries, why not use Oauth2 like everyone else?

        I totally agree, OAuth 1 is a pain. However, the reason that OAuth 2 is much nicer is that it relies on SSL to handle much of the message authentication. We can’t require SSL for WordPress core code, so OAuth 2 is unfortunately a non-starter there.

        The OAuth Working Group has been making slow progress towards removing this requirement, and we’ve been following that. If anything changes there, we’ll consider changing it.

        Couldn’t access postmeta information via the API unless Oauth1 is implemented. Why? Used work around.

        Working with postmeta requires a great deal of care, due to privacy and security concerns. As it turns out, there are lots of people who use the Custom Fields box to save private notes directly to post meta, so we cannot just expose all meta without considering.

        We’re looking at relaxing the restrictions here in the future: https://github.com/WP-API/WP-API/issues/1425

        It would be great if I could designate which fields I need to have returned using POST data and json.

        This is something that most people don’t need, and which also has the ability to play havoc with server-side caches. This is easily doable in a plugin however, and we’d love to see someone take up the work there.

        See https://github.com/WP-API/WP-API/issues/572 for more details.

        • pathartl 3:52 pm on September 24, 2015 Permalink | Log in to Reply

          Just showing my support for keeping post meta behind Oauth. At first I was skeptical, but it’s very easy to hook into the data via the `json_prepare_post` filter and add any data you want to the JSON response.

    • John Teague 8:26 pm on September 21, 2015 Permalink | Log in to Reply

      I can’t tell you how happy I am and how thankful I am to the entire REST API team. I have lobbied for the inclusion into core, and I know this will make WP stronger and better for the future. Kudos all around @ryan,@rachelbaker, contributors all. 🙌

    • Greg Ichneumon Brown 9:53 pm on September 21, 2015 Permalink | Log in to Reply

      The v2 docs mention 3 types of authentication: cookie auth, oath1, and basic auth. You mention though that Authentication is a separate project.

      Are some of these (all?) going to be part of the merge and when are they available (stage 2?). I assume many of the endpoints are not useful without some level of authentication (though I guess there are many GET endpoints that could work without auth).

      • Ryan McCue 11:20 pm on September 21, 2015 Permalink | Log in to Reply

        Cookie authentication is built-in to WordPress, so that’ll be there out of the box. Basic authentication is only intended as a development tool, so the intention is to never include this with WordPress. OAuth 1 is something we’ll consider in the future, either when merging the endpoints, or shortly afterwards.

    • Michael Beil 10:18 pm on September 21, 2015 Permalink | Log in to Reply

      This is such momentous news @ryan and @rachelbaker!

    • simonrcodrington 12:27 am on September 22, 2015 Permalink | Log in to Reply

      I’m all for the integration of the REST API into WordPress core. My concern is if this will produce any strange side effects that could affect my sites (I know this supports multiple types of security such as oAuth but it’s always on my mind)

      It’s been tested for a while but I still think a cautious approach to this would be better (with starting integration later at WP 4.5 and then moving from there). It’s one of the biggest introductions to core in a while so I’m happy with a slower pace 🙂

      • Ryan McCue 12:58 am on September 23, 2015 Permalink | Log in to Reply

        With this first phase, there won’t be any read or write capabilities added, only internal APIs. A future version will start integrating those as part of the second phase.

        We’ve also been working on this for ~2 years, and in the meantime we’ve fixed a few security bugs (mostly minor), so we’ve already had lots of eyes over the code. 🙂

    • Zach Russell 6:01 pm on September 22, 2015 Permalink | Log in to Reply

      I scanned through the comments and don’t think I found an answer there. I’m working on an app right now that uses the WP API. Will I have to make any changes to my code once the WP API is merged with core?

      • Ryan McCue 1:47 am on September 23, 2015 Permalink | Log in to Reply

        The plan is that the current v2 will become the core version with minimal changes. If you build off v2 now, you may need to change your code slightly, but changes will almost certainly be minor.

    • Praveen Chauhan 9:38 am on September 23, 2015 Permalink | Log in to Reply

      Great news !!! Congrats to the REST API team.

      Have few questions:

      1) How will REST API specific support queries/updates be handled?
      For a plugin, there can be many support queries, and there is a dedicated forum. So if some one has queries specifically related to the REST API, will you continue to use the REST API plugin’s forum or have you planned to shutdown that forum or plugin listing?
      More importantly, how will updates for the fixes be handled? I mean, if some one has issues specific to the REST API functionality which requires some fixes, will the users need to wait for the new release of WordPress or do you have an alternative plan for this?

      2) What will be the impact on WordPress’ performance?
      As a plugin, the functionality is optional for users. But after merging it into the core, its modules will be loaded along with WordPress. So what would be its impact on site load, performance etc?

    • pathartl 4:12 pm on September 24, 2015 Permalink | Log in to Reply

      +1 in full support. A question and comment:

      1. What will happen with the plugin (both v1 and v2) when it is activated on an install that has the API in core? We’ve written some read-only things for v1 and I’m concerned about having a major refactor later on down the road. No doubt it will eventually happen, but the concern lies in the first couple phases of integration.

      I’m glad the core committers will have to look at every aspect. I found the documentation lacking in places. Well not necessarily lacking, but not as well documented as most things in the codex. This is a big merge that is totally developer focused and should be hashed out really well.

      Thanks for the hard work! This is much needed

    • suifengtec 5:08 pm on October 9, 2015 Permalink | Log in to Reply

      It’s cool for the future of WordPress !

    • snstarosciak 1:21 pm on October 21, 2015 Permalink | Log in to Reply

      Nice! So here’s my question. How will this impact current sites using the WP API v2? Assuming building something like this into core will make API-creation plugins unecessary, I’m guessing that the “final” functionality will be available in 4.5 that is similar to how the WP API v2 works?

      Thankyou!

    • mmaumio 9:01 pm on November 5, 2015 Permalink | Log in to Reply

      That’s Awesome. It’ll surely save us from creating our API or using a third party plugin.
      +1 for this.

    • WP Plugin Dev dot com 12:41 pm on November 20, 2015 Permalink | Log in to Reply

      Two important questions arise:
      What is public in the API after the merge?
      Can I tell WordPress to don’t provide the API functionallity?

  • Ryan Boren 3:50 pm on June 9, 2015 Permalink
    Tags: , live-preview, , preview   

    Trust, Live Preview, and Menus in the Customizer 

    One of the most important things in WordPress is users being able to feel confident as they make changes to their content and more generally to their sites. Being able to make non-destructive changes and preview them is an important component of building that trust. This is perhaps most noticeable in the “save and surprise” approach of the widgets admin screen – every time you add a new widget, modify its settings, or move one around, the changes are saved and appear live on your site, even if you’re not ready yet. The customizer is our framework for live previewing changes. We are committed to providing live preview for all aspects of site customization and making it usable on all devices from phones to large screens.

    The customizer is the result of a tremendous amount of work over many releases. It was first introduced in 3.4. In 3.9, it received its first big updates in the form of widgets support and improved header upload and cropping. 4.0 brought panels and contextual controls. Development really started to take off in 4.1 when JS-templated customizer controls and a JS api were introduced, making possible an ecosystem of live preview compatible plugins and themes. 4.2 followed that up with two important features, theme switching and mobile support.

    That brings us to today and the ongoing 4.3 development effort. Revamped navigation for the customizer is already in trunk and the nighty builds. The menu customizer feature plugin is a merge candidate for 4.3 and could land soon. These marquee features further our commitment to live preview and need all of the attention we can muster.

    The customizer has come a long way, but it still lacks some features and needs time to mature. We have many improvements planned and in-progress, including transactions, partial refresh, theme installation, speedier loading, scaling to large screens, and possibly even integration with front end editing. Our live preview framework offers many possibilities.

    Meanwhile, the Appearance screens will remain and will be maintained. Appearance > Menus recently received some attention in the form of a few fixes. More attention is needed and will be given. There are still differences in the flows each approach best enables, whether it’s new site/theme setup, small maintenance tasks, or dedicated content managers for heavy usage of widgets, menus, or other pieces of content that benefit from having a preview mechanism. We should gather quantifiable metrics when it comes to performance and time to completion for a given flow, as well as evaluating the less-objectively-quantifiable perceived performance. There may come a time where the worlds converge; however, that time is not now.

    The feature plugin merge window is currently scheduled for June 17th. We have 8 days to get the Menu Customizer plugin ready for merge. Feature plugins must meet several criteria to be considered for inclusion in a release. To meet this criteria, the flow team has started testing and documenting flow and visuals for the menu customizer as well as the recently landed navigation changes. Merge criteria include identifying flows through the customizer, creating visual records of those flows, and creating flow comparisons of existing flow through Appearance > Menus versus flow through the customizer. This is a great and necessary way to contribute that requires no coding. All you need to do is take screenshots and publish them as a captioned gallery using the tool we’re making together, WordPress. We endeavor to be an Alan Lomax of flow, capturing and cataloging real user scenarios. Please help us capture the flows through Appearance > Menus used by you and your clients. We need this information to ensure our new interfaces are mindful and aware of how WordPress is actually used. Information on how to test and contribute visual records is available on the 4.3 development tracking page.

    @ryan, @helen, @designsimply

     

     
    • codezag 3:59 pm on June 9, 2015 Permalink | Log in to Reply

      the database structure of the menus will be changed ?
      is there any chnages to the menu walkers & database ?

      thanks

      • Fabien Quatravaux 7:49 am on June 11, 2015 Permalink | Log in to Reply

        As far as I know, this menu customizer will not introduce any change visible on the front-end side : no database structure change and no change to Menu Walkers. The only issue is about plugins or themes that added features to the Appearance > Menu admin page : those features may require some work to be available in the new menu customizer.

    • Frankie Jarrett 4:02 pm on June 9, 2015 Permalink | Log in to Reply

      Great to see that the core team is so committed to advancing the Customizer! I really believe it’s a glimpse into the future for a more JS-driven WordPress. Takes a bit of time to steer a ship of 75 million sites, but I know we’ll get there, and we’ll do it responsibly without leaving folks behind 🙂 /fives!

    • Shapeshifter 3 4:11 pm on June 9, 2015 Permalink | Log in to Reply

      Ryan,

      A very thorough synopsis of the current plan.

      Thank you!

    • kevinwhoffman 4:49 pm on June 9, 2015 Permalink | Log in to Reply

      Ryan, thanks for the update. The parallel development of the Menu Customizer alongside maintenance of the existing Menus screen is a good strategy moving forward until the Customizer is better proven.

      I also appreciate the rationale behind the importance of live previewing in different use cases. The more guesswork we can take out of the editing process, the better.

    • Jon Brown 4:52 pm on June 9, 2015 Permalink | Log in to Reply

      Great summery Ryan. I think the backlash against the menu customizer would have been a lot tamer if the proposal hasn’t included removing the appearance/menu page and stating that “this was the solution” for all the long un-addressed bugs in the appearance/menu page.

      Personally I don’t like the UI/UX of the customizer. I think stuffing that much GUI in the side panel is a mistake and editing should happen directly “on the page”. I wouldn’t object strongly to menu editing being added to the customizer panel as on option though, especially since I can always disable it like many of the customizer controls my client base find cluttered and confusing.

    • Morten Rand-Hendriksen 5:14 pm on June 9, 2015 Permalink | Log in to Reply

      Ryan is a calm shore in a raging storm.

      • George Stephanis 6:45 pm on June 9, 2015 Permalink | Log in to Reply

        Yes, behold my lord Boren, the rock, the hard place, like a wind from Texas he sweeps by blown far from his homeland in search of glory and honor, we walk… in the garden of his turbulence!

        (as paraphrased from A Knight’s Tale)

    • Gabe Shackle 5:28 pm on June 9, 2015 Permalink | Log in to Reply

      It’s a great addition to WordPress but the release approach has been terrible. Virtually all the opposition to the Customizer could have been avoided if it didn’t seem like everyone was being forced to use it.

      Things like changing the Widgets link from the admin bar, requiring all settings being in the Customizer by the TRT, and then with this last push that included language to remove the menus admin completely from the dashboard, it’s no wonder people were fairly upset and wrote the entire system off.

      If it had simply been released like this:

      “Check out this great new way to manage menus and widgets.”

      Rather than:

      “Here is the new way to manage widgets and menus. We’re going to be removing the interface you’re familiar with because we feel this new method is better and we don’t have enough resources to maintain both.”

      There would have been almost no push back at all. If the Customizer is truly as great as its developers say, let it stand on it’s own and prove it.

      • Helen Hou-Sandi 5:48 pm on June 9, 2015 Permalink | Log in to Reply

        Let’s take a moment to reflect on reactions being similarly imperfect in language choices and emotive content, and the very real effects that has on attracting and retaining the contributors we need to be able to maintain and improve those interfaces. Continuing to snipe at each other about tone, semantics, and hypothetical “should”s as though everything is predictable is not particularly productive.

        • Gabe Shackle 5:52 pm on June 9, 2015 Permalink | Log in to Reply

          I was merely offering my perspective and a possible reason for the negative reaction. No sniping intended at all.

        • PeterRKnight 10:22 pm on June 9, 2015 Permalink | Log in to Reply

          I thought a lot of the (unfair) reactions were coming from a lack of understanding about why these changes are happening and the way they are coming about. It’s always painful to see folks talking like there’s some kind of powertrip happening amongst some illusory ruling elite.

          But I’m agreeing with Gabe here, I think better communication would have prevented some of the kneejerk reactions that can be demotivating toward the developers.

          Because Gabe is right in that some people are interpreting this as tools being taken away from them, instead of being excited about a new powerful way of managing menus.

        • dmccan 3:26 pm on June 12, 2015 Permalink | Log in to Reply

          This post is great. It communicates and helps people to understand the thinking, planning, work, and process.

          Compared to some feedback I’ve seen, the feedback to this post has mostly been positive and generally constructive. We are all human and learning along the way. It is important to encourage and acknowledge contributions as well as provide constructive feedback. In this case the constructive feedback is that more good communication, like this article, is helpful.

    • Weston Ruter 7:02 pm on June 9, 2015 Permalink | Log in to Reply

      Thank you for writing this, @boren.

    • Knut Sparhell 7:36 pm on June 9, 2015 Permalink | Log in to Reply

      It’s already said, but again: Thank you for writing this, @boren. Record the flows of common tasks, on every kind of device.

    • Jose Castaneda 7:52 pm on June 9, 2015 Permalink | Log in to Reply

      Great write-up! Thank you for this. 🙂

  • Konstantin Obenland 7:45 pm on April 28, 2015 Permalink
    Tags: , ,   

    WordPress 4.3 Kickoff 

    First I’d like to thank @drewapicture for his outstanding work in 4.2! I was particularly impressed with his ability to keep meetings on track and in time, I’ll work on making sure that won’t change going forward. 🙂 A lot of the structure and artifacts he put in place have been proven quiet successful and I’d like to continue that, so you shouldn’t see too much change in that regard either.

    Release Date

    We’re aiming to release on Tuesday, August 18th. The 4.3 schedule is live and can be found here: https://make.wordpress.org/core/version-4-3-project-schedule/

    Deadlines are not arbitrary, and with your help I fully intend to get this version shipped comfortably on the 18th. Past releases have been quite good about releasing on time, let’s make that a signature trait of the WordPress project!

    Features

    WordPress 4.3 will be all about enabling users of touch and small-screen devices. @ryan has been testing flows on a myriad of different devices the past few releases and uncovered many things that desperately need attention.

    @joedolson has published a post over on make/accessibility about a11y priorities.

    If you see anything that sparks your interest feel free to leave a comment here and attend the kickoff meeting tomorrow, when we go through the list of things that were suggested. Specifically, Admin UI can will need a lot of hands. The meeting will also be a good time to suggest additional areas that you want to work on.

    Kickoff

    We’ll kick 4.3 off with a 2-hour meeting in #core at the usual time, April 29, 20:00 UTC.

     
    • sara cannon 7:55 pm on April 28, 2015 Permalink | Log in to Reply

      Excited for this release! I would love to help out with the Network Admin UI

    • Dave Navarro, Jr. 7:58 pm on April 28, 2015 Permalink | Log in to Reply

      Would like to see an update of the AUDIO shortcode as well to pull the title text from the audio file and display it.

      Really excited for the Shortcake stuff, hope it makes it.

    • Nick Halsey 9:51 pm on April 28, 2015 Permalink | Log in to Reply

      I have several ideas for continuing to work on themes in the Customizer building on 4.2. Would like to aim for adding theme install in 4.3, which would require a shiny install process, and shiny updates could work into that well too. I won’t be able to get started on that for a couple weeks, but should have a functional and tested proposal together well before the scheduled decision time.

      Along with the other mobile and touch improvements, I’d really like to see the much-needed Customizer UI design changes happen as well, hopefully we can pick back up with #31336 soon cc @folletto @designsimply.

      FYI, as is usually the case, I won’t be able to make most dev chats again this cycle.

    • aradams 10:07 pm on April 28, 2015 Permalink | Log in to Reply

      Hello All,

      I am not part of Make, just a WP user & designer. I have watched the unfurling of the New Editor saga over at WP.com and am concerned that there might be movement to implement that Editor to replace “Classic” editor for self-hosted WP. Could someone speak to that? I would be most grateful.

      • Konstantin Obenland 2:28 am on April 29, 2015 Permalink | Log in to Reply

        There are no plans that I’m aware of.

      • James Huff (MacManX) 5:27 am on April 29, 2015 Permalink | Log in to Reply

        You can use the new editor at WordPress.com for your self-hosted WordPress.org blog already if you have the Jetpack plugin installed and its Manage module active. Note that you’ll actually be using the new editor *on* WordPress.com, and can continue to use your WordPress.org blog’s Dashboard and “classic” editor as normal.

        Considering that WordPress.com and Jetpack are both products of Automattic Inc, and WordPress(.org) is not, I’m pretty sure there will be no deeper integration or replacement.

    • Pete Nelson 10:59 pm on April 28, 2015 Permalink | Log in to Reply

      Just a couple of patches waiting for that sweet, sweet commit: #31813 #31029

    • Stephen Edgar 11:49 pm on April 28, 2015 Permalink | Log in to Reply

      Admin UI – In #26311 I added a patch to make the “export admin screen” more responsive, I did this by replicating existing functionality from other admin screens, turns out these screens use tables, details of who, what and where tables are used in admin screens is also listed in that ticket.

    • mrjarbenne 3:50 am on April 29, 2015 Permalink | Log in to Reply

      It would be great to see this attended to: https://core.trac.wordpress.org/ticket/29606. Still can’t re-order gallery images on mobile (on iOS at least)

    • Max 7:37 am on April 29, 2015 Permalink | Log in to Reply

      I am not sure if that relates to Admin UI but #12706 is something which has been flowing around for a very long time without getting any closer to being fixed…

    • Ryan Boren 9:31 am on April 29, 2015 Permalink | Log in to Reply

      The touch bug I most want to see fixed is #29906. It is lingering desktop bias that fouls important toolbar flow.

    • leemon 12:45 pm on April 29, 2015 Permalink | Log in to Reply

      https://core.trac.wordpress.org/ticket/22938 – Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list

    • Torsten Landsiedel 1:13 pm on April 29, 2015 Permalink | Log in to Reply

      It would be really great to fix https://core.trac.wordpress.org/ticket/28303 in 4.3. I know this is a problem just for a bunch of languages, but files being overwritten is always a big problem and people are complaining in our local forums.

    • Ryan Boren 7:47 pm on April 29, 2015 Permalink | Log in to Reply

      Perennial wish, retire media-new.php.

      https://make.wordpress.org/flow/2015/01/29/retiring-media-new-php/

      Seems like most of the work would be hooking the media addition ui from the grid view into the list view with some row insertion ajax. The list view would also need to become a full screen drop target like grid view.

    • pingram3541 8:07 pm on April 29, 2015 Permalink | Log in to Reply

      Would love to see the ability for nesting multiple shortcodes of the same name. Many themes and plugins could benefit, especially when building grids and nesting columns etc. The logic is fairly simple but there is no way to filter this currently.

      Another thing I’d love to see is the ability to define query “orderby” based on multiple meta_key, meta_values, currently you can pass an array to order by a single meta_value + any of the other orderby arguments but not 2 or more meta_keys.

    • Weston Ruter 9:59 pm on April 29, 2015 Permalink | Log in to Reply

      My proposals as I’ve also blogged:

      Customizer Partial Refresh
      This greatly improves performance of previewing changes in the Customizer for non-postMessage transport settings (JS-applied changes) by just refreshing the area of the page that has been changed. As such it eliminates some of the need to do postMessage in the first place, while also reducing the amount of duplicated logic that would have to be implemented in JS to mirror what is being done in PHP. This resurrects some code from the old Widget Customizer feature plugin developed for 3.9. Writeup and feature plugin are available.

      Customizer Transactions
      A low-level re-architecture of the Customizer plumbing that has a lot of side benefits and bugfixes, introducing some exciting possibilities for future feature plugins like scheduled settings, setting revisions, and drafted/pending settings. Partial Refresh is a dependency for this. Pull request available, but needs refresh. See proposal.

      Customizer Concurrency/Locking
      This is an important one for a client project I’m involved with, and so I’m having to prioritize it. I’m working on a client site that will have many users in the Customizer at a time, and given the way the Customizer is currently implemented (as with most areas of WP), there is no concurrency/locking support. So I’m working on adding locking at the control/setting level. See #31436.

    • RENAUT 11:31 pm on April 29, 2015 Permalink | Log in to Reply

      what about reviewing all the mails send by wordpress ?

  • Ryan Boren 7:47 pm on March 6, 2015 Permalink  

    Mobile make-flow update 

    Only two make-flow tickets have been fixed during 4.2. Here’s where we’re at.

    List tables

    We have some patches which attempt hiding columns on small screens, but that approach is unsatisfying. A single column approach feels better. Perhaps we could get some one column designs for media and tags and go from there.

    #29993 – Media action links are cramped on small screens
    #29992 – Cramped tag action links on small screens
    #29991 – Comment action links are quite cramped on small screens
    #29995 – Username is cut off on the user list table on small screens
    #29994 – Border bug on empty list tables on small screens

    Admin Menu

    #31187 – Allow swiping the admin menu open and closed on touch devices

    There’s a patch that tests well on everything we’ve thrown at it so far except a OnePlus One phone. I think that’s the only hold up. Can anyone give that a look?

    #29906 – Submenus can’t be dismissed on mobile.

    The patch here works well for me. It needs code review. There’s one more issue to address regarding admin bar menu behavior.

    Media

    #29989 – Hide Media Buttons on small screens

    This has lost all momentum. Unless a dev adopts it, this one won’t see 4.2. A big bummer.

    TinyMCE

    #31159 – Kitchen sink should be hidden by default on small screens

    I think always collapsing the kitchen sink on mobile is fine for now, but preserving interface state separately for mobile and desktop merits future discussion. There are no patches yet for this ticket.

    #31161 – TinyMCE Help button is irrelevant on devices without keyboards

    I’m down with removing the help button on mobile. Needs a patch.

    Modal scrolling

    Scrolling behind modals is a persistent problem for us. We need a holistic approach instead of the slow motion wac-a-mole we’ve been doing.
    https://make.wordpress.org/flow/2015/03/05/scroll-bleed-through-in-the-session-expired-log-in-modal-iphone-5/

    #31381 – The theme details modal has scrolling and toolbar problems on iPhone 6 and 6+

    31381 has a reviewed patch that is ready for commit. Is this approach applicable elsewhere?

     

    Open make flow tickets:

    https://core.trac.wordpress.org/query?status=!closed&keywords=~make-flow

     
  • Drew Jaynes 12:09 pm on March 4, 2015 Permalink
    Tags: ,   

    Dev Chat Agenda, March 4, 2015 

    Here’s the agenda for Wednesday’s Dev Chat in the #core channel on Slack.

    » Beta 1 is one week away, along with the enhancements deadline.

    Time/Date: March 4 2015 21:00 UTC:

    1. Feature Updates
      1. Customizer Theme Switcher – @ocean90 / @celloexpressions
      2. Press This – @michael-arestad / @stephdau / @azaozz
      3. Shiny Updates – @pento
      4. Emoji – @pento
    2. Component Updates
      1. Accessibility – @afercia
      2. Mobile – @ryan
    3. Release Schedule Recap
    4. Daylight Saving Time reminder
    5. Open Floor – Looking for dev feedback on a ticket? Use this part of the meeting to let us know!
     
  • Drew Jaynes 12:00 pm on February 25, 2015 Permalink
    Tags: ,   

    Dev Chat Agenda, February 25, 2015 

    Here’s the agenda for Wednesday’s Dev Chat in the #core channel on Slack.

    Time/Date: February 25 2015 21:00 UTC:

    1. Feature Plugins – The Customizer Theme Switcher and Press This were merged into core on Tuesday. Please test and create new tickets for any issues you find
    2. Component Updates
      1. Accessibility – @afercia
      2. Mobile – @ryan
      3. Components – All the news that is news with @nacin
    3. Enhancements Deadline Reminder – Beta 1 is 2 1/2 weeks away. Need to start wrapping up enhancements.
    4. Open Floor – Looking for dev feedback on a ticket? Use this part of the meeting to let us know
     
  • Drew Jaynes 7:46 pm on February 18, 2015 Permalink
    Tags: ,   

    Dev Chat Agenda, February 18, 2015 

    Here’s the agenda for Wednesday’s Dev Chat in the #core channel on Slack.

    Time/Date: February 18 2015 21:00 UTC:

    1. Feature Plugins:
      1. Consider the Customizer Theme Switcher plugin for merge [Proposal] [Plugin]
      2. Consider the Press This Revamp plugin for merge [Proposal] [Plugin]
      3. If you haven’t looked at either of the merge proposals yet, please spend some time today before the meeting. Please comment on those posts if you haven’t already.
    2. Component Updates
      1. Accessibility – @afercia
      2. Mobile – @ryan
    3. 4.3 Release Lead – If you’re interested in leading a future release, it’s time to speak up.
    4. Open Floor – If you have something you’d like to discuss, leave a note in the comments
     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar