Dev Chat Summary: November 11 2020

Hello! Here’s what happened in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. dev chat on November 11, 2020 at 0500 UTC and November 11, 2020 at 2000 UTC, following this agenda.

05:00 UTC core dev chat

@peterwilsoncc facilitated the meeting and @mikeschroder took notes. Find the full Slack archive here.

20:00 UTC core dev chat

@laurora facilitated the meeting and @thewebprincess took notes. The full Slack archive can be viewed here.

Announcements

The WP 5.6 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. 4 has been delayed and will now be released around November 12, 2020 at 2000 UTC.

Highlighted Posts

And recent posts on the Make/Core blogblog (versus network, site) to highlight are:

Updates from Component Maintainers/Focus Leads

General: PHP8 is scheduled for November 26th, please see the PHP 8 call for testing to ensure we are ready before RC 1 scheduled for launch on November 17th. @desrosj is working on the dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..

Site Health: Most remaining patches complete for 5.6. Dev notes remaining.

Open Floor

@mikeschroder asked for help with getting PHP8 working with the automated hosting tests, as it’d be great to have hosts running the core tests with PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8 before 5.6 is released. Logs from that discussion found here.

@joostdevalk sparked a lively discussion with the following statement “If we enable auto-updates for core, we should default to it for all plugins too.” It is worth reviewing the conversation.

Finally, @helen put the call out for people to leave their thoughts/comments regarding Dark Mode in Twenty Twenty-One on the recent post.

Next Dev Chat meetings

The next meetings will take place on November 18, 2020 at 0500 UTC and November 18, 2020 at 2000 UTC in the #core 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. Please feel free to drop in with any updates or questions.

Props to @thewebprincess helping to compile these notes, @hellofromtonya for proofing, and @davidbaumwald for final review.

#5-6, #dev-chat, #summaries, #summary

Auto-update test scrub for WordPress 5.6

As part of the 5.6 release, we’ll be hosting an auto-update focused test scrub this 11/13/2020 13:30 UTC in the #core channel on 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/..

In particular, test different use-cases of the feature:

  • New installation for minor version
  • New installation for major version
  • Upgrade for major version

On single and 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.

If you want to contribute to this feature by testing, please join us and share your valuable feedback.

You can read more about auto-updates status and progress on two recent blogblog (versus network, site) posts

What you need

  • Test website
  • WordPress 5.6 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. 4 (coming out later today)

Looking forward to testing with you!

#5-6, #test, #testing

Dev Chat Agenda: 11th November 2020:

Here is the #agenda for this week’s meetings happening at:
Wednesday, 11 November 2020, 0500UTC and Wednesday, 11 November 2020, 2000UTC .

The #dev-chat meetings will be held on Wednesday, 11 November 2020, 05:00UTC and Wednesday, 11 November 2020, 2000UTC. These meetings are held in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack .

#5-6, #agenda

WP5.6 | Auto-Update Implementation Change

Hey Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org.! Last week in 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/. there was a lively (and lengthy) discussion on the auto-updates UIUI User interface (transcript). This post summarizes the discussion and most reasonable options for moving forward, considering timing, availability, and level of effort for suggested changes.

Summarized Concerns

  • Is this implementation aligned with our long term goals: to have auto-updates widely available in order to increase the collective health of all WordPress sites, minimize the maintenance burden for users, and have greater security across the entire ecosystem.
  • Is this implementation aligned with our short term goals: to continue our existing progress around auto-updates for minor releases, plugins, and themes.
  • A desire to avoid reverting elements of the UI and auto-updates after the release.
  • There were a vast array of concerns around the implementation.

Path Forward

One of the clearest things that came up in the conversation during coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. chat is that this is a complex technical task, and there will be a need for some long term, dedicated time to keep driving this work forward. Specifically, there is a shared concern that there is a technically non-trivial combination of reassurance and repair features that need to be defined and executed on and will need a dedicated product owner (transcript).

This Release and Next

  • WP5.6: Provide some updates to the design of the UI.
  • WP5.6: For existing installations, the behavior will remain the same as it is today: opted-in to minor updates by default, but a user must opt-in to major updates (constants and filters that are already in use by hosts or agencies will still take precedence).
  • WP5.6: For new installations, default behavior will change: opted-in to minor updates by default and opted-in to major updates by default.
  • WP5.6.1: Revisit the UI to revise based on feedback.
  • WP5.7Add a nudge on the Site Health screen for anyone opted out of major updates.
  • WP5.7Add auto-updates opt-in to installation flow.

Future Release Suggestions

  1. WP5.x: Add a nudge to opt-in on the updates page and a path to opt-out on Site Health.
  2. WP5.x: In a future release, have a renewal flow after a certain period of time.

Planning for the Future

The subject of auto-updates has resulted in many complicated discussions. As I reminded the release squad, decisions like these require us to remember that we’re contributing to over 30% of the web, and we have to balance our immediate needs with long term planning.

It’s important that whatever we implement isn’t taking us further away from our long term goals of having seamless, auto-updates across the project. Auto-updates can help us have a more secure WordPress ecosystem, and in turn can help change the public perception of WordPress being an unsecure choice for users of any skill level.

To provide some clarification on the nine project goals set out in 2019, the wording there is specific about implementing “opt-in to automatic updates of major Core releases”. However, the long term goal (for Matt as well as many of the contributors to WP3.7) was to have all installations opted-in to auto-updates of WordPress core by default, and that is still the long term goal.

Props to the WordPress 5.6 release squad for bringing such care to this discussion, and to @helen for helping me on the implementation wording. Special thanks to @audrasjb and @davidbaumwald for editing, and @andreamiddleton, @daisyo, and @cbringmann for proofreading!

#5-6, #auto-updates

WordPress 5.6 Beta 4 delayed from November 10th to November 12th, 2020

During the November 4th core chat, some questions were raised about the readiness of the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. auto-update feature, scheduled to land in WordPress 5.6. Questions ranged from the implementation of it to the scope of the output desired. A separate post is coming with more information on that discussion and the planned next steps.

In order to allow some more time to refine the work done so far, WordPress 5.6 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. 4 will be delayed from today, November 10th, to Thursday, November 12th, 2020.

At this moment, no delay is expected on the release: everyone is working to make WordPress 5.6 available on December 8th.

Thank you to @francina who helped me craft this draft. 🙂

#5-6, #auto-updates, #core-auto-updates

Twenty Twenty-One Test Scrub

As part of the 5.6 release, we’ll be hosting a Twenty Twenty-One focused test scrub today Friday, November 6, 2020, 13:30 UTC in the #core channel on 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/..

What we will test

  1. UXUX User experience/UIUI User interface of dark-mode, in particular, https://github.com/WordPress/twentytwentyone/issues/790
  2. Bugs that need testing after WordPress 5.6 Beta 3: https://core.trac.wordpress.org/tickets/needs-testing – those marked as “Next release”

How we will test

  • We will go through each item as a group.
  • We will create a thread in Slack for each items where you can post the results. This will make it easier to reply in the existing issues or create new ones.

What do you need to test

  • WordPress 5.6 Beta 3 installed
  • To test TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. patches, you need a development environment
    • https://make.wordpress.org/core/handbook/testing/patch/
    • https://make.wordpress.org/core/2020/09/29/test-scrub-for-wordpress-5-6/#comment-39945

See you later!

#5-6, #bug-scrub, #test, #twenty-twenty-one

Application Passwords: Integration Guide

WordPress 5.6 will finally see the introduction of a new system for making authenticated requests to various WordPress APIs — Application Passwords.

The existing cookie-based authentication system is not being removed, and any custom authentication solutions provided by plugins should continue to operate normally.

For any sites using the Application Passwords feature plugin, it is recommended to deactivate 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 after upgrading to WordPress 5.6. However, sites won’t experience any errors if the plugin remains active. The current plan is to use the plugin for future prototyping.

Application Password Format

Application Passwords are 24-characters long, generated by wp_generate_password() without the use of special characters — so they consist exclusively of upper-case, lower-case, and numeric characters. For the cryptographically curious, that comes to over 142 bits of entropy.

When presented to the user for entering into an application, they are displayed chunked for ease of use, like so:

abcd EFGH 1234 ijkl MNOP 6789

Application passwords can be used with or without the spaces — if included, spaces will just be stripped out before the password is hashed and verified.

Data Store

WordPress will be storing a user’s application passwords as an array in user 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., similar to how interactive login sessions (via WP_Session_Tokens) are stored already.

The WP_Application_Passwords class has all the methods for storing and retrieving records. Records include a number of attributes about them — including assigned name for the application, a timestamp for when it was created, and data on their last usage such as, date and IP address. Each application password is also assigned a uuid for reference, in case you’d like to build infrastructure for additional properties and store them in an alternate location.

Getting Credentials

Generating Manually

From the Edit User page, you can generate new, and view or revoke existing application passwords. The form and the list table are both fully extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. to allow for overloading to store additional data (more on this later, in “Authentication Scoping”).

The Application Passwords section of Edit User screen, after a new application password has been created.
The Edit User screen, after a new application password has been created.

Once a given password has been used, it will keep track of where and when it has been used – the “Last Used” column is accurate to within 24 hours (so that WordPress isn’t writing to the database on every usage — only if it’s a new day). This can be incredibly useful for identifying passwords that are no longer in use, so that they can be safely revoked.

Authorization Flow

To ensure that application password functionality is available, fire off a request to 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/. root URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, and look at the authentication key in the response data. If this key is empty, then application passwords are not available (perhaps because the request is not over https:// or it has been intentionally disabled).

If, however, response.authentication is an object with a key of application-passwords it will offer a URL to send a user to complete the authentication flow. (You could just guess at the URL, but this gives us more of the relevant information in one go, as well as confirming that application passwords are available and enabled.)

The response.authentication['application-passwords'].endpoints.authorization url will likely look something like this:

https://example.com/wp-admin/authorize-application.php

Instead of just sending the user there to generate an application password, it would then be up to the user to reliably re-enter it into your application. So instead, some additional GET parameters are accepted along with the request:

  • app_name (required) – The human readable identifier for your app. This will be the name of the generated application password, so structure it like … “WordPress Mobile App on iPhone 12” for uniqueness between multiple versions.
    Whatever name you suggest can be edited by the user if they choose before the application is created. While you can choose to not pre-populate it for the user, it is required to create a password, so they will then be forced to create their own, and could select a non-intuitive option.
  • app_id (recommended) – a UUID formatted identifier. The app_id allows for identifying instances of your application, it has no special meaning in and of itself. As a developer, you can use the app_id to locate all Application Passwords created for your application.
    In the event of a data breach, your app_id could be distributed to void credentials generated with it, or if a site wants to allow only a given app_id or set of app_ids to register, this would enable that. However, it is strictly on the honor system — there is nothing to stop applications from generating new uuids with every authorization.
  • success_url (recommended) – The URL that you’d like the user to be sent to if they approve the connection. Three GET variables will be appended when they are passed back (site_url, user_login, and password); these credentials can then be used for 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. calls.
    If the success_url variable is omitted, a password will be generated and displayed to the user instead, to manually enter into their application.
  • reject_url (optional) – If included, the user will get sent there if they reject the connection. If omitted, the user will be sent to the success_url, with ?success=false appended to the end.
    If the success_url is omitted, the user just will be sent to their WordPress dashboard.
A screenshot of the new Authorize Application screen in the WP-Admin. A button is displayed to approve the connection, and one to reject the connection.
A screenshot of what the authorization flow will look like to a user.

As the parameters are all passed in via GET variables, if the user needs to log in first, they will all be preserved through the redirect parameter, so the user can then continue with authorization.

It is also worth noting that the success_url and redirect_url parameters will generate an error if they use a http:// rather than https:// protocol — however other application protocols are acceptable! So if you have a myapp:// link that opens your Android, iOS / MacOS, or Windowsthose will work!

Here is an example of a simple javascript application (under 100 lines of code) that uses this to authenticate to a WordPress site. Though not the tidiest code, it was created in under two hours one evening, but it goes through the proper flows and can make authenticated requests.

Programmatically through the REST API

If you have previously been using a different system to access the REST API and would prefer to switch over to using application passwords, it’s easy! You can generate yourself a new application password via a POST request to the new /wp/v2/users/me/application-passwords endpoint. Once you’ve got the new application password in the response data, you can delete any old credentials and just use the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. implementation instead — but please consider using something like libsodium (which has a library bundled with WordPress alreadyhere’s an implementation example) or Vault to store the credentials encrypted, rather than in plaintext.

Using Credentials

REST API

The credentials can be passed along to REST API requests served over https:// using Basic Auth / RFC 7617, which is nearly ubiquitous in its availability — here’s the documentation for how to use it with cURL.

For a simple command-line script example, just swap out USERNAME, PASSWORD, and HOSTNAME in this with their respective values:

curl --user "USERNAME:PASSWORD" https://HOSTNAME/wp-json/wp/v2/users?context=edit

XML-RPC API

To use a generated application password with the legacy XML-RPC API, you can just use it directly in lieu of the account’s real password.

For a simple command-line script example, again just swap out USERNAME, PASSWORD, and HOSTNAME in this with their respective values:

curl -H 'Content-Type: text/xml' -d '<methodCall><methodName>wp.getUsers</methodName><params><param><value>1</value></param><param><value>USERNAME</value></param><param><value>PASSWORD</value></param></params></methodCall>' https://HOSTNAME/xmlrpc.php

Future 🔮 APIs

The application passwords authentication scheme can also be applied to future APIs for WordPress as they become available. For example, if GraphQL or other systems are enabled in WordPress, application passwords will provide them with a solid, established authentication infrastructure to build off of out of the box.

As an example of this, with a trivial code addition identifying whether the current load is an api request, WPGraphQL will now be able to accept authenticated requests without the need of an ancillary plugin, using just the application passwords functionality that has merged into core.

Using an Application Password on wp-login.php

You can’t. 😅 The point of application passwords are that they are to be used programmatically for applications, and not by humans for interactive sessions.

Feature Availability

By default, Application Passwords is available to all users on sites served over SSLSSL Secure Sockets Layer. Provides a secure means of sending data over the internet. Used for authenticated and private actions./HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information.. This can be customized using the wp_is_application_passwords_available and wp_is_application_passwords_available_for_user filters.

For example, to completely disable Application Passwords add the following code snippet to your site.

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Without SSL, it is possible for the Application Password to be seen by an attacker on your networknetwork (versus site, blog) or the network between your site and the authorized application. If you are ok with this risk, you can force availability with the following code snippet.

add_filter( 'wp_is_application_passwords_available', '__return_true' );

If desired, it is possible to restrict what users on your site can use the Application Passwords feature. For example, to restrict usage to administrator users, use the following code snippet.

function my_prefix_customize_app_password_availability(
	$available,
	$user
) {
	if ( ! user_can( $user, 'manage_options' ) ) {
		$available = false;
	}

	return $available;
}

add_filter(
	'wp_is_application_passwords_available_for_user',
	'my_prefix_customize_app_password_availability',
	10,
	2
);

Future Development

Authentication Scoping

In future versions, the expectation is to include the ability to scope a given application password to limit its access. The intention is to work on building this in plugin-land until it’s ready for a core proposal.

What might password scoping look like? Here’s some methods being considered:

  • In a 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 environment, either restrict the credentials to a subset of the user’s blogs, or restrict it to only operate in a normal “blogblog (versus network, site) adminadmin (and super admin)” context, and not a “network admin” context.
  • Restrict functionality to only manage content — posts, pages, comments, custom post types — and disallow infrastructure management functionality like managing plugins, themes, and users.
  • Restrict the role that credentials can allow an application to operate as. For example, an Editor may restrict a set of credentials to only operate as though they had Author or Contributor permissions.

However this is done, implementing additional functionality to enforce the principle of least privilege on an application-by-application basis is a worthwhile expansion on the included functionality.

Fine-grained Capabilities

Right now, a user’s application passwords can be managed by any user who has permission to edit_user them. The ability to customize this behavior using a new set of more fine-grained capabilities is currently planned for 5.7.

Eventually Two-Factor Authentication?

Another useful bit of application passwords is that it will removes an obstacle for the inclusion of multi-factor authentication on interactive logins.

Previously, if you enabled an interactive step — whether captcha or second factor validation — on login pages, you would be in a bind with other non-interactive authentications, for example the legacy XML-RPC system. After all, if a bad actor can just brute force or use social engineering to discern the user’s password, it would be trivially usable via XML-RPC, where there is no ability to include an interactive prompt, and that functionality would need to be disabled entirely.

With that use case now being provided for via application passwords, there is additional flexibility for the normal browser-based wp-login.php system to evolve.

Further Resources

For 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. reports or enhancements, open a Trac ticket in the new App Passwords component with the rest-api focus.

Props @timothyblynjacobs, @m_butcher, @desrosj, @jeffmatson, for helping to write, review, and proofread.

#5-6, #application-passwords, #authentication, #core-passwords, #dev-notes, #rest-api, #two-factor

Dev Chat Summary: November 04 2020

Hello! Here’s what happened in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. dev chat on Wednesday, November 4, 2020, 05:00 UTC and Wednesday, November 4, 2020, 20:00 UTC, following this agenda.

05:00 UTC core dev chat

@thewebprincess facilitated the meeting and took notes. Find the full Slack archive here.

20:00 UTC core dev chat

@thelmachido facilitated the meeting and @laurora took notes. The full Slack archive can be viewed here.

Both groups followed this agenda: https://make.wordpress.org/core/2020/11/04/dev-chat-agenda-october-4th-november-2020/

Announcements

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. 3 of 5.6 has been released!

WordPress 5.5.2 & 5.5.3 were also released. You can read up on the technical details in this post.

Highlighted Posts

Introducing auto-updates interface for Core major versions in WordPress 5.6

What’s next in Gutenberg? (November)

Updates from Component Maintainers/Focus Leads

General:
@sergeybiryukov reminded us that PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8 release is scheduled for November 26. We have two weeks until November 17 (scheduled date for WordPress 5.6 RC1) to discover and fix any remaining issues. Please see the PHP 8 call for testing: https://make.wordpress.org/core/2020/10/06/call-for-testing-php-8-0/. We need more testing on PHP 8, expanding test coverage, and creating tickets for any issues found.

Build/Test Tools:
@sergeybiryukov shared the following updates:

  • The test matrix on Travis was trimmed for older branches to remove the jobs that are no longer necessary. See #51705 for more details.
  • 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 test failures on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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/ Actions were fixed, see #51670 for more details.

Open Floor

@ahmedchaion asked if there were any plans to have a New Contributor Meeting suited to APAC timezones. The group agreed that there’s:
1. No reason  we can’t have one if there are available contributors to run it
2. And that the regular APAC Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. session fulfills that gap to some extent.
@thewebprincess asked if there were any core requirements for someone willing to run a new contributor meeting and if there was any documentation available. @sergeybiryukov followed up by stating there is no documentation currently available for this, but the following links might be helpful:

The group had a lively (and lengthy) discussion on the auto-updates UIUI User interface. The full transcript of the discussion can be viewed here.

@nalini highlighted the latest Month in WordPress post. And also shared the write-ups from the WordPress translation celebrations, adding that the Marketing and Polyglots teams are now working on questions and answers to encourage translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization., including about releases.

Next Dev Chat meetings

The next meetings will take place on Wednesday, November 11, 2020, 05:00 UTC and Wednesday, November 11, 2020, 20:00 UTC in the #core 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. Please feel free to drop in with any updates or questions.

#5-5-2, #5-5-3, #5-6, #dev-chat, #summaries, #summary

Updating core jQuery to version 3 – part 2

A 3-step plan was outlined for upgrading the version of jQuery bundled with core in June 2020.

The first step was included with WordPress 5.5, which stopped enabling jQuery Migrate version 1.x by default.

As part of #50564, part two of this process was committed, which updated the bundled jQuery version to 3.5.1. Alongside this, jQuery Migrate was also updated to version 3.3.2.

For the duration of WordPress 5.6, the migrate script will remain enabled by default, to capture any unexpected uses of deprecated features.

Do note that the Migrate script for version 3 is not compatible with features that the previous migrate script provided a polyfill for. The features that previously were marked as deprecated are no longer available. The purpose of jQuery Migrate version 3.3.2 in WordPress 5.6 is to help with updating (migrating) all jQuery based 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/. from jQuery version 1.12.4 to 3.5.1.

When testing the changes, it is recommended to enable SCRIPT_DEBUG. This will load jQuery Migrate in debug mode, and output stack traces in your JavaScript developer console.

As this is a major upgrade to the jQuery library, please make sure you test your plugins and themes as thoroughly as possible before the release of WordPress 5.6 to avoid any preventable breakage.

The jQuery Core Upgrade Guide provides details on what features are deprecated, and removed, and how to upgrade your code accordingly.

#5-6, #dev-notes, #jquery

Dev Chat Agenda: November 4th 2020

Here is the #agenda for this week’s meetings happening at:
Wednesday, 4 November 2020, 0500UTC and Wednesday, 4 November 2020, 2000UTC .

The #dev-chat meetings will be held on Wednesday, 4 November 2020, 05:00UTC and Wednesday, 4 November 2020, 2000UTC. These meetings are held in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack .

#5-6, #agenda