Discovery to ensure all relevant WordPress actions/filters are AMP compatible

[MackenzieHartung]

Acceptance Criteria

AC1: Conduct a Discovery to ensure all relevant WordPress actions/filters are AMP compatible
AC2: Create an issue/issues as an outcome of the Discovery.

Tasks

• Catalog all actions and filters that are triggered in the course of rendering a WordPress template, and then identify which ones are problematic for AMP. For example, wp_head, wp_footer, primarily what Core uses to output code in template, in particular the printing of scripts and stylesheets, wp_print_head_scripts.

[DavidCramer]

Key actions called during render of a template

Action	State	Note
wp	✅
template_redirect	✅
get_header	✅
wp_enqueue_scripts	✅
wp_head	❌	Calls main header rendering functions - wp_resource_hints: can add preconnect, prefetch, and prerender links; locale_stylesheet: can include additional stylsheets; print_emoji_detection_script: adds additional script tags; wp_print_head_scripts: prints out header scripts; wp_custom_css_cb: renders header styles;
wp_print_styles	❌	outputs multiple style tags
wp_print_scripts	❌	outputs multiple script tags
pre_get_search_form	✅
loop_start	✅
the_post	✅
get_template_part_content	✅
loop_end	✅
get_sidebar	✅
dynamic_sidebar	✅
get_search_form	✅
pre_get_comments	✅
wp_meta	✅
get_footer	✅
get_sidebar	✅
wp_footer	❌	Calls footer rendering functions - wp_print_footer_scripts see below:
wp_print_footer_scripts	❌	renders footer scripts.

Filters to aid in making the above actions compliant

Filter	Note
locale_stylesheet_uri	returning false can prevent adding additional stylesheets in wp_head action.
wp_resource_hints	returning an empty array can stop wp_resource_hints from adding preconnect, prefetch, and prerender
print_late_styles	returning false can prevent rendering additional styles in the footer on wp_footer
print_footer_scripts	returning false can prevent rendering scripts in the footer on wp_footer

The above filters can be used to solve xwp/ampnews#7

[westonruter]

Is wp_resource_hints something we need to block?

[DavidCramer]

@westonruter I think it would be safe. That particularly aids in rendering in a browser, which is not necessary in AMP.

[DavidCramer]

@westonruter I think I got this all listed now and is ready to be reviewed.

[westonruter]

I think it would be safe. That particularly aids in rendering in a browser, which is not necessary in AMP.

Aside from removing the emoji_svg_url from the resource hints array, I don't see how AMP would make them all obsolete. I think we can safely keep them.

[westonruter]

@DavidCramer Would you take your findings and then open a PR to incorporate them into https://github.com/Automattic/amp-wp/blob/develop/includes/class-amp-theme-support.php ?

The existing code is removing actions, but perhaps some of the filters you discovered would be preferred.

Note that wp_custom_css_cb is removed and its output is replaced to be added to the AMP custom CSS.

Then you can look specifically at comments in #797 and #862, and the unique filters and actions that occur there which will need to be hooked into.

[DavidCramer]

@westonruter Will do. I spoke briefly to @ThierryA on this yesterday. will sync with him again and move forward. Thanks!

[westonruter]

@DavidCramer Here's the info from @amedina re: Resource Hints:

Resource hints still make sense with AMP. One use case is preloading a hero image in the first viewport:

<link href=hero.png rel=preload>

Another use case is preconnect for Google fonts (the WP plugin could do this even automatically!):

<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>

Another thing we should consider is adding a default preload for v0.js:

<link href=https://cdn.ampproject.org/v0.js rel=preload>

[DavidCramer]

@westonruter nice one!