When updating the JavaScript bundle build process in a recent PR, the publicPath being used by webpack for dynamic imports was hardcoded to wp-content/plugins/font-awesome/admin/build.
This is fine most of the time. But it's incorrect when installed on a server that has moved paths around somehow, or when installing this plugin via composer into a theme or plugin. Our own integration test plugin (plugin-sigma) demonstrates this.
The JavaScript bundle was including a version of React that may not have matched some WordPress environments.
This can work fine when our code is the only React code running on a page, such as on our admin page. But it doesn't work when integrating with the Block Editor (Gutenberg)--can't mix versions of React there.
Changes
move the JavaScript build process from Create React App to the more fitting-for-WordPress @wordpress/scripts.
use webpack's magic variable __webpack_public_path__ to dynamically set the loading path for webpack at run time, using a value provided by the server on page load.
make React, ReactDOM and the @wordpress packages all externals to the JavaScript bundle, so they are not loaded, thus avoiding conflicts.
declare dependence on those corresponding JavaScript libraries in wp_enqueue_script() in WordPress >= 5.4. Thus, use the versions available from WP Core at run time.
For WordPress 4 and < 5.4 , where the JavaScript libraries in WP Core are too old for us, load our own compat-js/build/compat.js as a dependency of our main bundle. Disable the Icon Chooser's integration with Gutenberg for these earlier 5.x versions, so as not to mix the earlier version of React that
Leverage code splitting and dynamic imports to only load the JavaScript needed for each scenario: admin page, conflict detector, or icon chooser (editor integration)
Known Limitations
Our JavaScript uses React hooks, which only became available in React 16.8.0, and it uses createInterpolateElement from @wordpress/element, for which there was experimental support in that package's v2.10.0, and stable support in v2.12.0.
Those conditions were not all met in WP 5 Core until about WP 5.4 (March 31, 2020), which uses @wordpress/element: ^2.11.0 that depends upon React ^16.9.0.
So this PR limits support for the Icon Chooser feature on a Gutenberg page at the 5.4 line.
All other features of the plugin continue to function for WP 5 prior to 5.4.
Even the Icon Chooser still works on earlier WP 5 on post editing pages that involve only the Classic Editor--as long as it's not also a Gutenberg page.
A descriptive warning is emitted to the JavaScript console on Gutenberg pages for those older WP 5.x versions in order to make it easy to identify and resolve the compatibility problem by upgrading WordPress to at least 5.4.6 (the currently latest in the 5.4 line with all of the most recent security fixes).
robmadole
commented
2 years ago
Problems addressed by this PR:
When updating the JavaScript bundle build process in a recent PR, the publicPath being used by webpack for dynamic imports was hardcoded to
wp-content/plugins/font-awesome/admin/build.This is fine most of the time. But it's incorrect when installed on a server that has moved paths around somehow, or when installing this plugin via composer into a theme or plugin. Our own integration test plugin (
plugin-sigma) demonstrates this.The JavaScript bundle was including a version of React that may not have matched some WordPress environments.
This can work fine when our code is the only React code running on a page, such as on our admin page. But it doesn't work when integrating with the Block Editor (Gutenberg)--can't mix versions of React there.
Changes
@wordpress/scripts.__webpack_public_path__to dynamically set the loading path for webpack at run time, using a value provided by the server on page load.React,ReactDOMand the@wordpresspackages all externals to the JavaScript bundle, so they are not loaded, thus avoiding conflicts.wp_enqueue_script()in WordPress >= 5.4. Thus, use the versions available from WP Core at run time.compat-js/build/compat.jsas a dependency of our main bundle. Disable the Icon Chooser's integration with Gutenberg for these earlier 5.x versions, so as not to mix the earlier version of React thatKnown Limitations
Our JavaScript uses React hooks, which only became available in React 16.8.0, and it uses
createInterpolateElementfrom@wordpress/element, for which there was experimental support in that package's v2.10.0, and stable support in v2.12.0.Those conditions were not all met in WP 5 Core until about WP 5.4 (March 31, 2020), which uses
@wordpress/element: ^2.11.0that depends upon React ^16.9.0.So this PR limits support for the Icon Chooser feature on a Gutenberg page at the 5.4 line.
All other features of the plugin continue to function for WP 5 prior to 5.4.
Even the Icon Chooser still works on earlier WP 5 on post editing pages that involve only the Classic Editor--as long as it's not also a Gutenberg page.
A descriptive warning is emitted to the JavaScript console on Gutenberg pages for those older WP 5.x versions in order to make it easy to identify and resolve the compatibility problem by upgrading WordPress to at least 5.4.6 (the currently latest in the 5.4 line with all of the most recent security fixes).