Use get_post_states to denote special pages on the added menu item accordions

[garrett-eclipse]

This is a follow-up ticket to #37782 which introduced the use of get_post_states to denote special pages in the menu editor. When a special page is selected and added to the menu now the item is just denoted as Page but would be nice to follow suit and denote it as appropriate (Front Page, Posts Page, Privacy Policy Page).

[garrett-eclipse]

Patch to denote special pages (Front Page, Posts Page and Privacy Policy Page) when inserted into the menu

[garrett-eclipse]

Before (All pages are just denoted as 'Page')

[garrett-eclipse]

After (special pages are denoted properly)

[garrett-eclipse]

I've uploaded a patch and screenshots to illustrate the change.

[garrett-eclipse]

Also related to the Customizer ticket that's pending commit - #46829

[SergeyBiryukov]

In 47211:

Menus: Use get_post_states() to denote special pages on the added menu item accordions.

Front Page, Posts Page, or Privacy Policy Page should now be marked as such on the added menu items.

Props garrett-eclipse.
Fixes #49374.

[SergeyBiryukov]

Since get_post_states() is only available in the admin, this is causing fatal errors on front end:

Fatal error: Uncaught Error: Call to undefined function get_post_states() in wp-includes/nav-menu.php:82

[SergeyBiryukov]

In 47213:

Menus: When adding a label for special pages in wp_setup_nav_menu_item(), check if get_post_states() is available, to avoid fatal errors on front end.

Fixes #49374.

[garrett-eclipse]

Thanks @SergeyBiryukov appreciate the catch, I overlooked that was also available to the front-end.

[stiofansisland]

In the original use case for the get_post_states() function to add statuses to the pages backend is not escaped, this allowed several plugins to add hints to the output:

Now in the edit menu screen it is escaped which causes issues:

I would be nice to keep the hints but if not an option then esc_html() should be replaced with wp_strip_all_tags()

[SergeyBiryukov]

Replying to stiofansisland:

Now in the edit menu screen it is escaped which causes issues:

It would be nice to keep the hints but if not an option then esc_html() should be replaced with wp_strip_all_tags()

Thanks for catching that! Since we're in late RC stage for 5.4, going with the latter option for now seems safer.

[SergeyBiryukov]

In 47458:

Menus: When adding a label for special pages in wp_setup_nav_menu_item() strip all HTML tags, as the label is escaped on output.

Follow-up to [47211], [47213].

Props stiofansisland.
Fixes #49374.

[SergeyBiryukov]

Reopening for backporting to the 5.4 branch after a second committer's review.

[SergeyBiryukov]

In 47465:

Menus: When adding a label for special pages in wp_setup_nav_menu_item() strip all HTML tags, as the label is escaped on output.

Follow-up to [47211], [47213].

Props stiofansisland.
Reviewed by whyisjake, SergeyBiryukov.
Merges [47458] to the 5.4 branch.
Fixes #49374.

[SergeyBiryukov]

In 48619:

Posts, Post Types: Make get_post_states() available on frontend.

This allows special pages to be denoted as such when editing a menu in the Customizer.

This applies to the Front Page, Posts Page, and Privacy Policy Page.

Follow-up to [47211], [47213], [47763].

Props dlh, whyisjake, SergeyBiryukov.
Fixes #46829. See #49374.

[SergeyBiryukov]

In 48620:

Posts, Post Types: Move get_post_states() back to the admin for now, require the file in WP_Customize_Nav_Menus::customize_register() instead.

This provides a minor performance improvement by only running the function in contexts where it's needed.

Follow-up to [47211], [47213], [47763], [48619].

See #46829, #49374.