Account for ambiguity in matching templates by incorporating template priority order from core #1938
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a bug identified in https://wordpress.org/support/topic/amp-notice-on-woocommerce-product-search-page/
It turns out that if you have a custom post type registered (say
product
), this custom post type has an archive, and you do a search among the custom post types with a URL such as:The resulting
WP_Query
has bothis_search
andis_custom_post_type
set. WordPress will end up serving thesearch.php
template here because theis_search()
condition comes beforeis_post_type_archive()
check intemplate-loader.php
. Nevertheless, we were not taking this logic into account but are rather just issuing a warning when more than one template is matched:amp-wp/includes/class-amp-theme-support.php
Lines 577 to 593 in 3a2064e
Now that we see there is a case where template conditionals can be ambiguous, we need to incorporate the priority order of template conditional checks in order to make sure we select the same matching template as WordPress core will do.
The one additional consideration that the AMP plugin has to make here is the case where a site registers a custom template type that is outside of the WordPress template hierarchy entirely. Since such a template type would not be accounted for in the
template-loader.php
conditional, in this case we just use the custom matching templates by assuming they are more specific than the ones coming from core.This PR also fixes an issue with the build process where compiled files from other branches (e.g.
amp-stories-redux
) were not getting cleaned up and were unintentionally being included in the builds. So now those compiled files are all removed before invoking Webpack when doing a build.Build for testing: amp.zip (v1.1-alpha-20190307T202052Z-bef18cf6)