Proposal: REST API Authentication / Application Passwords

Problem statement: no way to authenticate third-party access to 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/.

Ever since the REST API infrastructure merged via #33982 and shipped in WordPress 4.4 in December 2015, it’s been gaining momentum and been used in more and more places—throughout WordPress’s adminadmin (and super admin), via plugins and themes, and enabled deep, robust interactions powering new functionality such as the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor.

However, the functionality has been limited in that the only way to make authenticated requests to the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. has been through Cookie & Nonce-based authentication—there is no good way for third-party applications to communicate with WordPress in an authenticated fashion, apart from the legacy XML-RPC API.

This has resulted in frustration for our Mobile teams especially as they’re working to integrate Gutenberg support, which relies on the REST API. After some time having to store username/password to spoof a cookie and interactive session to scrape a nonce from the wp-admin DOM, and then to use an endpoint to get it instead via [46253]. All of which is a tremendously messy and awkward usage that completely falls apart if someone uses a variant of a two-factor authentication system.

Spoofing an interactive session just to make API requests is bad form and needlessly complex.

We’d like to propose integrating Application Passwords into Core.

There have been many systems considered, including everything from multiple incarnations of OAuth, JWT, and even some solutions that are combinations of the two. Some called for a centralized app repository, some had open registration, but all were complex and none of them could build sufficient traction to come to fruition.

Broad conceptual overview of varying methods (See: WP-API/authentication#15)

A simpler alternative to Application Passwords is pure Basic Authentication and detailed in #42790. However, Application Passwords is more comprehensive, and a far superior of a choice for the reasons that follow.

Benefit: Ease of API Requests

Given a login and an application password, making an API request is as simple as

curl --user "USERNAME:APPLICATION_PASSWORD" -X POST -d "title=New Title" https://my.wordpress.site/wp-json/wp/v2/posts/POST_ID

It uses the standard HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. authorization headers. Everything supports this trivially.

Benefit: Ease of Revoking Credentials

Application Passwords makes it easy to revoke any individual application password, or wholesale void all of a user’s application passwords. Application Passwords also lists the date a password was last used and the IP it was used from to help track down inactive credentials or bad actors using them from unexpected locations.

Benefit: Ease of Requesting API Credentials

While it is possible for a user to go to their user profile page and generate a new application password, for example if they are creating a command line tool for themselves, the ideal workflow looks something like this:

To request a password for your application, redirect users to:

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

The URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org is included in the REST API index to facilitate automated discovery.

{
  "name": "Trunk",
  "authentication": {
    "application-passwords": {
      "endpoints": {
        "authorization": "http://example.com/wp-admin/authorize-application.php"
      }
    }
  }
}

and use the following GET request parameters to specify:

  • 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. If omitted, the user will be required to provide an application name.
  • success_url (recommended) – The URL that you’d like the user to be sent to if they approve the connection. Two GET variables will be appended when they are passed back (user_login and password); these credentials can then be used for API calls. If the success_url variable is omitted, a password will be generated and displayed to the user, to manually enter into your 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 will be sent to their WordPress dashboard.

If the user is logged out, they’ll be redirected to the WordPress Login page. After logging in, they’ll be immediately redirected back to the Authorize Application screen.

In discussions with @timothyblynjacobs we’re unsure about whether to add a state parameter (which is just stored and passed back to the application to prevent CSRF attacks). Realistically apps could just include it on their own in the success_url or a site_url parameter (which could remind the application what site the returned credentials are for). Requiring apps to pass a state parameter could encourage best practices, but we wouldn’t be able to enforce that they validate its contents.

It’s also worth noting that the success_url and reject_url are both explicitly designed that apps can pass in custom protocols for the return URLs. That is, they could set them to be wordpress://authentication so that the user’s phone automatically redirects them back from their web browser, directly into the application with the credentials appended to the query. You may have seen this previously with other applications where you “Login with Facebook” in your browser and then Facebook sends you directly back into your app. Or with how your web browser can open Zoom directly on your laptop, pre-populating the room ID and password.

Benefit: Login Security

Unlike pure basic auth that requires entering in credentials directly into the application, Application Passwords allows for an interactive authentication flow. This means that login security features like Two Factor or reCAPTCHA can continue to protect user accounts.

One of the reasons XML-RPC is so often recommended to be disabled is that it allows brute forcing user’s passwords since those additional security protections can’t be implemented. A risk of implementing pure basic auth is that sites will be forced to disable it because it can’t be interactive.

Proposed solution: merge Application Passwords to core

While there is a standalone plugin for Application Passwords that’s developed in a GitHub repo, PR#540 to WordPress-develop is the official work we’re proposing to be merged into core. The pull request is based off of the original feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.’s codebase. We welcome comments on this proposal post, contributions to Application Passwords itself, and even more so review and feedback on the existing merge proposal pull request.

Props to @timothyblynjacobs for help on the content of this post, @jeffpaul for help on the structure of this post, and the many many people who have contributed to the analysis behind this proposal and to Application Passwords.

#application-passwords, #authentication, #rest-api, #two-factor

Passing arguments to template files in WordPress 5.5

For years, theme developers wishing to pass data to template files have had to use less than ideal workarounds. This included the use of global variables, set_query_var(), the include( locate_template() ) pattern, or own version of get_template_part(), and so on.

Starting in WordPress 5.5, the template loading functions will now allow additional arguments to be passed through to the matched template file using a new $args parameter.

Affected functions

  1. get_header()
  2. get_footer()
  3. get_sidebar()
  4. get_template_part()
  5. locate_template()
  6. load_template()

To provide proper context, the related action hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. have also been updated to pass this new $args parameter.

  • get_header
  • get_footer
  • get_sidebar
  • get_template_part_{$slug}
  • get_template_part

Note: get_search_form() already accepts and passes additional arguments to search form templates as of [44956]. However, the $args parameter was added to the related hooks at the same time as the ones above. These are:

  • pre_get_search_form (action)
  • search_form_format (filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.)
  • get_search_form (filter)

Example

<?php
get_template_part( 
    'foo', 
    null, 
    array( 
        'class'          => 'user',
        'arbitrary_data' => array(
            'foo' => 'baz',
            'bar' => true,
        ),
        ...
    )
);

In the above example, the additional data passed to get_template_part() through the $args variable can be accessed within the foo.php template through the locally scoped $args variable.

<?php
// Example foo.php template.

// Set defaults.
$args = wp_parse_args(
    $args,
    array(
        'class'          => '',
        'arbitrary_data' => array(
            'foo' => 'fooval',
            'bar' => false,
        ),
        ...
    )
);
?>

<div class="widget <?php echo esc_html_class( $args['class'] ); ?>">
    <?php echo esc_html( $args['arbitrary_data']['foo'] ); ?>
</div>

Note: Any template file that currently contains an $args variable should take care when utilizing this new feature. Any modifications to $args in the loaded template files will override any values passed through using the above functions.

This enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. ticketticket Created for both bug reports and feature development on the bug tracker. was created 8 years ago, and is a long awaited addition. Thank you to all that helped discuss and refine this change.

For reference, see the related TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticket: #21676.

Props @audrasjb and @desrosj for technical review and proofreading.

#5-5, #dev-notes

Facebook and Instagram embeds to be deprecated October 24th

9/24/2020: Updated the post to reflect that the oembed_cache post type is only used for caching oEmbeds used within widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. content. Also added a reference to the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. focused on removing the oEmbed support. @desrosj

Facebook recently announced that all oEmbed requests for Facebook and Instagram content will be deprecated on October 24th, 2020. These 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. requests are at the backbone of both GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ and the Classic Editor to embed videos, pictures, updates, and more from the popular social platforms.

Changes to tokenless access for User Picture and FB/IG OEmbed endpoints: By October 24, 2020, developers must leverage a user, app, or client token when querying Graph API for user profile pictures via UID, FB OEmbeds and IG OEmbeds. Developers should provide a user or app token when querying for profile pictures via a UID or ASID, though client tokens are supported as well. Please visit our changelog for User PictureFacebook OEmbed and Instagram OEmbed for details on how to start calling these Graph API endpoints today.

Facebook for Developers

In response to this change, WordPress will be removing Facebook and Instagram’s oEmbed endpoints from WordPress Core code. This change will likely be released in WordPress 5.6. But, if a 5.x minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. occurs after October 24th and before 5.6 (currently scheduled to be released on December 8, 2020), it could be included in that release. Gutenberg 9.0 recently removed support.

If you are a WordPress user or developer that is using Facebook or Instagram embeds, there are some community plugins that aim to bring support. For continued support, sites or applications will need to register developer accounts with Facebook, and add the relevant API keys to all requests.

Because oEmbed responses are cached in the database using either post 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. or the hidden oembed_cache post type (currently used only in widgets), any embed added prior to the October 24th deadline will be preserved past the deprecation date. These posts are not purged by default in WordPress Core, so the contents of the embed will persist unless manually deleted.

Any new embeds added after the October 24th deadline will return the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org as a link if the Graph API request is not performed using a token.

To follow along with the changes to address this in WordPress Core, check out the ticket on Trac (#50861).

Props @francina, @desrosj, @clorith for proofread and review.

Discussion: How best to gather Component/Focus Updates as we head towards release

The Challenge

One interesting challenge in the leadership and coordination of the release process is getting a clear and comprehensive understanding of the landscape of the release. The squad have some mechanisms in place to help reveal that landscape, devchat being one of the main cogs in that mechanism. In past release cycles, there have been other initiatives to try and make that landscape ‘higher resolution.’

In order to feel confident that the release is moving forward according to plan, it’s important for the release leads and wider release cohort to understand the progress with components and focus areas of the 5.6 release whether or not there are any areas that are under supported and need assistance, and what, if anything is going to threaten the timeline and/or scope of that release.

In order to do this, the squad relies on regular and timely updates from component maintainers, focus leads, and feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. leads as the cohort moves towards the release date. So far, we have resorted to pinging @maintainers during devchat, and while that does occasionally elicit a response, it can be intrusive, especially if that component is not currently active, or if there’s no significant development happening for that component in relation to the release. There is also a chance that important information is missed if someone doesn’t respond to the pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.”

The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. problem is, how do we make sure we receive important updates from  components and focus teams without creating an environment where the release squad is required to ping regularly and ask for updates? What kind of system can we implement that will work for the release squad and component maintainers?

Possible Solutions

Different release co-ordinators/leads have used different approaches such as pinging in devchat, or messaging 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/. groups to ask for updates. There have been other options proposed at various times, like async reporting on weekly agenda posts, or a dedicated ‘check in post’ such as is used in the community team, or even a dedicated slack channel for component maintainers.

Each option has its pros and cons. So this post has been created to actually ask the component maintainers and focus squads what makes the most sense to them?

Share your thoughts!

This post invites discussion on how to explore ways that best encourage proactive sharing of progress/blockers so that the release team and other interested cohort members can be empowered to resolve issues, and be confident in the progress towards the goal. 

Questions:

  • If you are a component maintainer, what kind of process would you like to follow that would enable you to share regular updates?
  • If you are a part of the release cohort, how would you like to receive that information? 
  • Do you have any other thoughts or suggestions on how we can improve the flow information generally, without overwhelming a channel full of contributors, or even individual contributors?

Please share your thoughts in the comments below by Wednesday September 30th 05:00 UTC.

Props to @angelasjin, @cbringmann, and @audrasjb for editing support.

Introducing Twenty Twenty-One

Well friends, it’s time for what I’m sure you’ve all been waiting for: an announcement about the next WordPress default theme! The rumors are true; WordPress 5.6 will launch with a brand new default theme: Twenty Twenty-One. 

The default theme team includes:

  • Default Theme Design Lead: Mel Choyce-Dwan (@melchoyce).
  • Default Theme Development Lead: Carolina Nymark (@poena).  
  • Default Theme Wrangler: Jessica Lyschik (@luminuu).
  • …and you, our fabulous volunteers!

Background

Twenty Twenty-One is designed to be a blank canvas for the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. After trying some designs heavily inspired by print resources, @kjellr remarked to me, “why not try something natively digital?” I added even more ideas to my increasingly unwieldy pinterest board and gave it a shot. The concept ended up being the most natural, usable design of the bunch. It was simple and un-opinionated, yet still refined. It felt like a fresh canvas, waiting to be painted.

Twenty Twenty-One will use a modified version of the Seedlet theme as its base. This provides us with a thorough system of nested CSSCSS Cascading Style Sheets. variables to make child theming easier, and to help integrate with the global styles functionality that’s under development for full-site editing.

Once the theme is stable, after 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. 1, we’ll start exploring Full Site Editing support.


Design Decisions

By default, the theme uses a native system font stack. I made this choice for a couple reasons:

  • No extra load time. Let’s keep this theme simple and fast.
  • This particular stack is pretty typographically “neutral” — none of the fonts are super opinionated, so the theme can be used broadly across different types of sites.
  • Using just the one font stack, without loading additional font files, also makes it easier for folks to customize or create a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. for Twenty Twenty-One. We want this theme to be a teaching tool, and an outlet for your creativity.

The theme also uses a limited color palette: a pastel green background color, and two shades of dark grey for text. We’ll be bundling the theme with some additional color palettes, including both a white and a black color scheme. Why pastel green? Pastels and muted colors are pretty in right now (seriously I could keep going).

(Who doesn’t love a little pastel cottagecore during these troubling times?)

All this is to say: the design? It’s pretty simple. That’s where patterns come in.

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ introduced support for patterns in WordPress 5.5. This is the perfect time to show them off. Twenty Twenty-One will come packaged with a bunch of unique patterns designed explicitly for the theme. The theme’s overall design is simple, so you can make it your own, but the patterns will be opinionated. There are a couple already designed, and we’ll be relying on our talented community designers for more ideas. Here’s what we’re thinking about so far:

Want to contribute a block pattern? We have an issue template for that.

Lastly, we’d love to make the theme meet relevant guidelines from WCAG 2.1 level AAA. We loved the idea when +make.wordpress.org/accessibility/ brought it up, and would appreciate any and all guidance from our community a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) experts to help make this possible.

You can find full page mockups of Twenty Twenty-One in the Figma file.


Timeline

Per the development cycle information, the upcoming important dates are:

  • WP 5.6 Beta 1 – October 20
    • Last chance for feature projects and new enhancements
    • Theme should be committed to trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.
    • Start exploring FSE support in a second, block-based theme
  • WP 5.6 Beta 4 – November 10
    • Soft string freeze
    • Starter content should be committed
  • WP 5.6 RC 1 – November 17
    • Hard string freeze
    • Starter content needs to be finalized
  • WP 5.6 Release – December 8

Get Involved

If you are interested in contributing to Twenty Twenty-One, make sure you are following this blogblog (versus network, site). During the design and development process, there will be weekly meetings starting Monday, September 28 at 15:00 UTC in #core-themes. We’ll also be holding weekly triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions at starting this Friday at 16:00 UTC.

Theme development will happen 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/ and in the interest of time, an in-progress version of the theme code has been uploaded here: https://github.com/wordpress/twentytwentyone.

Once the theme is stable, it will be merged into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and the GitHub repo will be deprecated.


Learn More

If you’re interested in learning more about default themes, you can read the following posts:

#5-6, #bundled-theme, #core-themes, #twenty-twenty-one

External Library updates in WordPress 5.5: call for testing

Edit 7/1/20: The post initially indicated that a minified version of Moment.js was now included in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. This was incorrect, a minified version has always been included, but as a direct copy from upstream. That copy now has a sourceMappingURL reference (which is not desired). For that reason, the library is now minified in the Core build process instead. That sentence was removed to prevent confusion. Props @sergeybiryukov for catching that.

Edit 7/2/20: After this note was published, new versions of the Moment.js and getID3 libraries were committed. The version updates for each have been adjusted appropriately.


WordPress 5.5 is currently slated to bring some long awaited updates to a handful of external libraries bundled with Core. A few of the updates are particularly large, and while backwards compatibility measures were taken, they could potentially require adjustments to plugins, themes, and custom code. For that reason, this developer note also doubles as a call for testing.

Please help test these library updates, and report back any bugs to help ensure that no edge cases were missed during the initial testing.

You can test these changes by installing the WordPress Beta Tester 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 (choose the “bleeding edgebleeding edge The latest revision of the software, generally in development and often unstable. Also known as trunk. nightlies” option), or download the nightly package directly (regenerated from trunk daily).


Remember, running the nightly version of WordPress is not recommended for production environments. Consider setting up a local development environment to test instead.


A full list of External Library tickets can be found on Trac, but below are the library updates currently slated to ship with WordPress 5.5, including all of the details you need to be aware of. The libraries that require an extra keen attention to detail are marked “please test”.

PHPMailer (please test)

Because of conflicting PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 support policies (support for PHP < 5.5 in was dropped in newer versions of the PHPMailer library), WordPress Core has been stuck on the 5.x version of PHPMailer for quite some time, even though a newer, 6.x version exists. However, now that WordPress only officially supports PHP back to version 5.6.20, PHPMailer can finally be updated.

This is a major update to the library. Please help by testing this update to ensure any edge cases are discovered.

Plugins that appear to be utilizing the library will soon receive an email to test their code. Below is what you need to know about the changes as they relate to WordPress Core.

Note: this is not an exhaustive list. For a more complete list of changes, please consult the Upgrading from PHPMailer 5.2 to 6.0 guide.

New file locations

To make updating the library easier, the PHPMailer files have been moved into the wp-includes/PHPMailer directory. The old files will remain for backwards compatibility and load the new corresponding files, but loading them will now throw a _deprecated_file() warning.

  • wp-includes/class-phpmailer.php is replaced by wp-includes/PHPMailer/PHPMailer.php.
  • wp-includes/class-smtp.php is replaced by wp-includes/PHPMailer/SMTP.php.

Additionally, the phpmailerException class is now separated into its own file, wp-includes/PHPMailer/Exception.php (previously, it was included at the bottom of the class-phpmailer.php file). When loading the PHPMailer library, the Exception.php file is required, and should also be loaded. If the old class-phpmailer.php file is loaded, the exception class will be loaded automatically to minimize failures.

New PHPMailer namespace

In past versions, the PHPMailer class existed within the global space. However, moving forward, the PHPMailer library is under the new PHPMailer\PHPMailer namespace. Below is an example of the old usage, and an example of the new way to utilize the library.

Old method

<?php
require_once ABSPATH . WPINC . '/class-phpmailer.php;
$phpmailer_instance = new PHPMailer();

New methods

Both examples will produce identical results.

<?php
use PHPMailer\PHPMailer\PHPMailer;
require_once ABSPATH . WPINC . '/PHPMailer/PHPMailer.php;
require_once ABSPATH . WPINC . '/PHPMailer/Exception.php;
$phpmailer_instance = new PHPMailer();
<?php
require_once ABSPATH . WPINC . '/PHPMailer/PHPMailer.php;
require_once ABSPATH . WPINC . '/PHPMailer/Exception.php;
$phpmailer_instance = new PHPMailer\PHPMailer\PHPMailer();

Similar changes must also be made when utilizing the PHPMailer Exception class.

The old classes have been registered as aliases of the new, properly namespaced classes using class_alias() in PHP (this is true for the PHPMailer, phpmailerException and SMTP classes). This means that a plugin containing code similar to the “old method” will continue to work seamlessly until it can be updated (with the exception of the _deprecated_file() notice).

Note: the aliases will only exist if the old, deprecated files are included. A plugin relying on Core to load the PHPMailer library will not have an alias present as the new files are now loaded instead.

Deprecated elements have been removed

Another big change in the 6.x update was the removal of all deprecated properties and methods. A full list of removed elements can be found in the upgrade guide.

Plugins using PHPMailer

All plugins that appear to be utilizing PHPMailer will soon be receiving an email notification to test their code and make any necessary adjustments.


For more information, check out the full list of changes included with this update, the PHPMailer 6.0 upgrade guide, or the related TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets (#41750, #50379, #50380).

SimplePie (please test)

SimplePie is a RSS and Atom feed framework bundled with WordPress Core to handle the consumption of RSS and Atom feeds. The library has remained largely untouched for several years, but has been updated from version 1.3.1 to the latest version (1.5.5) for WordPress 5.5.

This update includes 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. fixes, compatibility fixes for newer versions of PHP, added support for additional date formats, and minor improvements to ensure that feeds continue to be parsed correctly. Support for caching feed data to Redis and Memcached has also been added.

It is highly recommended that you test your code if your site fetches and processes RSS/Atom feeds.

Plugin authors were previously notified to test their code against the 1.5.5 update in early May, and the authors of plugins that were identified as using SimplePie should have received an additional follow up email. While no issues have been reported so far, it’s still possible that there may be undiscovered edge cases.

For more information, check out the full list of changes in SimplePie 1.3.1 to 1.5.5, or the related Trac ticketticket Created for both bug reports and feature development on the bug tracker. (#36669).

Twemoji

Earlier this year, the Unicode Consortium announced that Emoji v13.0 had been finalized. In addition to the 62 brand new emojis that were added, 55 gender and skin-tone variants were also added.

Platforms will begin rolling out native support later this year. But why wait? The Twemoji library has already been updated to support the new emojis, and that update will be included in WordPress 5.5.

So start spicing up your blogblog (versus network, site) about ninja (🥷) techniques, using tamales (🫔) and olives (🫒) on your food blog, and beavers (🦫) or polar bears (🐻‍❄️) on your wildlife blog.

For more information, check out the full list of new emojis added in Emoji v13.0, the Twemoji 13.0 release notes, or the corresponding ticket on Trac (#50148).

Masonry & imagesLoaded

The Masonry library has been updated from version v3.3.2 to 4.2.2, and the related imagesLoaded library has been updated from v3.2.0 to v4.1.4.

The biggest change in this update is the removal of support for IE versions 8 & 9. Core has not supported these versions of IE since WordPress 4.8, but if supporting these versions of Internet Explorer is important to your user base, please explore enqueuing your own versions of these libraries instead.

For more information, check out the full list of changes in Masonry, the full list of changes in imagesLoaded, or the related Trac ticket (#37675).

getID3

The getID3 library has been updated from version v1.9.18 to v1.9.20. This is a minor update that fixed several bugs. These fixes included one that caused a PHP notice when using PHP 7.4 and processing MP3 audio files.

For more information, check out the full list of changes in getID3 or the related Trac ticket (#49945).

Moment.js

The Moment.js library has been updated from version 2.22.2 to 2.27.0. For more information, check out the full list of changes in Moment.js, or the related Trac ticket (#50408).

clipboard.js

The clipboard.js library has been updated from version v2.0.4 to v2.0.6. For more information, check out the related Trac ticket (#50306).

Props @earnjam for technical review, @newyorkerlaura and @justinahinon for proof reading.

#5-5, #dev-notes, #external-libraries

E2E (End-To-End) Testing in Core Proposal

What

E2E (End To End) tests are a form of automated software testing which runs in the context of a user using an application. The intention is to test the complete “end to end” workflow that a user would take in various scenarios.

In web software development this means running and controlling a web browser pointing at a web page, either fully automatically by a machine, or by a user following the test steps.

Frameworks for running E2E tests allow a web browser to be controlled fully automatically, for instance by navigating to URLs, filling out forms, and clicking on links and buttons. The tests operate by checking assertions about the expected content or behaviour of the page and triggering a test failure when they are not met.

Why

Testing individual aspects of an application’s code — for example with unit tests or integration tests — reduces the chance of low-level bugs in the code that powers an application. Unit testing helps maintain the quality of the code that powers the application.

In contrast, E2E testing tests the higher-level functionality of an application that the user sees, typically including the interface and the inputs and controls that the user interacts with.

Unit testing and E2E testing can, should, and do co-exist.

How

E2E tests are usually human-readable and provide logical steps for a user to perform. For example:

  • Given I am logged in as an Author
  • When I view the list of posts in the dashboard
  • And I see posts published by other users
  • Then I should not see an “Edit” link next to posts which are published by other users

The scenario above can potentially form a completely automated E2E test, depending on the framework in use and the built-in steps that have been defined for it. The tests are written in such a way that a human can follow the same steps and come to the same result.

This means anyone, not just a developer, can write an outline of an E2E test.

Implementing E2E tests in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.

WordPress Core right now has only one E2E test in place, to check that the wp-adminadmin (and super admin) page loads. GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, on the other hand, has quite a few.

There are some tickets and pull requests open about this:
https://core.trac.wordpress.org/ticket/43395
https://core.trac.wordpress.org/ticket/49507

There is also a test environment but it is not currently being used as part of the automated test suite: https://make.wordpress.org/core/2019/08/05/wordpress-local-environment/

It would be beneficial to create a project to work on this in a structured way in order to maintain the stability and reliability of WordPress core as new features are added and changes are made.

Moving Forward

Months ago, this topic was mentioned multiple times and @pandjarov from SiteGround has offered to set up the test environment plus some engineering time to work on the tests.

We could either set up a new one or check that the existing one is still the right way forward.

To really kick things off, the Core Team has to come up with requirements for the test environment, its tests, and the preferred workflow, so the tests are really useful.

What is needed

  • A list of requirements – I think Core Committers, especially with a long history of contributing (the so-called historians) are best suited to start the list with the most pressing concerns
  • Evaluating the existing test environment (existing vs creating new)
    Ideas about what functionality in WordPress should be a priority in the automated tests, for example, the upgrade process, or managing users, or installing plugins
  • Developers who are familiar with Jest, which is the test framework in place in Gutenberg and WordPress core, so the test environment can be improved, and to write new tests
  • A fork of the wordpress-develop repo 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/ where the project can be managed and PRs opened
  • Volunteers to work on this. It’s a big task because it starts from 0 – this is very important because what the previous post about this has shown, in my opinion, is that an environment is not enough 😉
  • Coordination with the Test team
  • For making it easier to communicate I propose to add a dedicated weekly chat in the #core-test channel – From September 6th I am available to do that.

Deadline to comment

To make sure that the project lifts off I think it needs enough interest and volunteers to actively work on it.

Please leave a comment before September 6th (so you have a month to think about it!) with the requirements and/or (possibly AND) your availability to be part of this.

Proposal: Dual licensing Gutenberg under GPL v2.0 and MPL v2.0

This post is to gather feedback about a proposal to dual license GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ under GNU General Public License, v2 (GPLGPL GNU General Public License. Also see copyright license. v2) and the Mozilla Public License v2.0 (MPL v2.0). Full context can be found on this issue on GitHub that was opened to gather feedback about the MPL v2.0 proposal. On that post, there are some positive comments from people who would like to use Gutenberg in their software, but who are currently limited by the GPL v2 license.

I’m posting this here to bring some visibility to this ticketticket Created for both bug reports and feature development on the bug tracker.. I’d also like to propose the following, if there is no blockerblocker A bug which is so severe that it blocks a release. found by dual licensing:

  1. List all contributors (this can be automated via the GitHub API).
  2. Create a 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/ ticket to explain the change, pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” all contributors and ask them to write a predefined comment to either “approve” or “reject” the dual licensing request. This was done in other big open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. projects like rubinius (switched from BSD to MPL), mpv (switched from GPL to LGPL).
  3. Wait for contributors to reply.
  4. Contact contributors who do not reply in a timely manner to get their response.
  5. After all contributors respond, or when the target date is reached (e.g., one year in the future), remove or rewrite code from contributors who rejected the dual licensing and from contributors who didn’t reply.
  6. Switch the licensing scheme to GPL v2 + MPL v2.

The idea here is to keep some of the WordPress-specific modules under the GPL v2.0 only; some of them are not needed and not relevant for using Gutenberg in another software. Ideally, there would be a different way of bundling the project for being used in WordPress or in a non-GPL software.

Note that a similar license change has happened on Aztec-Android and Aztec-iOS.

Please comment on this post, or on the GitHub issue, if you have thoughts about this dual licensing idea or the ideas on how to make the change happen if this seems feasible.

Editor Chat Agenda 23 September, 2020

Facilitator and notetaker @itsjusteileen.

This is the agenda for the weekly editor chat scheduled for Wednesday, September 23, 2020, 10:00 AM EDT.

This meeting is held in the #core-editor channel in the Making WordPress 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/..

  • Gutenberg 9.0
  • 5.6 Project board
  • Monthly Plan for September 2020 and key project updates. With focus on issues, what is being done and help that is needed.
    • Global Styles.
    • Navigation screen and Navigation blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience..
    • Widgets screen.
    • CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. screen.
    • Full Site Editing.
  • Task Coordination
  • Open Floor

Even if you can’t make the meeting, you’re encouraged to share anything relevant for the discussion:

  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#core-editor, #core-editor-agenda

Dev Chat Agenda: September 23rd 2020

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

Please share any items you’d like to include in the comments below.

  • Announcements
  • Highlighted blogblog (versus network, site) posts
  1. Proposal: Dual licensing Gutenberg under GPL v2.0 and MPL v2.0 Action Required: Please review the post and add your comments to the discussion.
  2. ETA by Francesca – Introducing Twenty Twenty One Action Required: Please review the post, leave feedback and get involved
  3. ETA by Francesca –Proposal: REST API Authentication / Application Passwords Action Required: Please review the post and add your comments to the discussion.
  4. ETA by Francesca –Discussion: How best to gather Component/Focus Updates as we head towards release Action Required: Please review the post and add your comments to the discussion
  5. ETA by Francesca –Facebook and Instagram embeds to be deprecated October 24th
  • Updates from component maintainers and/or focus leads (also see item 4 in the above list)
  • Open Floor

    If you have something else you want to include to the agenda, please mention it in the comments below.

The #dev-chat meetings will be held on Wednesday, 23rd September 2020, 05:00UTC and Wednesday, 23rd September 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