Closed max-ostapenko closed 10 months ago
@tunetheweb seems like workflows in many cases run from base branch, skipping the changes from the head branch.
Again I expected to test the new parsing right here, but had to use a separate repo. Hope I covered it all and it will succeed after merging.
@tunetheweb seems like workflows in many cases run from base branch, skipping the changes from the head branch.
Don't understand what this means? I thought that's what the checkout of the head branch gets around:
The workflow file is fetched even before we do checkout. So there is no way to modify it when the workflow is already running.
Oh, ok. So we should be able to test it running with pull_request
event.
In WordPress specific HTTP Archive research, we've so far typically relied on only home pages of each origin. However, home pages tend to have different layout than many other pages have, and our assumptions on e.g. performance are not segmented in any way regarding content type. It would be helpful to e.g. differentiate between specific performance patterns commonly applied on home pages vs on singular posts.
Therefore this PR introduces a WordPress specific content type detection, based on the body classes that the CMS outputs by default. The PR adds 3 fields with information:
contentType
: This is the most important field and can have one of the following values:
home-blog
: The home page showing the blog (of latest posts).home-page
: The home page showing a "static front page" (as configured in WordPress).blog
: The blog (of latest posts) if configured to not also be the home page (only relevant when the home page is showing a "static front page").singular
: Any kind of singular content, e.g. a single post, page, etc.archive
: Any kind of archive content, e.g. a post type or taxonomy archive.unknown
: None of the above could be detected.postType
: The post type of the current content, or empty if not applicable based on the contentType
. This field should have a value for any content type, except for a taxonomy archive.taxonomy
: The taxonomy of the current content, or empty if not applicable based on the contentType
. This field should have a value only for a taxonomy archive.Some WebPageTest tests with this logic (using @westonruter's site as test candidate):
Test websites:
Fixed issues with escaping markup code.
Related to workflow run issues in #96.