Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix usage of amp_register_polyfills hook #7458

Merged
merged 13 commits into from Feb 7, 2023
Merged

Conversation

thelovekesh
Copy link
Collaborator

@thelovekesh thelovekesh commented Feb 7, 2023

Summary

This PR accounts for the following changes:

  • Make changes to the Webpack config to fix the default export in @wordpress/dom-ready package.
  • Remove amp_register_polyfills from the following services/classes:
    • PairedBrowsing -> This service has a conditional of has_support from DependecySupport which means it will work only on WP >= 5.6 so no polyfills are required. Also, this service has no dependency on React so we can keep it on our plugin.
    • ValidationCounts -> This service has a conditional of has_support from DependecySupport which means it will work only on WP >= 5.6 so no polyfills are required. Also, this service has no dependency on React so we can keep it on our plugin.
    • AMP_Template_Customizer -> We have disabled AMP customizer on WP < 5.6 so no polyfills required. Also, this service has no dependency on React so we can keep it on our plugin.
  • Disable AMP customizer on WP < 5.6

With this, we only have the following services left which use amp_register_polyfills only on their dedicated screens:

  • OnboardingWizardSubmenuPage
  • OptionsMenu
  • SupportScreen

Fixes #7457

Checklist

  • My code is tested and passes existing tests.
  • My code follows the Engineering Guidelines (updates are often made to the guidelines, check it out periodically).

…hook when screen is AMP options menu section
@github-actions
Copy link
Contributor

github-actions bot commented Feb 7, 2023

Plugin builds for 56daefa are ready 🛎️!

@@ -89,8 +89,9 @@ public function register() {
* Enqueue admin assets.
*/
public function enqueue_scripts() {
/** This action is documented in includes/class-amp-theme-support.php */
do_action( 'amp_register_polyfills' );
if ( $this->is_options_menu() ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, actually maybe this won't work as expected? Let's say you're not on the Settings screen. In this case, the polyfills won't be registered and the result will be possibly that the required scripts are not registered, right?

I think the way to address this is to remove the logic here and move it to is_needed, so that the logic runs if:

We have the expected version of React or we're on one of the AMP settings screens.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, the polyfills won't be registered and the result will be possibly that the required scripts are not registered, right?

Since it has 'wp-api-fetch', 'wp-dom-ready', 'wp-i18n' as dependency scripts while wp_enqueue_script, WP will enqueue them for it... right? I think WP prior to 5.6 already has these scripts' support and below 5.6 we are not exposing this service.

return Services::get( 'dependency_support' )->has_support() && Services::get( 'dev_tools.user_access' )->is_user_enabled();

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have the expected version of React or we're on one of the AMP settings screens.

amp-validation-counts.js doesn't require React for its operation. Here is the dependecies for this:

<?php return array('dependencies' => array('wp-api-fetch', 'wp-dom-ready', 'wp-i18n'), 'version' => '29b558177338ddf7e50f');

) {
$this->rest_preloader->add_preloaded_path( '/amp/v1/unreviewed-validation-counts' );
}
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For is_needed the conditions may need to be expanded to account for all of these screens and subscreens:

image

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want the ValidationCounts service to be needed only on the AMP settings menus?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be on all screens when we core is shipping the expected version of React, but otherwise it can be limited to only the AMP settings pages.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ValidationCounts doesn't have any dependency on React and uses 'wp-api-fetch', 'wp-dom-ready', 'wp-i18n'(which also doesn't have any dependency on React). So I think we can keep it on all screens.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good point. Nevertheless, we will need to not register the polyfills for this since the polyfills are unconditional now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is, unless we limit the service to only run on our dedicated screens. But probably simpler to just remove the polyfill registration entirely for this. Since the service is already conditional based on whether it has_support, there doesn't seem to be any need for polyfills anyway, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we can remove polyfills for it entirely as it's conditional based on has_support.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the amp_register_polyfills hook from the ValidationCounts service.

@@ -330,8 +330,12 @@ public function add_customizer_scripts() {
$dependencies = $asset['dependencies'];
$version = $asset['version'];

/** This action is documented in includes/class-amp-theme-support.php */
do_action( 'amp_register_polyfills' );
if ( ! Services::get( 'dependency_support' )->has_support() ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside: This is essentially re-making the Polyfills service conditional which was removed in #7421

Interestingly, also, there are some cases where this will never be reachable:

function amp_init_customizer() {
if ( ! Services::get( 'dependency_support' )->has_support() ) {
// @codeCoverageIgnoreStart
add_action(
'customize_controls_init',
static function () {
global $wp_customize;
if (
Services::get( 'reader_theme_loader' )->is_theme_overridden()
||
array_intersect( $wp_customize->get_autofocus(), [ 'panel' => AMP_Template_Customizer::PANEL_ID ] )
||
isset( $_GET[ QueryVar::AMP_PREVIEW ] ) // phpcs:ignore WordPress.Security.NonceVerification.Recommended
) {
wp_die(
esc_html(
sprintf(
/* translators: %s is minimum WordPress version */
__( 'Customizer for AMP is unavailable due to WordPress being out of date. Please upgrade to WordPress %s or greater.', 'amp' ),
DependencySupport::WP_MIN_VERSION
)
),
esc_html__( 'AMP Customizer Unavailable', 'amp' ),
[
'response' => 503,
'back_link' => true,
]
);
}
}
);
// @codeCoverageIgnoreEnd
}
// Fire up the AMP Customizer.
add_action( 'customize_register', [ AMP_Template_Customizer::class, 'init' ], 500 );

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside: This is essentially re-making the Polyfills service conditional which was removed in #7421

But only for customizers right?

Interestingly, also, there are some cases where this will never be reachable:

Actually, added it as a safeguard. Should we remove it? What if it surpassed the condition in any case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unsure. Maybe what we should do is just change amp_init_customizer to just return early if ! Services::get( 'dependency_support' )->has_support().

And then at the same time, we can remove all of the amp_register_polyfills actions from this class. What this means is that the custom AMP Customizer integrations won't be available on WP<5.6, but that's effectively the earliest version we support anyway.

Additionally, Customizer usage is declining.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this means replacing all of the contents of this if condition:

if ( ! Services::get( 'dependency_support' )->has_support() ) {
// @codeCoverageIgnoreStart
add_action(
'customize_controls_init',
static function () {
global $wp_customize;
if (
Services::get( 'reader_theme_loader' )->is_theme_overridden()
||
array_intersect( $wp_customize->get_autofocus(), [ 'panel' => AMP_Template_Customizer::PANEL_ID ] )
||
isset( $_GET[ QueryVar::AMP_PREVIEW ] ) // phpcs:ignore WordPress.Security.NonceVerification.Recommended
) {
wp_die(
esc_html(
sprintf(
/* translators: %s is minimum WordPress version */
__( 'Customizer for AMP is unavailable due to WordPress being out of date. Please upgrade to WordPress %s or greater.', 'amp' ),
DependencySupport::WP_MIN_VERSION
)
),
esc_html__( 'AMP Customizer Unavailable', 'amp' ),
[
'response' => 503,
'back_link' => true,
]
);
}
}
);
// @codeCoverageIgnoreEnd
}

With just return.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you mean:

if ( ! Services::get( 'dependency_support' )->has_support() ) {
		return;
}

We can also remove the @codeCoverageIgnore right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's right.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or rather, you can make it:

if ( ! Services::get( 'dependency_support' )->has_support() ) {
    return; // @codeCoverageIgnore
}

@westonruter westonruter added this to the v2.4 milestone Feb 7, 2023
Copy link
Member

@westonruter westonruter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! This is now ready for QA. 🎉

@westonruter westonruter merged commit 81b1307 into develop Feb 7, 2023
@westonruter westonruter deleted the fix/polyfills-service branch February 7, 2023 22:56
@westonruter westonruter added the Changelogged Whether the issue/PR has been added to release notes. label Feb 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changelogged Whether the issue/PR has been added to release notes.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Polyfills are being registered for Web Stories editor and breaking screen
2 participants