Ensure compatibility with WP 7.0

[gabrielcld2]

Approach

• Review and test integration with upcoming 7.0 WP release. Priority of this ticket is to ensure functionalities remain as they are once WP 7.0 is released
• Review deprecation warnings and fix the ones that can be fixed without large refactoring
• Upgrade WP Core minimum required version to allow using more recent functionalities

Some notable exceptions of issues that couldn't be resolved:

Gallery settings page

The suggested replacement is still marked as experimental. It would be risky to use an experimental component that might change its API within our plugin (our linter advice against it too). Remaining on the deprecated (but still working) component seems safer.

Gallery block

The gallery block styling is enqueued via the enqueue_block_editor_assets hook at the moment. Ideally we should migrate to using a block.json file combined with editorStyle property... however the structural changes are quite large so we might need to have a separate refactor task to upgrade the gallery block to apiVersion 3 with block.json support.

apiVersion 3 means full iframe support within the editor. Unfortunately this doesn't work well with the current structure of this block, as it's currently loading the gallery widget for a live preview within the editor. This is sort of related to the above issue.

QA notes

• Follow any recommended method here to install the latest WP 7.0 RC
• Perform some overall regression testing of the plugin, particularly:
  • the gallery settings page
  • the gallery block on the editor

[PatelUtkarsh]

PR looks good!

[gabrielcld2]

Some further changes were introduced:

Compatibility with WP 5.6

There are still users on WP 5.6+ using this plugin therefore we're ensuring this version keeps being supported for now.

This required some changes:

• remove apiVersion from gallery block
• runtime fallback to previous deprecatedrender call if createRoot isn't available
• reintroduce isSecondary props usage on Button component (along side the new prop). This ensures both old and new WP versions works
• Switch JSX transform from automatic to classic runtime. See details below:

JSX transform

@wordpress/scripts defaults to the automatic JSX transform (runtime: 'automatic'), which compiles JSX to calls into react/jsx-runtime. WordPress registers this as the react-jsx-runtime script handle, but only from WP 6.6
onwards. On older versions the handle is undefined, causing a fatal JS error at runtime.

To fix this, the babel-loader rule from @wordpress/scripts is patched in webpack.config.js to prepend @babel/plugin-transform-react-jsx with runtime: 'classic'. Because Babel runs explicit plugins before preset plugins,
this transform fires first and converts all JSX to React.createElement calls, leaving nothing for the preset's automatic transform to process.

A ProvidePlugin entry injects React from @wordpress/element into any module that references it, so JSX files don't need an explicit import. wp-element has been available since WP 5.0, making this safe across all
supported versions.

Compatibility with PHP 7.4

While manually testing this on WP 5.6 and PHP 7.4, I noticed a fatal error related to str_contains being used (which is a PHP 8 function). Updated this.

I performed an audit to check for any other PHP 8 only features being used but didn't find any.
Manual testing the plugin didn't raise any issue either.

[PatelUtkarsh]

Hello @gabrielcld2,

Re: PHPCS not catching str_contains

This is actually by design in PHPCompatibilityWP. The ruleset explicitly excludes str_contains because WordPress ships a polyfill for it in wp-includes/compat.php since WP 5.9. Since we now support WP 5.6+, that polyfill isn't available on 5.6-5.8; but PHPCS has no way to know our "Requires at least" version; it only checks PHP version compatibility.

Your fix to use strpos() is the right call. As suggested in Slack, we can also add this in phpcs.xml.dist to avoid this in future in this PR:

<!-- Re-enable PHP 8.0 function checks excluded by PHPCompatibilityWP.
     Their WP polyfills only exist in WP 5.9+, but we support WP 5.6+. -->
<rule ref="PHPCompatibility.FunctionUse.NewFunctions.str_containsFound">
    <severity>5</severity>
</rule>
<rule ref="PHPCompatibility.FunctionUse.NewFunctions.str_starts_withFound">
    <severity>5</severity>
</rule>
<rule ref="PHPCompatibility.FunctionUse.NewFunctions.str_ends_withFound">
    <severity>5</severity>
</rule>
<rule ref="PHPCompatibility.FunctionUse.NewFunctions.array_key_firstFound">
    <severity>5</severity>
</rule>
<rule ref="PHPCompatibility.FunctionUse.NewFunctions.array_key_lastFound">
    <severity>5</severity>
</rule>

[PatelUtkarsh]

Looks good. Clean approach for backward compat across WP 5.6+. Left two nit-picks. @gabrielcld2

[PatelUtkarsh]

💡 thought: Should we say requires 5.6?

[PatelUtkarsh]

💬 suggestion: terms-order.js now uses wp.i18n._x() but only declares jquery as a dependency. wp-i18n is available at runtime because wp_enqueue_media
loads media-views which pulls it in via set_translations(), but that's an implicit dependency. Should we add wp-i18n explicitly just to be safe?