Only show a modified time tag if it's later than the created time

[leonidasmi]

Context

Summary

This PR can be summarized in the following changelog entry:

• Fixes a bug where the article:modified_time meta tag would show an earlier time than the article:published_time meta tag for scheduled posts.

Relevant technical choices:

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

• Go to add a post but instead of publishing it, schedule it in the near future
• Let's say you created it at 10:00am and scheduled it to be live at 10:05am
• Once 10:05am passes, go to check the post's page source (you may need to refresh your site a couple of times, so that the scheduled post gets actually published)

Without this PR:

• The article:modified_time meta tag would appear and it would be an earlier time than the article:published_time meta tag, which is wrong
• In the schema, the dateModified attribute of the Article and the Webpage nodes would appear and it would be an earlier time than the datePublished attribute of those nodes. (make sure you have filled in all Site Representation info to make the Article node appear)

With this PR:

• The article:modified_time meta tag would not appear at all
• In the schema, there will be no dateModified attributes in the Article and the Webpage nodes.
• Retry the test with different timezone and time formats from your Settings->General page

Also:

• To check an edge case, add the following filter that will remove the modified time from a created post:

function filter_post_modified_gmt( $data, $postarr, $unsanitized_postarr){
    unset( $data['post_modified_gmt'] );
    return $data;
}

add_filter( 'wp_insert_post_data', 'filter_post_modified_gmt',10,3);

• Create a post, remove the filter and check the post's frontend
• Confirm that you don't get a PHP notice and there's no article:modified_time and no dateModified attribute of the Article and the Webpage nodes in the schema.
• That's actually an improvement from our production versions, because if you repeated this test with those, you would get an invalid/wrong article:modified_time tags and dateModified attributes equal to -0001-11-30T00:00:00+00:00

Check impact in News SEO:

• After having a post published via schedule like above, activate News SEO and go to /sitemap_index.xml (that post should have been published within the past 48 hours)
• Check the Last Mod. value for the /news-sitemap.xml entry
• Go to /news-sitemap.xml and confirm that the Publication Date for the most recent article is the same with the Last Mod of the /news-sitemap.xml entry of the above step
• Go to the frontend of that most recent article and check that the date you took note of above, is the same date with the article:published_time meta tag and the datePublished attributes in the schema

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Default Block/Gutenberg/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

• The generation of the modified time of a post. Some things to test for regression:
  • Check that for non-scheduled posts, the meta tags and schema output is the same, both with this PR and without (make sure you fill in all Site representation settings)
    • Note: if a post has the same published and modified date in wp_post (so, same post_date_gmt and post_modified_gmt), it will stop having datePublished attributes in the schema
    • Which means that for posts that have been published normally and edited afterwards, meta tags and schema are exactly the same. For posts that have been published normally and not edited afterwards, they will have the same meta tags but for schema they might have datePublished removed with this PR. That depends on whether post_date_gmt and post_modified_gmt are the same in wp_post for that post (they might have a second difference depending how slow is your machine when saving the post)
  • Check the same for draft posts
  • Check the above for all sorts of timezones and time formats from your Settings->General page

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Other environments

• This PR also affects Shopify. I have added a changelog entry starting with [shopify-seo], added test instructions for Shopify and attached the Shopify label to this PR.

Documentation

• I have written documentation for this change. For example, comments in the Relevant technical choices, comments in the code, documentation on Confluence / shared Google Drive / Yoast developer portal, or other.

Quality assurance

• I have tested this code to the best of my abilities.
• During testing, I had activated all plugins that Yoast SEO provides integrations for.
• I have added unit tests to verify the code works as intended.
• If any part of the code is behind a feature flag, my test instructions also cover cases where the feature flag is switched off.
• I have written this PR in accordance with my team's definition of done.
• I have checked that the base branch is correctly set.

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label.
• I have added my hours to the WBSO document.

Fixes #

[coveralls]

Pull Request Test Coverage Report for Build eac11f3ba12c5b8b4dd7de1fd844f63ba3045242

Details

• 7 of 7 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.001%) to 54.387%

---

Totals
Change from base Build b602854da9bd10c690131950c0472809c3328df6:	0.001%
Covered Lines:	29940
Relevant Lines:	55466

---

💛 - Coveralls

[enricobattocchi]

Not sure I get why these were moved out of the array above?

[leonidasmi]

So that we keep the same order of the node's attributes.

Because it could be not as readable if we had dateModified far from datePublished