The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Remove jQuery Migrate 1.x. This is planned for WordPress 5.5.
Update to the latest version of jQuery and add the latest jQuery Migrate. This is tentatively planned for WordPress 5.6 depending on test results. Updating to the latest jQuery UI, version 1.12.1, is also planned for 5.6.
Remove jQuery Migrate. This is tentatively planned for WordPress 5.7 or later, depending on testing.
As planned, a Test jQuery Updatesplugin was released to make it easy to test different versions of jQuery, jQuery Migrate, and jQuery UI. Please install it and thoroughly test if everything works as expected, especially on the front-end, or at the settings pages of other WordPress plugins.
How to help with testing
The plugin has a settings screen found under the Plugins menu in WordPress admin. Different versions of the jQuery libraries can be selected there for testing. Please test by:
Disabling jQuery Migrate, and leaving jQuery and jQuery UI at the default versions (for WordPress 5.5).
Test jQuery Updates settings screen, under the Plugins menu.
Updating your code
To get ready for this jQuery update, it’s important that you update your code. The migrate plugin will assist you in identifying issues. Additionally, the jQuery Core 3.0 Upgrade Guide and 3.5 Upgrade Guide provide detailed information about what has changed. As the browser supported list is also updated, this is also a great time for you to revisit what versions of browsers are supported by your themes and plugins.
How exactly would migrating WP core to vanilla, and then leaving jQuery as an optional dependency with a depreciation notice that devs should be using es6 + wp.scripts whenever possible break back-compat?
migrating WP core to vanilla, and then leaving jQuery as an optional dependency…
Right, the long term goal is to gradually migrate WP Admin to Vanilla JS. There is a lot of code to migrate, so it will take a while… Patches are welcome 🙂
Even if all of WP Admin is migrated to Vanilla, the jQuery libraries and plugins will still be available to enqueue through Script Loader, to maintain backwards compatibility.
Best place to get involved in migrating WP Admin to Vanilla JS is to just do it 🙂
Identifying some (old) code that can be converted, opening a Tracticket and adding a patch, and mentioning it in Slack would most likely bring other people that are interested.
Such a great news. Google PSI and Lighthouse is always telling update the jQuery. It has lots of vulnerabilities. Happy to hear it’s finally getting updated.
But on a side note I really think WP core should push devs to start using vanilla JS or Vue and stop using jQuery. Honestly jQuery is a lost cause. Javascript has come a long way since the jQuery days.
I tried out the plugin and so far everything works as expected, great work @azaozz! In the past we had seen issues with certain parts of the customizer breaking when we upgraded jQuery.
Thanks! Yes, I’ve heard about issues with some parts of the Customizer, but haven’t seen any, yet. Perhaps jQuery 3.5.1 plus jQuery Migrate 3.3.0 fixed them 🙂
If you know your plugin won’t work on older WP, you should:
1. Update the plugin headers so “Requires at least:” is set to the version you now support
2. Put in a version check on activation “If WP is less than 5.5, auto-disable”
The first one should prevent people on older WPs from updating, the second makes sure you don’t crash them.
__( 'This plugin can not be activated because either your WordPress instalation has an outdated/unsuported PHP version or you are using an outdated/old WordPress version.<br><br>This plugin requires a minimum of <strong>PHP 5.6 or greater</strong> and <strong>WordPress 4.9 or greater</strong>.<br><br> Your install:<br><strong>PHP: ' . PHP_VERSION . '</strong><br><strong>WordPress: ' . $wp_version . '</strong><br><br>You need to update either one of them or both, before you are able to activate and use this plugin.<br>- <a href="http://wayback.fauppsala.se:80/wayback/20200729170849/https://wordpress.org/support/update-php/" target="_blank" rel="noopener noreferrer">Learn more about updating PHP</a><br>- <a href="http://wayback.fauppsala.se:80/wayback/20200729170849/https://wordpress.org/support/article/updating-wordpress/" target="_blank" rel="noopener noreferrer">Learn more about updating WordPress</a>', 'wp_jquery_manager_plugin' ),
Now that 5.5 has been officially kicked off, bug scrubs will happen weekly all the way up to the final release. “Early” ticket scrubs have already taken place. Keep an eye on this schedule – it will change often to reflect the latest information.
These scrubs are separate and in addition to the normal scrubbing and triage by individual components. Some of those sessions include:
Design Triage: Every Monday 17:30 UTC at #design Gutenberg Design Triage: Every Tuesday 17:00 UTC at #design Accessibility Scrub: Every Friday 14:00 UTC at #accessibility
Also, the ongoing APAC-friendly #core bug scrub session every Tuesday at 05:00 UTC will continue during the cycle, alternating focus between core and editor.
Finally, a reminder that anyone — Yes, you! — can host a bug scrub at anytime. You can work through any tickets you’re comfortable with. In fact, if you plan one that’s 5.5-focused, we’ll add it to the schedule here along with your name. Finally, you’ll get well deserved props in the weekly Dev Chat, as well as in the #propsSlack channel!
All open tickets for 5.5, in order of priority, can be found here. Tickets that haven’t seen any love in a while are in particular need. Those can be found in this query.
If you’d like to lead a bug scrub or have any questions or concerns about the schedule, please leave a comment or reach out to me directly.
Got something to propose for the agenda, or a specific item relevant to our standard list above?
Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you, accordingly.
This meeting happens in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.
Values/counts for font-family and letter-spacing (only 3 for the latter!)
Values/counts for z-index
This data can be seen in the audit report Google Doc. It looks like the remaining items are media query counts and the history of CSS coding standards and the stylelint configuration. @isabel_brison suggested collecting related documentation and tickets for this history piece, and using @ryelle‘s css-audit tool to accommodate the media query counts.
List of data to track on a recurring basis
For the CSS audit of wp-admin, #49582, we have discussed running recurring reports, and this agenda item was to determine what data should be tracked in a recurring report. We decided that, for now, we can place to include the same data we are including now where the collection is automated with the css-audit tool or stylelint. These items can be seen in the audit report Google doc.
Color Scheming Updates
Themes vs. Modes
One outcome of the meeting previous to this one was the concept of color “themes” vs. “modes”. I started off the conversation with this question:
Do you see a distinction between the nature of admin color schemes and something like dark mode, in the way we treat colors? For example:
Ectoplasm – Dark
Ectoplasm – High Contrast
(where “Ectoplasm” = any of the admin themes)
@tellthemachines said that she saw “dark mode” or “high contrast” to be a collection of themes that support that criteria. We discussed that “modes” are most like a way to categorize themes, and are not a separate implementation.
I shared a link @youknowriad posted during the last meeting to a prototype of dark mode in the editor. In this prototype, dark mode is a separate toggle that can be applied on top of themes. I also shares a code snipped @youknowriad posted before as an example of themes and modes treated separately:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
.button {
color: var( --wp-admin-theme-color );
background: white;
}
.is-dark-mode .button {
background: var( --wp-admin-theme-color );
color: white;
}
.my-admin-scheme {
--wp-admin-theme-color: blue;
// potentially other variables
}
We discussed that the rigidity of this approach will be restrictive for other themes and accommodating they variety of user needs required for accessibility. In this case, the text for .button in dark mode will always be white, but we need to accommodate lower contrast dark mode themes as well. @tellthemachines mentioned that the “decisions not options” motto of WordPress, and that regarding accessibility, it should be the opposite (and after the meeting @ryelle followed up with the phrase “options not restrictions” … nice!).
So, to conclude here:
The notions of “dark mode” and “high contrast” seem like categories for color schemes – they are characteristics of a color scheme, not separate features.
In order to provide options, not restrictions, regarding accessibility, it will be important to have control over all colors in the implementation of color schemes.
CSS Latest and Greatest Link Share
I shared a link to CSS Scroll Snap – the possibility of slider-like interfaces with only CSS is not so far in the future!
In previous versions, when using the BlockPreview component, setting a height for the container was necessary in order to show the block preview properly. This was not working properly in situations where the height of the content was dynamic and changing from preview to another.
In WordPress 5.5, the BlockPreview component automatically scales the content to the available width and adapts its height to its content height.
In most situations, this will improve the rendering of BlockPreview components but if you used to rely on the fixed heights, you should consider checking whether the new behavior is working properly.
URLInput component
In previous versions, the URLInput component used to have a default value set as true for the autoFocus prop. This means that, every time this component was being rendered, it was auto-focusing the input. While this is the intended behavior for Link Popovers, this behavior was problematic in all the remaining use-cases. In WordPress 5.5, this prop is set to false by default.
If you relied on the auto-focus behavior of the input, you must explicitly assign autoFocus={ true }. Refer to the component README for more information.
Popover component
On WordPress 5.5, the Popover component has different default values for the noArrow and position props. If you relied on the previous default behavior, you must explicitly assign these props.
Edit 7/29/2020: a call out specific to Twenty Ten was added for the comment_type change.
WordPress 5.5 comes with a number of small developer-focused changes. Here’s a summary of what you can expect.
Upgrade/Install: updating a plugin or theme by uploading a ZIP file
Starting in WordPress 5.5, it will be possible to update a plugin or theme by uploading a ZIP file. After uploading the ZIP file, a comparison table will be displayed to the user, detailing the differences between the uploaded ZIP and the version of the plugin currently installed.
The majority of this process is handled by the new do_overwrite() methods within the Theme_Installer_Skin and Plugin_Installer_Skin classes. However, there are a few hooks that can be used to adjust the output of this feature:
The install_plugin_overwrite_comparison and install_theme_overwrite_comparison filters can be used to modify the output of the comparison tables.
The install_plugin_overwrite_actions and install_theme_overwrite_actions filters can be used to modify the actions displayed after an update has failed when overwriting is allowed.
The upgrader_overwrote_package action is fired when a plugin or theme has been successfully been upgraded/replaced with a new version uploaded by ZIP.
Themes: functions calling locate_template()now have a return value
The template loading functions have historically not returned any values. When called, they execute silently, even if the desired template file is missing. This makes it difficult to debug situations where there is a typo in the template name details passed to the function.
Starting in 5.5, the following functions now return false if the template file is not found, and void if the template is found and loaded:
get_header()
get_footer()
get_sidebar()
get_template_part()
This could also be used for themes to check for missing template files and execute code when one is missing. For example:
1
2
3
4
<?php
if ( false === get_header( 'post' ) ) {
// Do something when the `header-post.php` file is missing or cannot be loaded.
}
Note: Previously, returning a value when the template was loaded successfully was explored. However, this approach is not feasible. It was discovered that many themes in the wild are printing the return value of get_template_part(), leading to unexpected (and potentially compromising) content being sent to the browser.
For more information, check out the related ticket on Trac: #40969.
Taxonomy: default categories for custom post types
For the post post type, a default category term (“Uncategorized” by default) is applied to every published post. Starting in 5.5, this default term can be applied to posts of any custom post type with the category taxonomy registered to it. This can be accomplished using the new default_category_post_typesfilter.
Taxonomy: support for default terms in custom taxonomies
A new default_term argument has also been added to register_taxonomy(). Using this argument, a default term name (and optionally slug and description) can be defined. If the defined term does not exist, it will be created automatically.
Additionally, a default_term_$taxonomy option will be added to the database for easy access, and parity with default_category.
Since [9541], an empty string has been used as the default value of a comment’s comment_type field (though it was possible for this to be empty sooner). While examining the possibility of introducing custom comment types in #35214, this was identified as something that would potentially be problematic.
Starting in WordPress 5.5, comment will be enforced as the default comment_type for all comments going forward. This change is one of the first step to open the door to potentially supporting custom comment types.
After upgrading to 5.5, an upgrade routine will be scheduled via cron and run to update all preexisting comments with an empty comment_type to comment. This process will batch comments 100 at a time. The batch size can be adjusted using the wp_update_comment_type_batch_size filter.
If a conditional checks that $comment->comment_type is an empty string in your plugin or theme, it is possible that this change could cause comments to stop displaying on your site. Twenty Ten was the only default theme affected by this. Though it has been fixed and the theme will be updated along with 5.5, any theme built off of Twenty Ten should be updated.
For more information, see the related tickets on Trac (#49236, #35214).
Comments: Changes to return values
With the aim of consistency and WordPress 5.5 will bring a few changes to the values wp_update_comment() returns.
First, a new parameter, $wp_error, has been added to control whether a WP_Error is returned when an error is encountered. This is optional, and will default to false (do not return a WP_Error object).
Second, the return values for an invalid comment or post ID has been changed from 0 to false. This addresses an issue where 0 could be returned for three different scenarios.
Any code checking explicitly for 0 as a returned value of wp_update_comment() will need to be updated to instead explicitly check for false.
For more information, see the related ticket on Trac (#39732).
Additional developer changes
Build/Test Tools: The documentation for the Docker environment included with Core for local development and the environment overall has been improved. Contributors are encouraged to give it a try and report any breakage they experience. (see #50058).
Docs: All instances of @staticvar within inline PHP docs have been removed. This tag is no longer supported in phpDocumentor (see #50426).
Formatting: loading has been added as an allowed attribute for the <img> tag in the KSES functions (see #50731).
Formatting: wp_filter_object_list() now properly returns an array when passed an object with magic methods (see #50095).
General: The logic in add_magic_quotes() has been adjusted to prevent inappropriately recasting non-string data types to strings. This was noticeable in the REQUEST_TIME and REQUEST_TIME_FLOAT values in the $_SERVER super global (see #48605).
Login and Registration: The new lostpassword_errors filter in retrieve_password() allows developers to add or modify the errors generated during a password reset request (see #49521).
Media: the media grid frame is now exposed via the wp-media-grid-ready trigger for easier customization (see #50185).
Query: A new set_404 action has been introduced, firing after a 404 is triggered (see #48061).
Query: The found_posts property of WP_Query will now always be an integer (#42469).
Site Health: The error messages displayed to a user when the site does not meet the PHP or WordPress requirements of the plugin being activated have been improved to list those requirements and include a link to support documentation for updating PHP (see #48245).
TinyMCE: TinyMCE has been updated to version 4.9.10 (see #50431).
Upgrade/Install: an additional hook_extra parameter has been added to the upgrader_pre_download filter. This will provide additional context to code hooked onto this filter, such as which plugin or theme update will be downloaded (see #49686).
Upload: a new pre_wp_unique_filename_file_list filter has been added to wp_unique_filename(). This can be used to short-circuit the scandir() call to provide performance improvements for large directories (see #50587).
Logo images inserted using get_custom_logo() or the_custom_logo() will no longer link to the homepage when visitors are on that page. In an effort to maintain the styling given to the linked image, the unlinked logo image is inside a spantag with the same “custom-logo-link” class.
Many themes include both a logo and a site title, and then the logo is decoration alongside the site title. Because decorative images do not need their purpose to be described, the unlinked logo’s alt attribute is empty. In cases where the site title is not present, the logo alt text may require custom handling. See code examples below for ways to override the default behavior.
Theme authors who use the a tag as a CSS selector instead of the .custom-logo-link class are encouraged to duplicate their selector to also select the span tag, or to directly select the .custom-logo-link class. A theme directory search found 183 themes that use a.custom-logo-link for styling.
Please verify whether this change makes the logo display any differently on the homepage, as well as whether the empty alt text should be appropriate.
For more details, see the related ticket on Trac: #37011
New logo image attributes filter
Themes can use the get_custom_logo_image_attributes filter to override default attributes for the logo image or to set additional attributes.
For example, if a theme combines the logo image plus the site title (as actual text) within a link and/or heading tag, then having the site title as the logo’s alt text would be redundant. In that case, this is one way to empty the alt text so screen readers only announce the actual text:
Do I understand correctly that this
change will knowingly break at least 183 themes on the WordPress theme repo alone, and requires manual updates for each theme to fix?
It looks like 183 themes from the repo will be affected by it. That’s not to say that they are all going to be broken. Do you have an alternative proposal that can achive the same thing but without any changes with implications for theme developers? I would very much welcome it if you have one.
I have an alternative proposal. Make use of the “theme supports” system to take care of this. There is precedent for breaking HTML changes when core made the switch to HTML5 for various elements in the past. I’d use something like add_theme_support( 'unlink-homepage-logo' ) (or some other better name) for themes to opt into the feature.
It might not hurt to introduce a flag for any breaking HTML changes now and in the future. Something along the lines of add_theme_support( 'html-compat', [ 'logo-link', 'some-other-change' ] ).
This might have saved us from some other HTML changes like the recent calendar HTML changes.
It would be good to discuss the issue during the Open Floor.
Autosaves. How should these be used? It would be good with some more eyes on this issue. As autosaves can be confusing.
A few days ago I created a PR to implement an `itemWrapper` prop for `InnerBlocks` that allows child blocks to each be wrapped with a given element. It’s a rather significant change and there may be better ways of implementing it, so any technical feedback and ideas are much appreciated!
First, I’m hoping to get a final code review and approval on this reusable blocks refactor PR, which fixes some annoying bugs. It may be too late to get it into WP 5.5, but I’m hoping it could be backported to a 5.5.1 release.
I’m wondering what the status of this issue is and what needs to be done to move it forward. It seems like something that would be very good to have implemented before FSE to make theme styling easier.
A few days ago I created a PR to implement an `itemWrapper` prop for `InnerBlocks` that allows child blocks to each be wrapped with a given element. It’s a rather significant change and there may be better ways of implementing it, so any technical feedback and ideas are much appreciated!
I’ll be attending tomorrow but just wanted to share an agenda item ahead of time. Specifically, I want to flag this new page called “Keeping up with Gutenberg” and to encourage people to give feedback for how it can be improved! Props to @bph and @williampatton.
For task coordination: I’m working on adding labels to the editor icon buttons (10524 and 15311). I’ve done an initial PR to add an option to show labels, but it only affects the post editor for now. I think we’re going to need this functionality in the site editor too, and am wondering what would be the best way of having a setting that works across both editors. Thoughts welcome!
In WordPress 5.5, the core blocks continue to evolve with the addition of new block tools.
Custom Line Heights
Users can define custom line heights for headings and paragraphs. Themes can opt-in into this feature by defining the custom-line-height theme support flag.
1
add_theme_support( 'custom-line-height');
Custom Units
In addition to pixels, users can now use other units to define the height of Cover blocks. The available units are: px, em, rem, vh, vw. Themes can opt-in into this feature by defining the custom-units theme support flag.
1
add_theme_support( 'custom-units');
Themes can also filter the available custom units.
Before 5.5, WordPress relied on hosting provider or user settings and plugins to handle purging or invalidating of core, plugin, and theme PHP changes. This resulted in problems for users like PHP fatal errors when a cached file included a file that had been deleted during an update.
As of [48160], WordPress attempts to invalidate PHP files when Core, Plugins, or Themes are updated.
To help with this, a new function is available, wp_opcache_invalidate(), a safe-to-call-directly wrapper for PHP’s native opcache_invalidate(). In order to avoid PHP warnings, the function handles the checks necessary to see whether OPcache is available, and whether invalidation is allowed by the current PHP settings.
The function includes a new filter, wp_opcache_invalidate_file, which allows disabling WordPress’ invalidation by file, in case it is necessary due to platform concerns, or there are certain files that a user wants to keep from being invalidated.
You can skip invalidation for one file like this:
1
2
3
4
5
6
7
8
9
// Disable opcode cache invalidation for `/path/to/myfile.php`.
And plugin authors everywhere, after years of reports like “your update seems to work fine, but in the moments after updating it these errors were logged, what should I do?” rejoiced!
This is good timing as I’ve been hesitant to make an update knowing it will throw fatal errors (for a few seconds at least) for some users.
This change doesn’t appear to be in the latest ‘bleeding edge nightly’ (You are using a development version (5.4.3-alpha-48366)), do you know when it will be?
Great news! I wish this was in 5.0!
I’m really exciting about this. This helps improving performance of websites and make WP sites look more “modern”.
Wow, this is great news, I’m sure a lot of people will love it. By the way, I did my bit by translating the plugin into Spanish.
Thank you! Yes, would be great if the explanation and testing instructions on the Test jQuery Updates settings screen are translated.
Since I have been using jQuery 3.x for years nows, I’m happy to see this change in core soon. Nice work!
That’s great! Have you run into any compatibility issues with core or WP themes or plugins?
Awesome!
This is great news 🙂
This is great news, but stops here?
It’s well known issue that jQuery size grows over time:
http://wayback.fauppsala.se:80/wayback/20200729170849/https://mathiasbynens.be/demo/jquery-size
and current one (3.5.1) is 287630 bytes, minified is 89476.
Why not announce “End of an era.” by switching to Vanilla JS?
Or Vue
Because this will break 1/3 of the web (+/-).
Never gonna happen.
How exactly would migrating WP core to vanilla, and then leaving jQuery as an optional dependency with a depreciation notice that devs should be using es6 + wp.scripts whenever possible break back-compat?
This is an amazing idea. I wish it was possible. But I’m sure it’s not gonna happen as it will break a lot of websites.
Right, the long term goal is to gradually migrate WP Admin to Vanilla JS. There is a lot of code to migrate, so it will take a while… Patches are welcome 🙂
Even if all of WP Admin is migrated to Vanilla, the jQuery libraries and plugins will still be available to enqueue through Script Loader, to maintain backwards compatibility.
where to start?
@azaozz best place to get involved is the js slack channel or somewhere else?
Best place to get involved in migrating WP Admin to Vanilla JS is to just do it 🙂
Identifying some (old) code that can be converted, opening a Trac ticket and adding a patch, and mentioning it in Slack would most likely bring other people that are interested.
(Old) jQuery plugins can also be replaced if they have Vanilla equivalents. See http://wayback.fauppsala.se:80/wayback/20200729170849/https://core.trac.wordpress.org/ticket/47069.
I’m glad this is proceeding!
Such a great news. Google PSI and Lighthouse is always telling update the jQuery. It has lots of vulnerabilities. Happy to hear it’s finally getting updated.
But on a side note I really think WP core should push devs to start using vanilla JS or Vue and stop using jQuery. Honestly jQuery is a lost cause. Javascript has come a long way since the jQuery days.
I tried out the plugin and so far everything works as expected, great work @azaozz! In the past we had seen issues with certain parts of the customizer breaking when we upgraded jQuery.
Thanks! Yes, I’ve heard about issues with some parts of the Customizer, but haven’t seen any, yet. Perhaps jQuery 3.5.1 plus jQuery Migrate 3.3.0 fixed them 🙂
Is there an official suggestion for plugins to be compatible with older versions of WP once they update their jQuery to be 3.x compatible?
If you know your plugin won’t work on older WP, you should:
1. Update the plugin headers so “Requires at least:” is set to the version you now support
2. Put in a version check on activation “If WP is less than 5.5, auto-disable”
The first one should prevent people on older WPs from updating, the second makes sure you don’t crash them.
I check both on minimum PHP version and WP version. I hope somebody could use this. This is what I do:
// Activation processregister_activation_hook( __FILE__, 'wp_jquery_manager_plugin_activation' );function wp_jquery_manager_plugin_activation() {if ( ! current_user_can( 'activate_plugins' ) ) {exit;}global $wp_version;$php = '5.6';$wp = '4.9';if ( version_compare( PHP_VERSION, $php, '<' ) || version_compare( $wp_version, $wp, '<' ) ) {deactivate_plugins( basename( __FILE__ ) );wp_die('<p>' .sprintf(__( 'This plugin can not be activated because either your WordPress instalation has an outdated/unsuported PHP version or you are using an outdated/old WordPress version.<br><br>This plugin requires a minimum of <strong>PHP 5.6 or greater</strong> and <strong>WordPress 4.9 or greater</strong>.<br><br> Your install:<br><strong>PHP: ' . PHP_VERSION . '</strong><br><strong>WordPress: ' . $wp_version . '</strong><br><br>You need to update either one of them or both, before you are able to activate and use this plugin.<br>- <a href="http://wayback.fauppsala.se:80/wayback/20200729170849/https://wordpress.org/support/update-php/" target="_blank" rel="noopener noreferrer">Learn more about updating PHP</a><br>- <a href="http://wayback.fauppsala.se:80/wayback/20200729170849/https://wordpress.org/support/article/updating-wordpress/" target="_blank" rel="noopener noreferrer">Learn more about updating WordPress</a>', 'wp_jquery_manager_plugin' ),$php). '</p> <a href="' . admin_url( 'plugins.php' ) . '">' . __( 'go back', 'wp_jquery_manager_plugin' ) . '</a>');}}See example on GitHub:
O! this is great news!