Iterating on Feature Plugins

Feature plugins appeared in the wake of the 3.6 release cycle, in which two large efforts were reverted before the final release: a UI for content using post formats and a refreshed aesthetic for the admin, notably with a new set of icons. Both suffered from the same problem: attempting to create and iterate on a significant feature within a single release cycle. The identification of that problem led to the idea of developing features as plugins, decoupling them from the time restrictions of fairly quick release cycles.

(While post formats had further issues that led to changes not landing in core, the admin design changes became known as MP6, a feature plugin which was merged in WordPress 3.8.)

Over the last two and a half years, we’ve had successful feature plugins that were merged into core, efforts that began small and grew as discovery happened, ideas that never quite got off the ground, and ideas that were initially explored in “plugin” form but ultimately became patches for various reasons, usually technical. With over two years of active feature plugins behind us, it’s time to take a look at what’s been successful, what hasn’t been, and where we go from here.

So, what’s next?

Feature plugins projects

Thinking of features as plugins has strapped us in a number of ways, in large part because the “plugin” part implies a functional project from the start. From observation, experienced and newer contributors alike set their initial goal to be some sort of functional plugin. As a result, by the time something is being proposed in whatever forum, there’s been a fair amount of effort spent – and personal attachment developed – for something that might be headed in the wrong direction. Changing direction at that point is very demoralizing and has led to burn out and less participation.

My suggestion is to move both nomenclature and mindset to “feature projects.”

Feature projects are similar to feature plugins in many ways (including in name), but may not take the form of a plugin; in fact, they likely will not begin as plugins. Most will start as ideas that need exploration to be more fully formed/fleshed out before implementation. Others will become discrete patches on tickets. Others may turn into multiple plugins, breaking out the successful parts of the project into patches for core, while iterating on the less-successful pieces. Still others may remain in plugin format even after reaching a polished point, as they may not make sense as a bundled part of core but serve a valuable purpose for users.

To start, there is now a feature projects overview (still in progress) that is more of a higher level overview than the current status dashboard, with listings of feature projects that are in progress or merged, with sections for wishful thinking and projects that have been abandoned for one reason or another to be added in the future. Each project should be accompanied by a brief statement that clearly states what problem the project is solving, its goals, and how it supports the various philosophies and objectives of the WordPress project. The overview will also serve as a sort of roadmap for potential project features, albeit one without promises of delivery timeframes.

The general goal of this shift in framing and process is for feature development to be successful and lead to a stronger product with more contributors. Some individual goals in support of this are:

• Attracting and retaining a greater range of skill sets in contributors, for example through being able to more thoroughly engage designers in early stages.
• Implementing methods of collecting usage information and other data (more on that coming soon).
• Supporting feature projects with resources for user testing and more structured feedback.
• Advance both contributor and general community knowledge around product design and development.

Life cycle of a feature project

Today, feature plugins move forward in varying directions, frequently without a clear goal or target. This can make it hard to determine what their status is or what next steps might be. Learning from the current situation, feature projects will have clearer check points. For one, there will be bi-weekly meetings where anyone can propose a feature project, check in at specific goal points, update the community on the current status of a feature project, and/or ask for help if they’re having issues advancing their idea. We will kick these off in the #core channel in Slack on April 5 17:00 UTC.

Beyond this, there are several parts in the life of a feature project.

First, a feature project should have a brief statement of purpose. Explaining why a feature project is important to WordPress – and how it fits in with the values and philosophies of WordPress – is a necessary part for success. Without such a statement, projects can (and do) get “lost” along the way, ultimately heading in a direction that is not right for core, or start off on the wrong foot entirely.

This statement of purpose should outline the justification/explanation for why the feature project should exist. This statement is not meant to be encapsulate the entire idea, but should give an idea of how the idea fits into core and its concepts. Keep in mind that a simple statement is better than a long one; comprehensive statements may be all-inclusive, but they narrow the focus in a way that might not make sense as ideas morph based on feedback.

Here are some examples of previous feature ideas – since implemented – in the form of a brief statement:

• MP6: Simplify and modernize the design of the admin, with a focus on the rapidly growing user base using HiDPI, touch, and small-screened devices.
• Widgets Customizer: Improve the WYSIWYG experience of widgets through non-destructive live previews. The current approach of making some changes immediately live but not others breaks users’ expectations and trust.

After creating and proposing a project with statement at a meeting, ideas should move through a discovery and design process (more on that below).

Once the discovery results have been put together and published, it will be proposed to the core team as an official feature project during a regularly scheduled meeting. The core team then has the opportunity to study the direction before giving it the green light to move into implementation. It’s important to question ideas and assumptions early on to ensure the design and discovery process went well and that the project heads along the best path.

Next, with the endorsement of the core team, development of the feature project can begin. Development may take the form of a plugin, a patch on a core ticket, or whatever way works best for the specific feature project.

Finally, once a feature project is fully developed, it can be proposed for inclusion in core. Proposals can take the form of a Make/Core post along the same lines as feature plugin merge proposals, or by raising the specific ticket at a weekly core devchat. As the project gets closer to the finish line, it’s recommended that the team report on its status at one of the scheduled feature project chats.

Throughout the entire process, the feature project team should hold weekly meetings, allowing others to ask questions, gather feedback, and help develop the feature.

Discovery and Design First

WordPress has always taken a user-first approach to features and often even the APIs that power these features. The benefits of this approach show in adoption and the myriad creative ways developers have found to push its limits. In the past, the project has spent time testing features after they were developed, helping determine if the features were ready for core. However, as we find in product companies and digital agencies, design (interaction, visual, etc.) should be based on data gathered from discovery with real users and happen before design and technical implementation begin.

Feature design and development should come from interviews with users, developed personas, surveys of those personas, documented flows, and other fairly standard methods. Proper discovery will allow for testing long before functional development begins using low-fidelity storyboards and walking through potential concepts with users, both verbally and visually. Projects should check in at a meeting when discovery results are available and continue to check in through the design process.

It’s important to note here that some discovery and design stages may be successful by most measures but not lead to a viable feature for core. This is okay. Going through these stages will often still lead to improvements that can be brought back to core and will help us refine feature project approaches in the future.

Conclusion

Feature plugins as a concept were a great idea; decoupling features from the release process gives us a lot of room to get things right. Adjusting our approach to cover all features – and to focus on discovery and design first – will give us a better WordPress.

Iterating on Feature Plugins by Helen Hou-Sandi was originally posted at https://make.wordpress.org/core/2016/03/31/iterating-on-feature-plugins/

WordPress 4.5 Field Guide

WordPress 4.5 is the next major version of WordPress and with it come some bang bang changes. This guide will describe many of the developer-focused changes to help you test your themes, plugins, and sites. So grab a ☕️ ,,, or  and get ready for what’s coming soon.

JavaScript! and CSS!

Multiple external libraries have been updated with the two that require your attention being Backbone and Underscore. There were some‼️ breaking changes ‼️ with these two libraries, so make sure to test your code if you use either of these.  jQuery and jQuery Migrate have also been updated, please test with the unminified versions in order to ensure future compatibility with WordPress.

The script loader has been updated with three big changes. The build process no longer creates wp-admin.min.css, wp_add_inline_script() joins the family of functions, and better support for multigenerational dependencies is included.

Term Edit Page! –‼️ Backward Incompatible change‼️

The term edit screen has been separated out from the term list screen. This brings greater consistency to how the admin generates screens for terms and posts but at the cost of the need to change how you register scripts and how you detect that you are on a term edit screen.

Live Preview: Faster, Extensible, More Features!

Live Preview (also known as “The Customizer”) once again has received attention this release with the addition of new controls, some performance improvements that require your attention to implement, and a two new user-facing features.

Setting-less Controls, Device Previews, and Selective Refresh are the three biggest changes you’ll find. Setting-less controls make it easier for you to implement complex interfaces. Device Preview is a using facing feature that allows users to adjust the preview to match the screens on various devices.  This feature includes filters to change the devices users can choose. Selective Refresh allows for changes to appear quicker inside the preview, and you can do so with less code than before. Theme authors need to make changes to take advantage of selective refresh. Luckily, the change will generally result in fewer lines of code needed overall ( more  than  ).

One area that selective refresh helps live preview function faster is with widgets.

‼️ If you offer sidebars or a widget in your theme or plugin, please update your code to implement selective refresh. Both themes and widgets need to indicate support, so please update your code accordingly.

The final change to Live Preview involves a control for a new theme feature, and that is Custom Theme Logos.

Custom Theme Logos!

Themes can now offer support for custom logos. Custom Logos add an additional way for users to customize their site and theme developers can customize how custom logos are displayed.

Image Performance!

Following up on the introduction of responsive images in WordPress 4.4, WordPress 4.5 is making changes to improve image performance including improved compression settings and smarter handling of image metadata.

Embed Templates! (and other iterations)

Iterating on embeds has led to the ability to better customize embeds by adding new templates to the template hierarchy for embeds. Embeds have also had some performance improvements for autodiscovery, the ability to embed the front page of a site, and changes to the iframe of embedded content.

Comments Component!

The comments component has a few user-facing changes to make comments easier to moderate. For developers, the most notable change is the ability to adjust field lengths for your custom database schema. Additionally, the rel=nofollow attribute and value pair will no longer be added to relative or same domain links within comment_content.

Multisite!

Multisite once again has seen changes with the addition of new filters around site and user creation, and a WP_Site object.

And more!

Overall, 372 bugs have been marked as fixed in WordPress 4.5 (so far). There are also dozens of new hooks and dozens of hooks that have received additional parameters. It’s entirely possible that one or more has caused a regression, so please make sure to test your code deeply and report any issues you find.

WordPress 4.5 Field Guide by Aaron Jorbin was originally posted at https://make.wordpress.org/core/2016/03/30/wordpress-4-5-field-guide/

Reminder – Dev Meeting Time

This is just a reminder that the dev meeting today is shifting an hour earlier today, since Europe has moved into DST.

The meeting will be at March 30, 2016 at 20:00 UTC.

We’ll chat about what’s left in the report. See you there!

Reminder – Dev Meeting Time by Mike Schroder was originally posted at https://make.wordpress.org/core/2016/03/30/reminder-dev-meeting-time/

Week in Core, Mar 22 – Mar 29 2016

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

• 30 commits
• 23 contributors
• 82 tickets created
• 9 tickets reopened
• 46 tickets closed
• RC1 released on March 25th
• Target release date for 4.5 is April 12th

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.

Administration

• Common CSS: Reset bottom padding for .nav-tab-wrapper. [37073] #35960

Build/Test Tools

• Ensure that the default wp_die() handler can handle a WP_Error object. [37071] #36166

Canonical,Canonical

• Restore the is_404() check in wp_old_slug_redirect() which was removed in [34659]. This reverts part of [34659] due to excessive canonical problems it’s caused in 4.4.x. [37075] #21602, #35344

Customize

• Bring custom-logo args closer to custom-header. [37077] #36255
• Customize: Replace site logo with custom logo terminology, fixing failure to preview logo changes. Fixes #35855. [37066] #36255, #35855

Editor

• Make the tooltip for the ‘apply’ button in the inline link dialog translatable. [37091] #36366

Embeds

• Docs: Use third-person singular verbs for summary DocBlocks in WP_oEmbed. Also [37068] #36296
• Docs: Improve and add missing DocBlocks for methods and properties in WP_oEmbed. [37067] #36296
• Docs: Standardize file headers for two embed templates introduced in [36693] for #34561. Also missed props for flixos90 on [37087]. [37088] #34561, #35986, #36352
• Docs: Reference the correct embed templates and template parts filenames in headers for embed files introduced or changed in 4.5. [37087] #34561, #35986, #36352
• Docs: Properly mark $args parameters in two WP_oEmbed methods as optional. Also clarify that the $args parameters can accept a string (the default) in addition to an array. [37069] #36296

Emoji

• Fix the diversity emoji check in Safari. [37090] #36266
• Add some extra IE11 compatibility. IE 11’s implementation of MutationObserver is buggy. It unnecessarily splits text nodes when it encounters a HTML template interpolation symbol ( “{{“, for example ). So, we join the text nodes back together as a work-around. [37089] #35977

External Libraries

• Update jQuery Migrate to 1.4.0. [37072] #35380

General

• Docs: Following [37085], properly indent the markdown-formatted examples in the DocBlock for wpdb::esc_like(). [37086] #32246
• Docs: Add missing quotes around a specifier in a query example in the DocBlock for wpdb::esc_like(). [37085] #32246
• Update TinyMCE and jQuery UI button styles. Part props liljimmi. [37076] #35571

JavaScript

• External Libraries: Update jQuery to 1.12.2. Release post: http://blog.jquery.com/2016/03/17/jquery-1-12-2-and-2-2-2-released/. Changelog: https://github.com/jquery/jquery/compare/1.12.1…1.12.2 [37070] #35380

Mail

• Correct compact() usage in wp_mail(). [37081] #35781

Query

• Query: Ignore search terms consisting of a single dash. [37082] #36195

Taxonomy

• After [36874], run the correct load-edit-tags.php hook on the new term edit page. When not misspelled, this hook is useful (and needed) for backward compatibility. Unprops swissspidy. [37084] #34988

Themes

• Docs: Improve the DocBlocks for get_header_textcolor() and header_textcolor() to mention that they both retrieve color values in the HEX format. [37083] #36336

TinyMCE

• Editor: wptextpattern: add back inline tests. See #33300. [37080] #33300
• Include the upstream fix for inserting “ while the caret is in an inline element: https://github.com/tinymce/tinymce/commit/b1618d1adb57df992ee69907b1cfff9aa4d53c80. [37074] #36165

Widgets

• Improve inline documentation syntax throughout WP_Widget. [37065] #36298
• Add missing information to the WP_Widget PHP4 constructor DocBlock. Also add several missing at @access tags to other method DocBlocks and clarify parameter docs for WP_Widget::form_callback(). [37064] #36298
• Use third-person singular verbs for method summaries in WP_Widget_Factory. [37063] #36299
• Add missing information to constructors DocBlocks for WP_Widget_Factory. [37062] #36299
• Add a missing DocBlock for the WP_Widget_Factory::$widgets property. [37061] #36299

Thanks to @ankit-k-gupta, @azaozz, @boonebgorges, @celloexpressions, @dd32, @DrewAPicture, @ericdaams, @flixos90, @iseulde, @madvic, @maweder, @mikeschroder, @obenland, @ocean90, @pento, @raimy, @ramiy, @RomSocial, @SergeyBiryukov, @swissspidy, @theMikeD, @utkarshpatel, and @westonruter for their contributions!

Week in Core, Mar 22 – Mar 29 2016 by Eric Binnion was originally posted at https://make.wordpress.org/core/2016/03/30/week-in-core-mar-22-mar-29-2016/

jQuery Updates in WordPress 4.5

jQuery was updated from version 1.11.3 to 1.12.2, see [36285], [36680], and [37070].
At the same time jQuery Migrate – the plugin to detect and restore APIs or features that have been deprecated in jQuery – was updated from 1.2.1 to 1.4.0 ([36285] and [37072]).

The non-minified version of jQuery Migrate throws a few more warnings now. See some examples from core in [36286-36288].

Please test your plugins and themes with the non-minified version to make them compatible with future versions of jQuery.

Ticket: #35380

jQuery Updates in WordPress 4.5 by Dominik Schilling (ocean90) was originally posted at https://make.wordpress.org/core/2016/03/29/jquery-updates-in-wordpress-4-5/

The Editor in WordPress 4.5

Inline Link Toolbar

From WordPress 4.5 you will be able to link text with an inline toolbar, which replaces the link modal. You will still be able to access the modal with the gear icon in the toolbar, if you’re using one of the advanced fields or are using a plugin that extends the modal. Eventually we will try to move all those fields inline, though still under an advanced toggle and not visible by default. For those interested, see #36312.

Text Patterns

We also added some more text patterns, or shortcuts if you like: `text` will change to <code>text</code> and --- (or more dashes) will change to <hr> while typing. We considered adding patterns for bold and italic, but there was no consensus yet and we’d like to test the inline text patterns first on an HTML tag mostly used by developers. See #33301.

The Editor in WordPress 4.5 by Ella Iseulde Van Dorpe was originally posted at https://make.wordpress.org/core/2016/03/28/the-editor-in-wordpress-4-5/

Video: How to Add a Full Screen Search Overlay in WordPress

WPBeginner - WordPress Tutorials originally appeared at http://www.youtube.com/watch?v=h1XdeaI1Nd8

Core Dev chat notes for March 23

Agenda

Schedule Notes, Status Updates, RC Triage.

Schedule Notes

• Release Candidate 1 will go out today, as per the release schedule.
• April 12 is the target release date for WordPress 4.5.
• Release Candidate means a soft string freeze, except the About Page.
• Also, every commit must be approved by two leads or permanent committers, and only regressions or blockers are addressed.
• In other logistics, @jorbin had a couple of comments regarding the field guide:
  • There is a firm deadline of Monday 16:00 GMT for the two remaining posts (@rmccue on the Rest API and @iseulde on Editor Shortcuts).
  • He’s planning on posting the field guide on Monday, following that deadline.

Status Updates

• Image Improvements: @joemcgill
  • Not much to report. All the remaining tickets from the Media component have been cleared. It looks like there was some movement on #36191.
• Theme Logo Support: @obenland
  • We have 2 open tickets in the queue, both possibly fixed by the same commit.
  • The goal is to make theme support arguments be closed to custom_header and remove the necessity to create a custom image size.
• Editor: @azaozz, @iseulde
  • Everything looking good, squashing some minor bugs.

RC Triage

Ticket triage continued addressing tickets in preparation for Release Candidate 1.

 

Full meeting logs in Slack.

Core Dev chat notes for March 23 by Adam Silverstein was originally posted at https://make.wordpress.org/core/2016/03/25/core-dev-chat-notes-for-march-23/

Week in Core, Mar 15 – Mar 22 2016

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

• 59 commits
• 30 contributors
• 57 tickets created
• 3 tickets reopened
• 47 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

4.5

• Post 4.5-beta4 version bump. [37027]
• 4.5-beta4 [37026]

Customize

• Prevent preview iframe from showing until fully loaded. Fixes #36276. [37060] #31195, #36276
• Add support for flex sizes in CustomizeImageCropper. [37042] #36255, #34851
• Require opt-in for selective refresh of widgets. [37040] #27355, #35855

Dashicons

• Fix incorrect ID in SVG version of font. [37037] #34221
• Updates .dashicons-googleplus (f462) and adds three new icons, .dashicons-move (f545), .dashicons-laptop (f547), and .dashicons-paperclip (f546). [37036] #34221

Docs

• Mark optional method parameters as such in Walker_Page. Also normalizes parameter spacing following [37056]. [37057] #36300
• The page object type in use in Walker_Page is WP_Post. [37056] #36300
• Improve inline documentation for properties and methods in Walker_Page. [37055] #36300
• The page object type in use in Walker_PageDropdown is WP_Post. [37054] #36300
• Improve inline documentation for properties and methods in Walker_PageDropdown. [37053] #36300
• Normalize Walker_Comment method parameter docs spacing following [37051]. [37052] #36300
• Comment display element object types for Walker_Comment are WP_Comment since 4.4.0. [37051] #36300
• Improve inline documentation syntax for Walker_Comment. [37050] #36300
• Standardize the class DocBlock summary for Walker_Comment. [37049] #36300
• Improve inline documentation for properties and methods in Walker_Comment. [37048] #36300
• Mark optional parameters in Walker_Category methods as such. Also cleans up some syntax. [37047] #36300
• Improve inline documentation for property and methods in Walker_Category. [37046] #36300
• Improve inline documentation in property and method DocBlocks for Walker_CategoryDropdown. [37045] #36300
• Change the ‘HTTPS’ column header to ‘Supports HTTPS’ in the markdown providers tables in the hook doc for the oembed_providers filter. [37039] #32246
• Add Twitter timelines and moments to the table in the hook doc for the oembed_providers filter, introduced in [36954]. [37038] #36197, #35986
• Document default WP_Ajax_Response::add() arguments as a hash notation. Adds example output to the DocBlock description based on default argument values. [37032] #32246
• Improve 4.5 changelog entries introduced in [36992] for wp_authenticate(), and the authenticate and wp_login_failed hooks. [37030] #9568, #35986
• Clarify documentation for the xmlrpc_enabled filter to better explain that its scope only extends to methods requiring authentication [37025] #21509, #36055
• Use a third-person singular verb in the DocBlock summary for WP_REST_Response::get_curies(), introduced in [36533]. Also adds a missing return description. [37015] #34729, #35986
• Improve parameter description syntax in the hook doc for the rest_request_from_url filter, introduced in [36673]. [37014] #35803, #35986
• Improve the DocBlock for WP_REST_Request::from_url(), introduced in [36673]. [37013] #35803, #35986
• Use a third-person singular verb in the DocBlock summary for WP_Customize_Site_Icon_Control::content_template(), introduced in [36698]. Also adds a missing @access notation. [37012] #33755, #35986
• Add a missing version and access information to the DocBlock for the WP_Customize_Selective_Refresh->$manager property, introduced in [36586]. [37011] #27355, #35986
• Standardize the file header and class summarries for the file containing WP_Customize_Selective_Refresh, introduced in [36586]. [37010] #27355, #35986
• Standardize the file header and class summaries for the file containing WP_Customize_Partial, introduced in [36586]. [37009] #27355, #35986
• Clarify the use of the get_currentuserinfo() for backward compatibility purposes in the DocBlock description for _wp_get_current_user(), introduced in [36651]. [37008] #19615, #35986
• Use a third-person singular verb in the DocBlock summary for wp_authenticate_email_password(), introduced in [36617]. [37007] #9568, #35986
• Add a couple of spaces before hook docs for filters introduced in 4.5. [37006] #35986

Editor

• Fix exiting DFW with the keyboard shortcut on Mac (Opt+Ctrl+W). [37003] #36222

Emoji

• The everythingExceptFlag browser support flag, introduced in [36816], wasn’t being initialised correctly. [37029] #35300
• Fix the diversity emoji check in Safari. [37028] #36266

I18N

• Move translatable Codex URLs to separate strings in wp-admin/includes/meta-boxes.php. [37016] #35751

Media

• Fix erroneously inserting a rel attribute in get_image_send_to_editor(). Reverts most of [34259] and [34260] and adds a unit test. [37035] #36084
• When generating the base URL to be used in the srcset attribute, use an https scheme when the image base URL’s host matches that of the current host, and the request is being served over HTTPS. This prevents mixed content warnings caused by http embedded media. [37022] #34945

Responsive Images

• The src of the image has to be first in the srcset, because of a bug in iOS8. Update the unit tests to reflect the changes. [37034] #35030
• Skip images with a missing $image_meta['file'] value. [37018] #35480
• Do not attempt to create srcset when the image meta is missing or corrupted. [37002] #35480

REST API

• Provide better method for generating CURIEs [37041] #34729
• Add home_url to API index to avoid confusion with site_url. [37031] #35647
• Remove unused variable $api_root from WP_Rest_Server->embed_links() method. [37021] #35803

Themes

• Twenty Thirteen, Twenty Fourteen, Twenty Fifteen: Update screenshots to 1200 x 900 [37033] #34806

TinyMCE

• Adjust textpattern tests for the changes in [37023]. [37024] #33300
• Remove *** and ___ text pattern and support for spaces in ---. The only hr text pattern is 3 or more dashes, no spaces. Remove the *, _, and __ text patterns for bold and italic. [37023] #33300

TinyMCE, Inline Link

• Add back the bottom box-shadow on the Apply button. Shrink .mce-btn.mce-primary to compensate for the bottom box-shadow. Tighten up/reduce the margins between the buttons. [37004] #33301
• Remove bottom box-shadow from the Apply button so it matches the rest. Change the tooltip for the cogwheel button to Link options. [37001] #33301

Build/Test Tools

• Allow to cache the node_modules directory. This should speed up the installation of npm dependencies. [37058] #36291
• Bump grunt-contrib-qunit ~0.7.0 → ~1.1.0 [37020] #35104
• Bump grunt-contrib-watch ~0.6.1 → ~1.0.0 [37019] #35104
• Bump grunt-contrib-jshint ~0.11.3 → ~1.0.0 [37017] #35104

Users

• In edit_user() check for a blank password when adding a user. [37059] #35715

XMLRPC

• Unit tests left off [r37043] [37044] #35874
• Fix bug where draft posts couldn’t be published in the future, and would publish immediately. [37043] #35874

Props

Thanks to @aargh-a-knot, @adamsilverstein, @azaozz, @DrewAPicture, @empireoflight, @gitlost, @iamtakashi, @jaspermdegroot, @joehoyle, @joemcgill, @johnbillion, @jorbin, @karmatosed, @liljimmi, @melchoyce, @mensmaximus, @mikeschroder, @netweb, @ocean90, @overclokk, @pbearne, @pento, @rachelbaker, @raimy, @ramiy, @redsweater, @SergeyBiryukov, @wesleye, and @westonruter for their contributions!

Week in Core, Mar 15 – Mar 22 2016 by Grant Palin was originally posted at https://make.wordpress.org/core/2016/03/23/week-in-core-mar-15-mar-22-2016/

Release Candidate and Meeting Time Reminder

Schedule

Per the schedule, WordPress 4.5 Release Candidate will be released in the hours following Wednesday’s weekly dev meeting, which is at March 16, 2016 at 2100 UTC.

For those on Daylight Saving Time – If you’re on Daylight Saving Time, the core dev meeting will continue to be an hour later for you this week, with meeting time changing to March 16, 2016 at 2000 UTC next week.

The above time link should give you the correct time and date for your local timezone.

Triage

There are currently 6 tickets in the milestone remaining. We hit the 25 ticket target before Beta 4! Thanks for all your help!

The report, minus the About Page (#36173) and tickets regarding tests, which can land at any time (#35857) must be clear before RC.

At RC, we’ll be issuing a soft string freeze, with all strings to be considered frozen minus the About Page, which should be frozen by a week before release at the latest.

As a reminder, after RC, every commit must be approved by two leads or permanent committers, and only regressions or blockers are addressed.

If you own ticket(s) on Trac in the 4.5 milestone:

• If your ticket is not going to be committed today, please punt it to Future Release.
• Please commit, or add an update as to what is left as a comment on the ticket, and why it should remain in the milestone.

We’re almost to RC. Thanks to everyone for your help!

Release Candidate and Meeting Time Reminder by Mike Schroder was originally posted at https://make.wordpress.org/core/2016/03/23/release-candidate-and-meeting-time-reminder/

Implementing Selective Refresh Support for Widgets

WordPress 4.5 includes a new Customizer framework called selective refresh. To recap, selective refresh is a hybrid preview mechanism that has the performance benefit of not having to refresh the entire preview window. This was previously available with JS-applied postMessage previews, but selective refresh also improves the accuracy of the previewed change while reducing the amount of code you have to write; it also just makes possible to do performant previews that would previously been practically impossible. For example, themes often include some variation of the following PHP and JavaScript to enable performant previewing of changes to the site title:

function mytheme_customize_register( WP_Customize_Manager $wp_customize ) {
        $wp_customize->get_option( 'blogname' )->transport = 'postMessage';
}
add_action( 'customize_register', 'mytheme_customize_register' );

function mytheme_customize_preview_js() {
        $handle = 'mytheme-customize-preview';
        $src = get_template_directory_uri() . '/js/customize-preview.js';
        $deps = array( 'customize-preview' );
        $ver = '0.1';
        $in_footer = true;
        wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
}
add_action( 'customize_preview_init', 'mytheme_customize_preview_js' );

( function( $, api ) {
        api( 'blogname', function( setting ) {
                setting.bind( function( value ) {
                        $( '.site-title a' ).text( value );
                } );
        } );
} ( jQuery, wp.customize ) );

In 4.5, the core themes now utilize selective refresh for previewing the site title and tagline. This allows the above code to be replaced with the following PHP:

function mytheme_customize_register( WP_Customize_Manager $wp_customize ) {
        $wp_customize->selective_refresh->add_partial( 'blogname', array(
                'selector' => '.site-title a',
                'render_callback' => function() {
                        bloginfo( 'name' );
                },
        ) );
}
add_action( 'customize_register', 'mytheme_customize_register' );

So as you can see, not only is the amount of code more than cut in half (also eliminating the JS file altogether), it also ensures that when a site title change is previewed it will appear with all of the PHP filters applied from core and plugins: for example wptexturize will apply so that curly quotes and dashes will appear as expected. In REST API parlance, selective refresh enables the Customizer preview to show title.rendered instead of just title.raw. (For more on this change to previewing the site title and tagline, see #33738. The previous JS-based previewing is retained for an instant low-fidelity preview while the selective refresh request returns.) Selective refresh is also the mechanism used for previewing the new custom logo feature in 4.5, ensuring that the logo image is rendered re-using the image_downsize logic in PHP without having to re-implement it in JS (keeping the code DRY).

With that recap of selective refresh out of the way, let’s turn to the focus of this post: selective refresh for widgets. When widget management was added to the Customizer in 3.9, every change to a widget required a full page refresh to preview. This resulted in a poor user experience since a full refresh can take awhile, especially on weighty pages. So selective refresh of widgets is a key usability experience improvement for widget management in the Customizer in 4.5. However, as live postMessage updates to the site title and tagline have required supporting theme code (see above), so too will theme support be required for widgets, as noted in the Selective Refresh of Widgets section from the previous post on this topic:

Selective refresh for nav menus was enabled by default in 4.3. While some themes needed to add theme support for any dynamic aspects (such as the expanding submenus in Twenty Fifteen), generally nav menus seem to be fairly static and can be replaced in the document without needing any JS logic to be re-applied. Widgets, on the other hand, have much more variation in what they can display, since they can in fact display anything. For any widget that uses JavaScript to initialize some dynamic elements, such as a map or gallery slideshow, simply replacing the widget’s content with new content from the server will not work since the dynamic elements will not be re-initialized. Additionally, the sidebars (widget areas) in which the widgets are displayed may also have dynamic aspects associated with them, such as the Twenty Thirteen sidebar which displays widgets in a grid using Masonry. For this theme, whenever a widget is changed/added/removed/reordered, the sidebar needs to be reflowed.

In order to allow themes to reflow sidebars and widgets to reinitialize their contents after a refresh, the selective refresh framework introduces widget-updated and sidebar-updated events. Additionally, since re-ordering widgets in a sidebar is instant by just re-ordering the elements in the DOM, some widgets with dynamically-generated iframes (such as a Twitter widget) may need to also be rebuilt, and for this reason there is a partial-content-moved event.

For the above reasons, I believe it will be much more common for widgets (and sidebars) to need special support for selective refresh, and so I think that at least for 4.5 the selective refresh should be opt-in for widgets (and perhaps in themes for sidebars). See theme support for Twenty Thirteen and plugin support for a few widgets in Jetpack (which won’t be part of the merge). At last week’s Core dev meeting, it was suggested that we add the opt-in for widget selective refresh at RC.

So as noted, selective refresh for widgets will be opt-in as of 4.5 RC1 (see #35855).

What do themes and widgets need to do to opt-in for selective refresh support?

Selective refresh will be used for previewing a widget change when both the theme and the widget itself indicate support as follows:

Adding Theme Support

If your theme does not do anything fancy with its sidebars (such as using Masonry to lay out widgets), then all that you need to do is add the following to your theme:

add_theme_support( 'customize-selective-refresh-widgets' );

On the other hand, if the theme is rendering a sidebar in a unique way, then to add a bit of logic to handle the changes properly. For example, as noted previously the footer area in Twenty Thirteen consists of a sidebar that is laid out using Masonry. When a widget is added, removed, or updated, the Masonry logic needs to be re-run to update the positioning of the widgets in the sidebar. The following highlighted code is what handles this:

var widgetArea = $( '#secondary .widget-area' );
widgetArea.masonry( {
        itemSelector: '.widget',
        columnWidth: columnWidth,
        gutterWidth: 20,
        isRTL: body.is( '.rtl' )
} );

if ( 'undefined' !== typeof wp && wp.customize && wp.customize.selectiveRefresh  ) {
        wp.customize.selectiveRefresh.bind( 'sidebar-updated', function( sidebarPartial ) {
                if ( 'sidebar-1' === sidebarPartial.sidebarId ) {
                        widgetArea.masonry( 'reloadItems' );
                        widgetArea.masonry( 'layout' );
                }
        } );
}

Note the if statement is there so the code will only run in the Customizer preview and if selective refresh is available (that is, if they are running 4.5 or later).

Adding Widget Support

If your widget lacks any dynamic functionality with JavaScript initialization, adding support just requires adding a customize_selective_refresh flag to the $widget_options param when constructing the WP_Widget subclass. If you are enqueueing any CSS for styling the widget, you’ll also want to enqueue this unconditionally in the Customizer preview (if is_customize_preview()) so that a widget can be added to the preview and be styled properly without doing a full page refresh. For example, note these highlighted lines in a sample widget:

class Example_Widget extends WP_Widget {

        public function __construct() {
                parent::__construct(
                        'example',
                        __( 'Example', 'my-plugin' ),
                        array(
                                'description' => __( 'Selective refreshable widget.', 'my-plugin' ),
                                'customize_selective_refresh' => true,
                        )
                );

                // Enqueue style if widget is active (appears in a sidebar) or if in Customizer preview.
                if ( is_active_widget( false, false, $this->id_base ) || is_customize_preview() ) {
                        add_action( 'wp_enqueue_scripts', array( $this, 'enqueue_scripts' ) );
                }
        }

        public function enqueue_scripts() {
                wp_enqueue_style( 'my-plugin-example-widget', plugins_url( 'example-widget.css', __FILE__ ), array(), '0.1' );
        }

        /* ... */
}

On the other hand, as with sidebars in a theme, if a widget uses JavaScript for initialization, you’ll need to add logic to make sure re-initialization happens when the widget is selectively refreshed. So in addition to the above example, you must:

1. Enqueue any dependent JS logic if is_customize_preview() just as noted above for enqueueing any CSS stylesheet.
2. Add a handler for partial-content-rendered selective refresh events to rebuild a widget’s dynamic elements when it is re-rendered.
3. As needed, add a handler for partial-content-moved selective refresh events to refresh partials if any dynamic elements involve iframes that have dynamically-written documents (such as the Twitter Timeline widget). (Adding this event handler should normally not be required.)

The Twitter Timeline widget in the Jetpack plugin is a good example for how to write these event handlers:

jQuery( function() {
        // Short-circuit selective refresh events if not in customizer preview or pre-4.5.
        if ( 'undefined' === typeof wp || ! wp.customize || ! wp.customize.selectiveRefresh ) {
                return;
        }

        // Re-load Twitter widgets when a partial is rendered.
        wp.customize.selectiveRefresh.bind( 'partial-content-rendered', function( placement ) {
                if ( placement.container ) {
                        twttr.widgets.load( placement.container[0] );
                }
        } );

        // Refresh a moved partial containing a Twitter timeline iframe, since it has to be re-built.
        wp.customize.selectiveRefresh.bind( 'partial-content-moved', function( placement ) {
                if ( placement.container && placement.container.find( 'iframe.twitter-timeline:not([src]):first' ).length ) {
                        placement.partial.refresh();
                }
        } );
} );

(This is adapted from a pending PR for Jetpack.)

Conclusion

All core themes and core widgets will have support for selective refresh in 4.5. Now it’s up to theme and plugin authors to also add support to also start taking advantage of these drastic performance improvements for previewing widget changes.

Implementing Selective Refresh Support for Widgets by Weston Ruter was originally posted at https://make.wordpress.org/core/2016/03/22/implementing-selective-refresh-support-for-widgets/

Video: How to Create a Visual Sitemap in WordPress

WPBeginner - WordPress Tutorials originally appeared at http://www.youtube.com/watch?v=tqEt4TTGgd8

Core Dev chat notes for March 16

Agenda

Schedule Notes, Status Updates, Let’s Triage!

Schedule Notes

• Beta 4 will go out today, as per the release schedule.
• Release Candidate 1 (RC1) is next Wednesday
• Thanks to the a valiant effort headed up by @chriscct7, we’re down to 23 tickets in the 4.5 milestone.

Status Updates

• Image Improvements: @joemcgill
  • Only a few open tickets left for 4.5, the big ones are related: HTTPS website with HTTP images (#34945) and Incorrect URL scheme for media in the admin area when using administration over HTTPS (#34109).
• Customizer: @westonruter, @celloexpressions
  • Two non-logo related tickets remain:  Add QUnit tests for the Customizer preview (#35857) and Selective refresh of widgets (#35855). Feedback for whether (and how) to opt-in for selective refresh support.
  • @georgestephanis offered to nudge the Jetpack team to update their widgets to support selective refresh. @westonruter submitted a PR with the required updates.
• Theme Logo Support: @obenland
  • @mor10 opened a couple of tickets that @westonruter has patched, so expect that to go in soon. Other than that it’s done. (Famous last words)
• Editor: @azaozz, @iseulde
  • Discussion around More text patterns (#33300)
  • @jorbin and @helen both suggested removing bold/italic
• @mike brought up #21602: Redirect_canonical can lead to infinite loop on index navigation if site url is not all lower case

Ticket Triage

Ticket triage continued bringing the tickets left for the milestone down to 17.

Full meeting logs in Slack.

Core Dev chat notes for March 16 by Adam Silverstein was originally posted at https://make.wordpress.org/core/2016/03/17/core-dev-chat-notes-for-march-16/

Week in Core, Mar 8 – Mar 15 2016

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

• WordPress 4.5 Beta 3 released!
• 111 commits
• 42 contributors
• 87 tickets created
• 12 tickets reopened
• 86 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

About

• Run w-logo-white.png through imagemin. [36929] #35661
• Improve color contrast of WP Badge text, and update the logo to use the latest version. [36910] #35661

Accessibility

• Improve accessibility for the Plugin details modal. [36964] #33305
• Reduce the WordPress shades of grey, Episode 3. [36904] #35783
• Improve the color contrast ratio of the expandable panel “handles”. [36959] #35923
• wpLink: fix accessibility issues [36991] #30468

Administration

• Use admin_url() for “Add New” links in wp-admin/users.php. [36902] #36186
• Use admin_url() for “Add New” links in wp-admin/upload.php. [36901] #36186

Build/Test Tools

• Add Automated Tests for custom logo support [36905] #36086, #33755
• Let’s not reinvent wp_get_attachment_image(). [36914] #36086
• Update grunt-rtlcss ~1.6.0 → ~2.0.1. [36935] #35104
• Rename the precommit:core task to precommit:base for clarification. [36955] #35557
• Introduce multisite unit tests. [36949] #33755, #36086
• Account for expected attachemnt size in custom logo output. [36911] #36086
• Update grunt-browserify ~4.0.1 → ~5.0.0 [36979] #35104
• Update grunt-postcss ~0.7.1 → ~0.8.0 [36978] #35104
• Revert r36978 [36980] #35104
• Increase beautificatedness of language in grunt precommit unit test messages. [36924] #35557
• Improve grunt precommit task [36906] #35557
• Add grunt prerelease task [36930] #35557

Comments

• On the Edit Comment screen do not show the permalink for unapproved comments. [36958] #36161

Customize

• Restore body class removed in [36837] for when custom logo is present. [36903] #33755, #35945
• Fix persistence of toggles for displayed nav menu item properties. [36908] #35273
• Reduce vertical space of site icon control. [36907] #35943
• Only add custom logo’s header text control if needed. [36915] #33755
• Update cropper.js to match changes in [36931] #32783
• Use full URL to image to prevent breakage if moved. See #33755. [36948] #33755
• Rely on selective refresh exclusively for previewing custom logo changes. [36990] #27355, #33755, #36096
• Bump down the priority custom logo’s control. [36912] #35942
• Remove selective refresh error message from appearing inline within the preview. [36890] #27355, #36164
• Remove unused JS variable to fix jshint error introduced in [36890]. [36892] #36164
• Correct a unit test for custom icon functionality. [36952] #36086
• Explicitly set full as the default custom logo size. [36950] #33755

Database

• Reset connection status variables when the connection is closed. [36997] #36240

Docs

• The $update_result parameter passed to WP_Automatic_Updater::after_core_update() is never a WP_Error. If an error is returned, the error object lives in the result property of the paramter. [36995] #32246
• Re-add a @param that went missing in [36993]. [36994] #32246
• Improvements and corrections for the $ver parameter of the dependencies API functions. [36993] #32246
• Use a third-person singular verb for the get_the_excerpt() DocBlock summary. [36942] #32246
• Improve the DocBlock summary for wp_metadata_lazyloader(), introduced in [36566]. [36941] #35816, #35986
• Improve the usefulness of the DocBlock summary for get_edit_term_link(). [36940] #32246
• Improve the 4.5.0 changelog entry in the hook doc for the get_archives_link filter, introduced in [36418]. [36939] #35573, #35986
• Improve the $blog_id parameter description in the DocBlock for the_custom_logo(), introduced in [36698]. [36938] #33755, #35986
• Improve inline documentation for has_custom_logo(), introduced in [36698]. [36936] #33755, #35986
• Improve the DocBlock summary for the_embed_site_title(), introduced in [36693]. [36923] #34561, #35986
• Improve the DocBlock summary for the clean_comment_cache action, introduced in [36405]. [36922] #35610, #35986
• Improve syntax for the $lengths parameter in the hook doc for the wp_get_comment_fields_max_lengths filter, introduced in [36272]. [36921] #10377, #35986
• Improve the DocBlock summary for wp_get_comment_fields_max_lengths(), introduced in [36514]. [36920] #10377, #35986
• Improve the DocBlock summary for wp_queue_comments_for_comment_meta_lazyload(), introduced in [36566]. [36919] #35816, #35986
• Improve the usefulness of associated reference info in the hook doc for the comments_template_query_args filter, introduced in [36235]. [36918] #34442, #35986
• Add a missing DocBlock summary for the WP_Scripts->print_html_before property, added in [36633]. [36917] #14853, #35986
• Improve syntax in the DocBlock for rest_get_server(), introduced in [36529]. [36947] #35329, #35986
• Use a third-person singular verb in the summary for get_embed_template(), introduced in [36876]. [36963] #34561, #34278, #35986
• Improve changelog entries added for the delete_term and delete_{$taxonomy} actions in [36080] and a third entry added for the clean_term_cache action in [36399] [36962] #35213, #35611, #35986
• Improve the summary and return description in the DocBlock for unregister_taxonomy(), introduced in [36243]. [36961] #35227, #35986
• Use a third-person singular verb for the DocBlock summary for remove_permastruct(), introduced in [36181]. [36960] #35235, #35986
• Improve two 4.5.0 changelog entries added for the plugins_update_check_locales and themes_update_check_locales filters, introduced in [36630]. [36966] #34937, #35986
• Correct a typo in the DocBlock summary for get_embed_template(), introduced in [36963]. [36965] #34561, #34278, #35986
• Update default $size value for get_custom_logo filter after [36950]. [36975] #33755
• Correct grammar when referring to “a URL” vs “an URL” in several places. [36970] #36218
• Improve the DocBlock summary for wp_queue_posts_for_term_meta_lazyload(), introduced in [36566]. [36945] #35816, #35986
• Improve the accuracy of the return description for unregister_post_type(), introduced in [36316]. [36944] #14761, #35986
• Improve the DocBlock summary for WP::remove_query_var(), introduced in [36177]. [36900] #35234, #35986
• Standardize file header summary for wp-includes/class-wp-metadata-lazyloader.php. [36899] #35986
• Improve inline documentation syntax throughout WP_Metadata_Lazyloader, introduced in [36566]. [36898] #35816, #35986
• Add a missing file header to wp-includes/class-wp-metadata-lazyloader.php, introduced in [36566]. [36897] #35816, #35986
• Update the return type for get_active_blog_for_user() This is now a WP_Site object. [36895] #32450
• Update param/return types for WP_Site in ms-blogs.php, get_blog_details() now returns a WP_Site object. clean_blog_cache() is now called with a WP_Site object. [36894] #32450
• Update the return type for get_current_site() This is now a WP_Network object. [36893] #32246
• Improve DocBlock syntax for wp_get_upload_dir(), introduced in [36565]. [36925] #34359, #35986

Editor

• Fix size of the resize handle on RTL sites for HiDPI screens. [36934] #36193
• Fix Mac keyboard shortcut for distraction free writing. [36973] #36214
• Hide the Move to Trash link for auto-drafts until they are auto-saved. [36972] #16116
• Correct and update the Visual and Text editors description in the screen help. [36971] #35479

Embeds

• Update Twitter oEmbed URL. [36946] #36197
• Extend the provider list to support moments and timelines from Twitter. [36954] #36197
• Add support for dai.ly embeds over HTTPS. [36951] #36189

Emoji

• Upgrade twemoji.js to version 2. [36928] #36059
• Twemoji replacements weren’t working in TinyMCE after [36816]. [36927] #35300
• Fix typo in wp-emoji.js. [36981] #35977

Media

• Fix typo in test_image_preserves_alpha_on_rotate(). [36998] #30596
• Media: Fall back to GD when loading URL in HHVM Imagick. [36996] #35973
• Progressive enhancement for Imagick; add profiles to whitelist. [36891] #33642, #28634
• Support Imagick in HHVM. [36916] #35973
• Merge two error messages and use sprintf() for the method names. [36968] #33642
• Fix typo introduced in [36887]. [36987] #36230, #36089

Posts, Post Types

• Call set_url_scheme() consistently on URLs passed through preview_post_link [36926] #35407

Query

• Ignore search terms consisting of a single dash. [36989] #36195

Rewrite Rules

• Allow rewrite rules to work in nested WordPress installations on IIS. [36953] #35558

Taxonomy

• Correct @return annotation for wp_set_object_terms() and related functions. [36896] #36182
• After [36874], rename $term_id to $tag_ID in wp-admin/edit-tag-form.php. [36969] #34988
• Fix test related to cap check in get_edit_term_link(). [36986] #35922
• Improve error handling in get_categories(). [36988] #36227

Themes

• Twenty Thirteen, Twenty Fourteen and Twenty Fifteen: Fixes #34033 [36999] #34033
• Twenty Fifteen: Simplify twentyfifteen_the_custom_logo(). [36943] #35944
• Twenty Fifteen: add support for site logos [36913] #35944
• Twenty Thirteen: Removes title attribute from footer [36956] #35843
• Twenty Eleven: Captioned image fix for editor [36957] #33153
• Support second argument in theme support for custom logo. [36909] #33755

Tiny MCE

• Update to 4.3.8, changelog: https://www.tinymce.com/docs/changelog/#version438-march152016. [37000] #36254
• Remove unused user setting for wpLink. Remove redundant text and variable from wp_link_dialog(). [36985] #33301
• Add audible confirmation when a link has been selected or inserted in the editor for both the inline dialog and the modal. Do not auto-search when the URL field is empty or already contains an URL. Remove a few redundant tabindex. [36984] #33301
• When dragging, prevent error when a range cannot be created at the drop location. [36983] #36229
• When doing undo/redo with keyboard shortcut, do not focus the inline dialog. Cannot do consecutive undo/redo if the focus is moved away from the editor. [36982] #33301
• Ensure the inline dialog is in preview mode after updating a link from the (advanced) modal. [36977] #33301
• Tweak the small animation shown while waiting for wpView data to make it sell CPU intensive. [36976] #33525
• When searching, do not empty the URL input field when using the arrow keys to highlight items. [36974] #33301

Users

• Add @since entries to wp_authenticate() and its filters now that the $username parameter can also be an email address. [36992] #9568, #35986

 

Thanks to @celloexpressions, @davidakennedy, @drebbitsweb, @hugobaeta, @iamtakashi, @@iseulde, @adamsilverstein, @afercia, @ahockley, @arush, @azaozz, @boonebgorges, @celloexpressions, @Chouby, @claudiosanches, @danielbachhuber, @DrewAPicture, @DuckDagobert, @ericlewis, @iseulde, @jeremyfelt, @joemcgill, @johnbillion, @johnjamesjacoby, @jorbin, @juliobox, @karmatosed, @markoheijnen, @melchoyce, @mikeschroder, @netweb, @niallkennedy, @obenland, @ocean90, @pento, @programmin, @rachelbaker, @RomSocial, @sebastianpisula, @SergeyBiryukov, @swissspidy, @tywayne, @virgodesign, @westonruter, @wido, @WiZZarD_, and @wonderboymusic for their contributions!

Week in Core, Mar 8 – Mar 15 2016 by Andrew Rockwell was originally posted at https://make.wordpress.org/core/2016/03/16/week-in-core-mar-8-15-2016/