Help Test WordPress 6.5 Beta 3

This post is not covering all important features for testing in WordPress 6.5 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, more will come. The previous call with general instructions for testing can be found here.

If you want to help in testing but are not sure how to start, join the #core-test channel 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/. and ask for guidance. Seasoned testers will gladly point you in the right direction and share interesting stuff to play with. 


WordPress 6.5 RC1 is coming on 5 March 2024 which means String freeze – no new strings should be added or changed in the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to give Polyglots the ability to translate strings into different languages before the release. This is the time to pay careful attention to new strings. If you know English by heart, please test new features and check out the language.

Table of contents

Key features to test

I18n – Translations performance

WordPress 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. put great efforts into localization performance, and we can see significant improvement in translation loading.

TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket: #59656

Detailed information about the project:

Not all 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’s features went into the Core and the plugin is still useful with translations from PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php.-files that can benefit with OPcache.

Testing instructions

Special request to developers who maintain multilingual sites to test WordPress 6.5 with real data on staging versions of the real sites. Do it now and be confident when the time will come to update sites on production and benefit from this improvement.

General checks

  • Front end theme translations
  • Back end translations
  • Memory usage
  • Site speed
  • Compatibility with different plugins, including plugins for multilingual sites and plugins with huge amounts of strings
  • MultisiteMultisite Multisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core.https://codex.wordpress.org/Create_A_Network. translations
  • Absence of errors with different PHP versions (more: supported versions, recommendations)

Notes:

  • WordPress 6.5 has new or changed strings that are not available for translation until RC1. WordPress, themes and plugins can also have untranslated strings in languages you choose to test with. If you want to translate WordPress, follow the guidance in the Translator Handbook.
  • If you find an issue file a new ticket on Trac under the I18N component.
  • If you find an issue with a plugin or theme, please, report it to its developer.
  • The Query Monitor plugin is an active observer and can make an impact on the result as well.
  • Some strings can lack translation, and, in this case, they will be absent in 6.4 as well as 6.5 (with some exceptions as ‘Activate’ after plugin installation that looks the same but actually is a different string).
  • At this stage, the solution is working fine at first glance, and you have to be creative, notice details and take bold actions to get into every possible corner and dig deep to be sure that there are no hidden holes.

Fresh installations

  • Install 6.4 and 6.5 latest Beta/RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. with English default language keeping everything else the same.
  • Install Query Monitor plugin on both sites to check memory usage and execution time.
  • Debug settings
  • Change the default site language to another language
    • Check that translations are working in the Admin
    • Check that translation work on the front end (you will have by default Twenty Twenty-Four theme and it has strings for the front end)
    • Check that in general each 6.5 admin page uses less memory than 6.4 pages
    • Check that JS translations work, for example by clicking on the Apply button on the plugin page without selecting any plugins, install plugin, install theme, use Quick/Bulk Edit and change post/page attributes
  • Change the user language to another one adding a third language. If you know the RTL language, please check it and mix with LTR.
  • Install a lot of languages to check that the system will still be quick with this number of languages.
  • Install plugins that have translations in chosen languages (one of the most popular will most likely be one of them) and check that translations are identical.
  • Install a classic theme and check its translations.

If we missed some aspects that should be checked, please leave a comment below this post.

Plugin dependencies

Logic of installing, activation, deactivation and removal of plugins was reworked. This is a significant enhancement in addition to already existing safeguards during plugins installation for compatibility and errors checks. 

To get detailed information and find previous test calls, please, read Merge announcement

Testing instructions

Environment

  • Install WordPress 6.5 latest Beta/RC version
  • Debug settings
    • Enable Debug and Debug log
    • Keep Console open to notice JS and ajax/REST request errors
  • Remove all plugins
  • Install Query Monitor plugin and keep it active (it will show PHP errors if they will accrue)
  • Pay attention to details during the process

General checks

Plugins without dependencies should be installed, activated, deactivated, uninstalled, enabled/disabled to auto-updates as before (single or bulk). 

  • Install several plugins
  • Activate plugin
  • Activate several plugins using Bulk action
  • Install old versions of plugins via file upload
  • Update one plugin
  • Update several plugins using Bulk action
  • Try to install plugin that will cause fatal error (invent nonexistent function, for example)
  • Deactivate one plugin
  • Deactivate several plugins using Bulk action
  • Delete a plugin
  • Delete several plugins using Bulk action
  • Did the same with Enable/Disable auto-updates

Test dependencies

  • Installation: Dependents can only be installed via Plugins > Add New if their dependencies are installed.
  • Activation: Dependents anywhere (Plugins > Installed plugins / Plugins > Add New / modals / WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ / after installing via ZIP) can only be activated if their dependencies are activated first.
  • Deactivation: Dependencies can only be deactivated on Plugins > Installed plugins (single or bulk), if their dependents are deactivated first.
  • Deletion: Dependencies can only be deleted on Plugins > Installed plugins (single or bulk), if their dependents are deleted first.

Steps to follow

Prepare several plugins and zip them into own archives to install via admin

  1. my-hello-dolly/my-hello-dolly.php
<?php

/**
* Plugin Name: My Hello Dolly
* Requires Plugins: hello-dolly
*/
  1. my-car/my-car.php
<?php

/**
* Plugin Name: My Car
*/
  1. my-car-trailer/my-car-trailer.php
<?php

/**
* Plugin Name: My Car Trailer
* Requires Plugins: my-car
*/
  1. game-stone/game-stone.php
<?php

/**
* Plugin Name: Game Stone
* Requires Plugins: game-scissors
*/
  1. game-paper/game-paper.php
<?php

/**
* Plugin Name: Game Paper
* Requires Plugins: game-stone
*/
  1. game-scissors/game-scissors.php
<?php

/**
* Plugin Name: Game Scissors
* Requires Plugins: game-paper
*/
ActionExpected behaviour
1. Install ‘My Hello Dolly’ plugin via Plugins > Add New
– Activate plugin
Plugin is installed
Error message
Dependency is not installed automatically
2. Install ‘My Car Trailer’ plugin via Plugins > Add NewPlugin is installed
3. Activate ‘My Car Trailer’ pluginPlugin is not activated
Error message
4. Install and activate ‘My Car’ plugin
– Activate ‘My Car Trailer’ plugin
Plugins are activated
‘My Car’ plugin has no link to deactivate
5. Deactivate ‘My Car Trailer’ plugin
– Deactivate ‘My Car’ plugin
Plugins are deactivated
‘My Car’ plugin has no link to delete
6. Delete ‘My Car Trailer’ plugin
– Delete ‘My Car’ plugin
Plugins are deleted
7. Install and activate ‘My Car’ plugin
– Install and activate ‘My Car Trailer’ plugin
– Manually delete ‘My Car’ plugin in the wp-content folder
– Open Plugins page in admin
‘My Car’ plugin will be deactivated due to its absence
‘My Car Trailer’ will still be active
Notice message
8. Add plugins ‘Game Paper’, ‘Game Scissors’, ‘Game Stone’ into wp-content folderWarning on the plugin page about invalid requirements 

These are only expected behaviour.

Now it is time to be creative and think about other possible scenarios. Write them down before actually testing and check if your expectations are matching what is happening.

Remember to check the Test Dependencies section above so that your expectations meet the current status of the feature.

Other improvements

Focus styles updated for full WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. compliance

Trac ticket #51870

The focus style for form inputs, buttons, and links styled as buttons, which was first introduced in WordPress 5.3 (#34904), has been fully updated in WordPress 6.5. In WordPress versions prior to 6.5, the focus styles were inconsistent across different elements like inputs, buttons, and links.

This update modifies the focus styles for all interactive elements to be consistent with the styles introduced in WordPress 5.3, in order to meet WCAG accessibilityAccessibility 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) standards for minimum colour contrast ratios.

Please help test consistency of focus styles for form inputs, buttons and links styled as buttons with this video to guide you.

Fixing inappropriate pointer cursor on disabled form controls in WordPress

Trac ticket #59733

WordPress 6.5 introduces a fix for an issue where disabled form controls in WordPress were still showing a pointer cursor instead of the default cursor.

Previously, WordPress set all form controls and their label elements to use cursor:pointer to highlight that they are interactive. However, when a control is disabled or has `aria-disabled=”true”`, using a pointer cursor is inappropriate and doesn’t follow web standards.

The issue affected disabled checkboxes, radio buttons, and other form controls throughout WordPress, including in 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/ editor. While WordPress traditionally hides disabled controls rather than disabling them, there were still instances of improper cursor styling.

To address this, the change makes sure labels and disabled form controls, including those with aria-disabled, use the default platform-dependent cursor. This follows web accessibility standards and fixes the confusing pointer cursor on disabled controls. Interactive controls will still use a pointer for consistency with WordPress’ prior styling.

Testing instructions

  • Go to Settings > Reading
  • Make sure ‘Your homepage displays’ is set to ‘Your latest posts’.
  • Hover the mouse on the ‘Homepage:’ and ‘Posts page:’ disabled select elements.
  • Observe the mouse cursor is the default one.
  • Hover the mouse on the disabled select elements labels.
  • Observe the mouse cursor is the default one.
  • Install and activate the Link Manager plugin.
  • Add a new link.
  • In the form to create a new link, check the checkbox at another web address of mine.
  • Observe all the following checkboxes and radio buttons get disabled.
  • Hover the mouse on all radio boxes, checkboxes, and their labels.
  • Observe the mouse cursor is always the default one.

Media: AVIF support enabled

Trac ticket #51228

WordPress 6.5 introduces native support for uploading, editing, and saving images in the AVIF (AV1 Image File) format, provided the server has the required AVIF libraries installed.

The AVIF image format utilises the intra-frame encoding techniques of the AV1 video codec to offer drastically improved compression ratios compared to older image formats like JPEG, PNG, and even newer ones like WebP.

By incorporating AVIF encoding and decoding into the media functions, WordPress 6.5 allows users to upload AVIF files and take advantage of the file size savings, typically around 30-50% over JPEG/PNG for equivalent visual quality. Edited AVIF images can also be resaved while preserving alpha transparency and colour profiles.

Testing instructions

  • Verify your WordPress install supports AVIF — check Tools-> Site Health -> Info tab -> (expand) Media Handling section. Either GD or Imagick must have “AVIF” listed.
  • Upload an AVIF image to a post or the media library. Some test images are available in the libavif repository.
  • Test features like cropping and rotating in the media library and the editor
  • Test viewing post in all supported browsers (Browserstack would be great for that)
  • Test using the image_editor_output_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. to output AVIF’s for uploaded JPEGs, noting JPEG/AVIF file sizes with/without the filter.

The order of loading the import map and script modules has been changed. Now, the import map is loaded first, followed by the script modules. This fixes an issue where incremental import maps would fail if loaded after the script modules.

In classic themes, the import map and script modules are now loaded in the footer rather than the head. This is because the proper order (import map first) can’t be guaranteed when printing in the head in classic themes.

Testing instructions

Create a plugin with a dependency between two script modules and an import map. You can either follow the instructions below to create a test plugin, or simply download this test plugin.

Create a new plugin with three files:

test-plugin/test.php

<?php
/*
* Plugin Name: Test Script Modules
* Version: 1.0.0
*/

wp_register_script_module( 'bar', plugins_url( '/bar.js', __FILE__ ) );
wp_enqueue_script_module( 'foo', plugins_url( '/foo.js', __FILE__ ), array( 'bar' ) );

test-plugin/foo.js

import bar from 'bar';
bar();

test-plugin/bar.js

export default function bar() {
 console.log( 'bar' );
}
  • Upload the plugin on your test website.
  • Activate the plugin.
  • Open your site (frontend).
  • Check that “bar” was printed in the console.

To check that this fixes the positioning of the scripts/link in the classic themes:

  • Load a 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. theme (Twenty Twenty-Four or another)
  • Check that the scripts with type=”importmap” and type=”module”, and the link with rel=”modulepreload” are printed in the head.
  • Load a classic theme (Twenty Fourteen)
  • Check that the scripts with type=”importmap” and type=”module”, and the link with rel=”modulepreload” are printed in the footer.

Please share feedback as soon as you can before the final release on March 26, 2024.

What else you can do

  • Share this post to advise other WordPress developers, DevOps, QA specialists, and site owners to join efforts in testing.
  • Ask your local meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. organizers to make a meetup about testing, QA, and release cycles. 
  • Subscribe to the Test Team blog to get further information and updates. You may also subscribe to the Core Team blog to stay in the loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. with Core updates, including the latest “Week in Core” posts.
  • Join our regular Test Team meetings in the #core-test Slack channel, where you can get real-time updates, get help with testing, or discuss tricky cases. Participate in team meetings and test scrubs every week to engage in the testing community.
  • Do you have suggestions for how this post can be improved? Please leave a comment below.

A big thank you to @oglekler, @lumiblog, @vipuljnext@swissspidy@costdev@ankit-k-gupta and @webtechpooja  for contributing to this post.

#6-5, #test

Weekly Meeting Time Change Announcement

Based on our poll results and what we got from our Proposal to change the Weekly Meeting Time post, we concluded our next meeting time. The new meeting time is as follows:

As of this week, the bi-weekly Test team chat meeting will change from 16:00 UTC to 11:00 UTC. This will be reflected in our next meeting, which will be on December 19, 2023.

Along with the Bi-weekly Test team Triage meeting, it will change from 16:00 UTC to 11:00 UTC. This will be reflected in our next triage meeting, which will be on December 12, 2023.

#meeting, #test

Test Team Chat Summary: 14 September 2021

The meeting started 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/. here.

Short explanation for first time attendees

@hellofromtonya reminded, that this bi-weekly meeting is where people who test WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. gather to discuss important things regarding test contribution. Testing includes manual testing, attempting reproduce reported issues, and automated testing.

You can find the agenda meeting here.

Week in Test introduction

@hellofromtonya described the purpose of this weekly publication, in short, it includes:

  • Parts of the core where testing help is needed this week
  • Learning and reading opportunities

Team agreed that it’s very helpful.

Last week’s Team update introduction

@hellofromtonya reminded that it’s a Team update, an overview of what has happeed last week. It also includes stats that are related to our team.

The Team agreed that the queue of the items that need testers’ attention is long.

Focal group updates

@hellofromtonya explained that it’s a time for testers to share updates for testing project initiatives. This section has started with:

  • PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. 8.1 fixes are underway
  • Modernization to Latest PHPUnit project is nearly finished. Backporting is next, then dev note
  • PHPUnit Test modernization is ongoing

@hareesh added:

  • The latest version of jQuery UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. was recently merged to Core. Need a lot of testing.

Documentation strategy

@francina opened this discussion, asking what instructions we want to give. The main reason was related to setting up environment.

@hellofromtonya proposed to create a docs empowering everyone to contribution, we need clear entry points for:

  • Local machine setups
  • How to do different types of testing
  • How to create test reports

Team agreed that this documentation should be present in Make Test website, Make Core should only refer to it.

@hellofromtonya mentioned, that PHPUnit docs page lacks a reference to where contributors can set up their local machines. That should be a priority.

@francina @juhise @hellofromtonya agreed that the Team should start documenting the steps for Docker testing environment and later repeat the same pattern for other solutions. On of the concerns is that screenshot are getting outdated very quickly.

@mkaz shown 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’s development site setup instructions based on wp-env. Team agreed that all projects should be pointing to one place where everything related to development environment is stored and maintained.

@hellofromtonya proposed a step-by-step instrctions of creating documentation for different types of test environments:

  • Start with Docker
  • Setups on Make Test with reference in Make Core
  • Figure out the doc info structure / strategy
  • Doc for different OS: Windows, Mac, and Linux
  • Link to tooling’s official docs
  • Get feedback from contributors
  • Refine
  • Repeat

@francina proposed working session with setting up environments. It’s going to happen on 2021-09-23 14:00

People with different OS will be essential for the successful meeting.

@boniu91 shared a reminder that on 2021-09-17 13:15 the Test Scrub is going to happen taking care of the following tickets:

#build-test-tools, #core-test, #test