Andrew Rockwell 4:51 pm on February 24, 2016
Tags: 4.5 ( 60 ), week in core ( 245 )

Week in Core, Feb. 16-23 2016

Welcome back the latest issue of Week in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., covering changes [36671-36541]. Here are the highlights:

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

Ticketticket Created for both bug reports and feature development on the bug tracker. 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 SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

Code Changes

AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)

Improve the color contrast ratio for the input placeholders. [36619] #35777
Remove title attributes from the PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party details modal. [36618] #35111
Remove the revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. 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 ImageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. 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-URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org 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

Don’t display errors during Ajax requests. [36571] #34915, #23811, #26262
Make $wp_local_package explicitly global in wp-settings.php. [36557] #34975

Build/Test Tools

Add Tests_dbDelta::assertTableHasPrimaryKey(). [36552] #34877
Add a test for testing wp_enqueue_script() with an alias handle in the footer. [36559] #35643
Test that jQuery can be moved into footer after [36550]. [36596] #25247
Add test for wp_get_installed_translations(). [36563] #35284

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 filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. [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 sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. 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 testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. 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 PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher notice and JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. 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 tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) from the WP_Customize_Panel->instance_count property DocBlockdocblock (phpdoc, xref, inline docs). [36568] #32246

Embeds

Only display an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. 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

Make Custom TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. Feeds Auto-discoverable [36671] #23677

Formatting

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

Help/About

Remove unused strings. [36554] #34909

HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.

Certificate bundle: Attempt to move a certificate lower in the file to allow older OpenSSL versions to parse it & communicate with WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://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

I18Ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.

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-adminadmin (and super admin)/users.php. [36621] #35885
Remove HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. 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

Update unit tests after change to default image quality. [36616] #33642
Reduce default image compression quality to ’82’. [36615] #33642
After [36546] restore the “Add new” functionality. [36575] #34350, #35853

Menus

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

Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site

Make view mode sticky for networknetwork (versus site, blog) 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 metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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

Remove an unused variable after [35953]. [36581] #35050

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 excerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. 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 headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. status handling. [36629] #10722
is_*( $int ) should not falsely match strings starting with “$int”. [36625] #24674, #35902

Revisions

Clean up _wp_post_revision_fields() [36659] #13382

Schema

Add an index to wp_users.user_email. [36654] #9568, #33376

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

Update label for the username field in wp_login_form() after [36617]. [36620] #9568

Themes

After [36546] restore theme search functionality. [36580] #34350
Fix flickering of the theme screenshot on hover in WebKit browsers. [36579] #35787
Improve error messages for broken themes. [36638] #35286

TinyMCE

Inline text patterns [36627] #33300
Fix the regex that removes spaces from empty paragraphs. Was causing problems when wpautop is disabled and there are many U+00A0 chars between the opening “ and an inline tag. These chars are inserted by the browsers to maintain consecutive spaces typed by the users in contentEditable. [36597] #35890
Update to 4.3.4. Changelog: https://github.com/tinymce/tinymce/blob/master/changelog.txt. [36589] #35876
Create and edit links inline. [36602] #33301

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!

#4-5, #week-in-core

Adam Silverstein 8:14 am on January 27, 2016
Tags: 4.5 ( 60 )

Feature Plugin chat notes for Jan 26

Agenda

Review the feature plugins for status updates from leads
Open floor for feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. 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 enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. See #32403.
CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.: @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 APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.: @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 multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site 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 blogblog (versus network, site) soon. The team needs more feedback and testing! Testers can get the current pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party from the wordpress.org repository.
WP-API: @danielbachhuber updated – released betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 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 dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. (at the Day of REST) will hopefully get other people diving in and contributing to the final push.

Open Floor

@johnbillion mentioned exploring developing the Notifications API in the form of a feature plugin
@jrf proposed a feature plugin for theme and plugin dependency management and is looking for feedback on the idea — please leave any notes in the comments.

The full logs are available on Slack.

#4-5

Ryan McCue 1:03 am on September 21, 2015
Tags: feature plugins ( 120 ), json-api ( 39 ), merge ( 11 ), proposal ( 36 ), rest-api ( 107 )

WP REST API: Merge Proposal

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

We on the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. team (myself, @rachelbaker, @joehoyle, @danielbachhuber, and newest member and coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. @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 JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. in a theme or pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, mobile and desktop applications, or importing and exporting data. The APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. offers up all core data types (posts, terms comments, and users), plus support for metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision.; we’ve got plans to eventually have access to everything the adminadmin (and super 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 JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. 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 HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.. 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: UIUI User interface-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 codeLines of Code Lines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses. (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 GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ 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 SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. and TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., 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.

#feature-plugins, #json-api, #merge, #proposal, #rest-api

Ryan Boren 3:50 pm on June 9, 2015
Tags: customize ( 67 ), live-preview, menus ( 31 ), 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 adminadmin (and super admin) screen – every time you add a new widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user., 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 customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. 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 headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. 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 trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. and the nightly 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 pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. merge window is currently scheduled for June 17th. We have 8 days to get the Menu Customizer pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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

#customize, #live-preview, #menus, #preview

Konstantin Obenland 7:45 pm on April 28, 2015
Tags: 4.3 ( 65 ), agenda ( 995 ), meeting ( 364 )

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.

Editor led by @azaozz and @iseulde
Adminadmin (and super admin) UIUI User interface led by @helen
Networknetwork (versus site, blog) admin UI led by @jeremyfelt
Partial Refresh led by @westonruter
Customizer Transactions led by @westonruter
Install process and passwords led by @markjaquith

@joedolson has published a post over on make/accessibility about a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) 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.

#4-3, #agenda, #meeting

Ryan Boren 7:47 pm on March 6, 2015

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 tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. on empty list tables on small screens

Adminadmin (and super admin) Menu

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

There’s a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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.