"Keyphrase in slug" assessment won't ever make sense on a static home…

[mykola]

Context

• Remove "Keyphrase in slug" assessment for static home page.

Summary

This PR can be summarized in the following changelog entry:

• Removes the keyphrase in slug assessment for static home pages.

Relevant technical choices:

• To check if current page is the static home page on php side page_on_front option is compared it with the currently editing page.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

• Create new page.
• Put some content
• Add a title.
• Add keyphrase that not appear in the title.
• Save the page so slug is generated and should not contains keyphrase in slug.
• Make sure that "Keyphrase in slug" assessment is appeared.
• In Settings->Reading set the page as a HomePage.
• Check Keyphrase in slug again - it should not be present any more.
• Repeat for Elementor editor.

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.

QA can test this PR by following these steps:

Impact check

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

• Should not impact any other part.

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 #20118

[coveralls]

Pull Request Test Coverage Report for Build 263f79589aeaf693e2fd35f4480b26ef13e4f829

Details

• 5 of 13 (38.46%) changed or added relevant lines in 5 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.003%) to 54.503%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
admin/metabox/class-metabox.php	0	4	0.0%
src/integrations/third-party/elementor.php	0	4	0.0%

Totals
Change from base Build 32b600b34fc231b69fc8fbfa337f57bbd2d09c3b:	-0.003%
Covered Lines:	29539
Relevant Lines:	54468

---

💛 - Coveralls

[mhkuu]

Hi @mykola,

Can you please check the following:

• There were some problems after merging, I fixed those in 51eb005, please review that commit 😄
• There are currently two ways implemented on the PHP side to set the isFrontPage variable. Only one needs to stay.
• If we use the metabox script data (which I think is preferable), this approach won't work when the metabox is not used, for example, in Elementor, which only has the sidebar integration. We would then also need to add this setting to src/integrations/third-party/elementor.php.
• It would be good to cast get_option( 'page_on_front' ) to an int, see e.g. admin/class-admin-recommended-replace-vars.php.

There are also some issues with the PR:

• The "changelog: enhancement" label should be attached.
• The "UI change" label should be removed.
• The test instructions are not very clear, you also need to set a keyphrase to enable the assessment.
• The situations under "relevant test scenarios" should be selected. As suggested above, it would be good to check this in all editors.
• The "Fixes" comment should refer to the issue ("Keyphrase in slug" assessment won't ever make sense on a static homepage #20118). Doing so automatically links the PR to the issue when the PR is based on trunk.

[mhkuu]

CR: Looks good now, thanks a lot for addressing my comments! 👍 There's something to say for moving the Elementor code from collectData into getAnalysisData, but that can be part of a larger refactor of that integration.

ACC: Works! 🎉

The test for PHP 7.3 is failing, but that's because of SVN trouble on the WordPress side, I'll wait on that before merging!