PHP Meeting Recap – November 13th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

The meeting’s chat log.

Attendees: @flixo90 @jdgrimes @jon_bossenger @mikelking @mte90 @nerrad @schlessera

@sergey

Chat Summary

We started the meeting by examining the poll that @flixos90 had made regarding a modified meeting time slot.

As most of the votes went to the 16:00 UTC time slot, and nobody had a specific reason for not using that time slot, we decided to make that new time official from now on.

This means that all subsequent meetings are held at 16:00 UTC from now on.

Then we continued working on the “Before Upgrading PHP” section again, which we are working on in a shared Google Doc.

Here’s a brief summary of the corresponding discussions and decisions:

  • We discussed adding a second “Backup” step after all updates have been done. In case of a rollback further down the line, this would avoid going through all updates again, which incur a big time and bandwidth hit.
  • While discussing how to best add this addition “Backup” step, we came up with the idea of adding small “aside” text boxes to the document, which visually communicate that the content therein is not part of the critical path and should not be considered a blocker in case the user can’t complete that “aside”.
  • We discussed the different animals that Google Docs assigned to the anonymous users, and how they don’t seem to match up everywhere. 😉
  • Regarding the compatibility checker, we discussed whether to include knowledge about the future XWP project that might have an impact here, or not. We decided that we write the content for the current state and context, as there’s no guarantees to when or if any of the WIP projects will be completed and usable.
  • We added an aside to the compatibility checker as well, to warn users against false positives and other detection issues.
  • We acknowledged that our aside might be a bit on the intimidating side, and that we need the help of the #marketing team to rephrase the copy in that regard.
  • We rewrote the “Ask plugin/theme support” topic so that it is clearer and points people to existing resources first before contacting support.

Next week’s meeting

The next meeting will take place on Monday, November 20, 2017 at 16:00 UTC, as always in #core-php, and its agenda will be to finish the rest of the “Before Upgrading PHP” document that we will hand over to the marketing team to get their help with writing the copy. If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account. See you next week!

#core, #core-php, #php, #summary

WordPress 4.9 final nightly build

As noted in the 4.9 release delay post, a final nightly build is now available for testing. This includes three commits, so please take a look through those and test as you can (see #42548, #42530, and #42545).

We hope to ship WordPress 4.9 on Wednesday, November 15th (that’s tomorrow) at 23:00 UTC, but we still need your help to get there. If you haven’t tested 4.9 yet, now is the time!

If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you! If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

We are almost there
But we still need help testing
So test, please and thanks!

Thanks for your continued help testing out the latest versions of WordPress.

#4-9

WordPress 4.9 release delayed by one day

The 4.9 release was due out today (November 14th), however issues with shortcodes within widgets (#42548) and changes to the Editor (#42530) occurred during release preparations. The new target release date is tomorrow (November 15th). It doesn't serve anybody well to delay things this late in the day, but it's essential to ensure the late fixes which have landed in the last few days are well tested.

We will do a release dry-run today at November 14th, 23:00 UTC23:00 UTC in #core after the code freeze, depending on the availability of the lead devs. An update will be posted that includes a link to a nightly build after the code freeze.

We've re-scheduled the 4.9 release to occur tomorrow at November 15th, 23:00 UTC / 23:00 UTC.

Nav Menu Improvements in the Customizer in 4.9

In our usability tests with prior releases, we identified two common problems users encountered when trying to create a menu.

  1. Clicking the Add a Menu button in an attempt to add a page to their new menu.
  2. Forgetting to assign the menu to a location.

In WordPress 4.9, we’ve updated the Customizer’s menu creation flow to address these issues.

An Updated Menus Panel

The Menus panel layout and copy have been updated for clarity. The panel now shows menus first and locations second. This puts menus front and center and allows the panel to adjust more easily to specific scenarios. For example, when there are no menus, the panel asks users to create a menu and explains the steps to be taken.

Before After

Menu Creation

When the user clicks Create New Menu, the Customizer opens a dedicated menu creation section. Using a dedicated section allows us to guide the user through each step of menu creation. We start by inviting the user to provide a clear name for the menu and to select its new location. Once the menu is created, we guide them to add menu items and highlight the Add Items button if the user doesn’t find it after a short time.

Create a Menu for a Location

The locations section now allows the user to create a menu for a location that has not been assigned a menu. When the user clicks a location’s Create New Menu link, the Customizer opens the Menu Creation section with the location preselected.

Deprecated UI Classes

With the addition of a dedicated menu creation section, a number of classes are no longer used and are being deprecated.

The following PHP classes have been deprecated along with their files:

  • WP_Customize_New_Menu_Control in
    wp-includes/customize/class-wp-customize-new-menu-control.php
  • WP_Customize_New_Menu_Section in
    wp-includes/customize/class-wp-customize-new-menu-section.php

The following JS class has been deprecated (but not its containing file):

  • api.Menus.NewMenuControl in
    wp-admin/js/customize-nav-menus.js

Related Tickets

  • #40104 Customizer: Improve menu creation flow
  • #36279 Add an “add new menu” button to the menu locations section in the customizer
  • #42114 Customize Menus: UX Improvements
  • #42116 Customize Menus: Add “It doesn’t look like your site has any menus yet” view
  • #42357 NewMenuControl class has been removed from trunk

#4-9, #customizer, #dev-notes

WordPress 4.9 Field Guide

WordPress 4.9 is officially the best release ever (that rhymes with Shore Joint Twine)!  Users have safer and more flexible ways to edit code, new and improved widgets, and improvements to customizing their site while developers will be able to take advantage of 188 enhancements and features added.  Let’s look at the many improvements coming in 4.9…

Widgets: now new and improved

Galleries aren’t just for posts anymore, now they can get all up in your sidebars. That’s a good thing, if you’re into that sort of thing. On top of that your text widget now supports shortcodes, images, galleries, videos, audio, and other media. Oh, and the text widget now supports embeds, so go ahead and drop a YouTube clip in that widget.

Introducing the Gallery widget

Widget Improvements in WordPress 4.9

WordPress and CodeMirror sitting in a tree…

Something something I-D-E. Ever wondered what an IDE would look like inside WordPress? Do you use Notepad as your IDE? No? Great, then you’ll love the syntax highlighting, linting, and auto-completion functionality within the Customizer’s Additional CSS feature, the Custom HTML widget, and the Plugin and Theme file editors!

Code Editing Improvements in WordPress 4.9

🔎, 🏗️, and 👓 Themes in the Customizer

That’s emoji for browsing, installing, and previewing, but you knew that already. The Customizer now includes a new experience theme browsing and live-previewing themes, as well as—for the first time—installing new themes from WordPress.org in the process. Don’t believe us? Then give it a try with your favorite theme!

A New Themes Experience in the Customizer

Changesets

Quick, what’s your favorite sequel? If you said Caddyshack 2, then we need to have a little chat. If you said Changesets 4.9, then you’re correct! Get ready to learn all about Drafting, Scheduling, Autoloading, and Linear/Branching Modes, Autosaving Auto-Drafts and Autosave Revisions, Post Locking, and Customization Drafts. Yes, all of that is in 4.9. You’re welcome.

New Features and Enhancements with Customizer Changesets in 4.9

Nav menu creation flow

Ever had problems working in the Customizer and adding a page to a menu or forgetting to assign a menu to a location when trying to create a menu? The Customizer’s menu creation flow has been updated to address these issues.

Nav Menu Improvements in the Customizer in 4.9

The A(PI)-Team

If you have a problem, if no one else can help, and if you can find them….maybe you can hire The A(PI)-Team. The Customizer JS API improvements in 4.9 fix many longstanding annoyances and shortcomings with the JS API. Additionally, a REST API update now effectively requires named URL parameters and thus no longer allows regular (numeric) matches.

Improvements to the Customize JS API in 4.9

Improvements in REST API request parameter regular expressions

Multisweet multisite multimprovements

Run a network of sites? Then pour yourself some coffee and dig into all the multigoodies in 4.9. New functions and filter, replaced functions, capability and role updates, and some security improvements all come along for the ride on the multisite train.

Multisite Focused Changes in 4.9

Users and security updates

Were you hoping for new capabilities for activating and deactivating plugins plus installing and updating language files, capability security hardening, changes to how multisite handles switching roles and capabilities, and security improvements to how email addresses get updated in 4.9? If so, you’re going to be happy. If not, you should still be happy.

Improvements for roles and capabilities in 4.9

Account Security Improvements in WordPress 4.9

Don’t Press That

Press This is no longer in core, but can be found via a “canonical” plugin. Cry if you want to, but the functionality still exists so cheer up!

Press This in 4.9

 

ME.js updates.js

If.js I.js could.js think.js of.js something.js witty.js related.js to.js the.js ME.js.js updates.js, then.js I.js would.js have.js wrote.js that.js here.js. Instead.js… .js.js all.js the.js things.js.

MediaElement upgrades in WordPress 4.9

Updates for screen readers

As usual, we saved the best for last! Modernization and standardization comes to the screen-reader-text CSS class.

Changes to the screen-reader-text CSS class in WordPress 4.9

But Wait, There is More!

Roughly 400 bugs, 181 enhancements, 7 feature requests, and 42 blessed tasks have been marked as closed in WordPress 4.9.

Please, test your code. That bears repeating: Please, test your code. Fixing issues now, before 4.9 is released, helps you and helps millions of WordPress sites. Please. Test. Your. Code.

#4-9, #dev-notes, #field-guide

Core editor meeting time change

As Daylight Saving Time ended for all countries it applied to (finally) this Sunday, November 5th, we will shift the time for the #core-editor chat starting this week on Wednesday, November 8, 2017 at 18:00 UTC / Wednesday, November 8, 2017,18:00 UTC. See you then!

New Features and Enhancements with Customizer Changesets in 4.9

In WordPress 4.7 the concept of changesets was introduced in the Customizer (#30937). To understand the new Customizer improvements in 4.9, you must first go back and review what was proposed and implemented a year ago:

Customize Changesets Technical Design Decisions

Changesets are a way to persistently store changes made via the Customizer framework. Changesets contain the pending changes for any number of settings, and a setting can model any object in WordPress—whether options, theme mods, nav menu items, widgets, or even posts/pages and their postmeta. Changesets are identified by UUID (which is the post_name for the customize_changeset post type that stores the data as JSON in post_content). When a request is made to WordPress with the customize_changeset_uuid request param—whether to the frontend or to the REST API—the Customizer framework will bootstrap and all of the values from the changeset will be read and applied to the response via WordPress filters added by the settings’ respective WP_Customize_Setting::preview() methods.

Only an authorized user can write changes into a changeset for a given setting (according to its respective capability). But once it has been written then anyone can preview the site with the changes in the changeset applied: all that is needed is the UUID. Since previewing a changeset is now a readonly operation (whereas before 4.7 it was always a POST request), a changeset can be previewed on a site by authenticated and unauthenticated users alike. With the changeset UUID supplied when opening the Customizer, a user can keep iterating on a set of changes over several days or longer and only publish them once stakeholders are satisfied. Now, freelancers and agencies will be better able to communicate and collaborate on site changes with clients.

Once a customize_changeset post transitions to the publish status then all of the values in the changeset will be passed into their respective WP_Customize_Setting::update() methods to publish (“go live”) on the site: in version control terminology, the staged values from the changeset get committed and pushed. All of the changes go live together in a batch save operation (originally changesets were termed “transactions”).

As noted in the 4.7 merge proposal:

For the initial core merge, no UI changes are being proposed. The feature will only be exposed as the new query parameter on the URL. Adding a UI to this feature will happen in a future release.

The future [release] is now. Where the infrastructure of changesets was merged from the Customize Changesets feature plugin in 4.7, the key UI features from the plugin are now being merged in 4.9 after a significant number of design iterations.

This dev note contains sections on the following:

Continue reading

#4-9, #customize, #dev-notes

Press This in 4.9

In WordPress 4.9, Press This has found a new home as a “canonical” plugin.

Proposed in #41689 and committed in r41584, Press This and the supporting functions are no longer in Core at all. This is notably different than the Link Manager deprecation, which left all of the code in Core but deactivated behind a filter. If you are extending the WP_Press_This class, you will need to update your plugin or theme as it is no longer present in Core.

When someone visits wp-admin/press-this.php, they are given a prompt to install the new plugin or to notify their administrator to install it:

If installing it through the prompt above, the activation flow will return them to Press This:

If you are extending Press This or are depending on functionality from it, you can see how to check for plugin availability via 4.9’s wp-admin/press-this.php and please comment on #37938 discussing if some of the parsing functionality of Press This would be beneficial ported back into Core.

In the new plugin, older bookmarklets will no longer function and this feature is discontinued. Usage of bookmarklets across the web has decreased significantly and bad actors attempting to trick users to preform unsavory actions increased over the years. Coupled with advancing toward a new editing in experience in Core, we decided it was a suitable time to make these changes in one swift move.

Continued development of Press This will happen at https://github.com/WordPress/press-this/ and I hope those who like the streamline editing experience will continue to contribute. Short-term goals include switching to the REST API instead of admin-ajax and tweaking the current experience.

#4-9, #dev-notes

Improvements to the Customize JS API in 4.9

There are many user-facing Customizer improvements in 4.9, including: drafting/scheduling of changesets, autosave revisions, changeset post locking, frontend public previews, a new experience for browsing and installing themes, updated nav menu creation UX, and the code editing improvements for the Custom HTML widget and Additional CSS. But in addition to all of these, there are also many improvements for developers which will make extending the Customizer much more pleasant.

Something important to remember about the Customizer is that it is a single page application that is powered by JavaScript. Many developers may only interact with the PHP API for registering controls, settings, sections, panels, and partials. But controls, sections, and panels do not need to be registered in PHP at all. The PHP API for registration is essentially a wrapper for the underlying JS API. When you load the Customizer all of the params for the PHP-registered constructs are exported to the client for the JavaScript API to instantiate and initially add to the UI, but this JS API can dynamically instantiate additional constructs at any time thereafter in a Customizer session. This is how new widgets, nav menus, and nav menu items are added without requiring the entire Customizer to reload. You can also avoid statically registering settings and partials in PHP by instead adding filters to dynamically recognize settings and partials, allowing them to be registered on demand. All of this allows the Customizer application to scale out to be able to customize and preview an unlimited number of things on a site (e.g. any post or page with their postmeta in the Customize Posts feature plugin). The point here is that in order for the Customizer to scale, the JavaScript API must be used directly. So this is why the Customizer JS API improvements in 4.9 are important as they fix many longstanding annoyances and shortcomings with the JS API.

This dev note contains the following sections:

Continue reading

#4-9, #customize, #dev-notes

Changed behaviour of esc_sql() in WordPress 4.8.3

As part of the WordPress 4.8.3 release, there is a change in `esc_sql()` behaviour that may affect plugin developers who expect `esc_sql()` to return a string that’s usable outside of the context of building a query to send to WPDB.

While we strongly recommend you do not use `esc_sql()` for other purposes, we understand that it can be tricky to rewrite old code rapidly. To return to the old behaviour, you can use the `$wpdb->remove_placeholder_escape()` method, like so:

echo esc_sql( "100%" );
// "100{9fa52f39262a451892931117b9ab11b5a06d3a15faee833cc75edb18b4411d11}"

echo $wpdb->remove_placeholder_escape( esc_sql( "100%" ) );
// "100%"

#4-8, #4-8-3, #dev-notes, #wpdb