Denote the special pages in Customizer Menu editor

[garrett-eclipse]

Hello,

It was mentioned while working through #37782 that the special page labels (Front Page, Posts Page and Privacy Policy Page) would also be beneficial on the Customizer Menu editor.

Opening this to branch from there as it's focus for 5.2 will be the standard menu editor.

Cheers

[garrett-eclipse]

Customizer Menu w/ an important page. Would be nice to label it

[garrett-eclipse]

Special page labels being introduced to menu items in #37782

[audrasjb]

Hi @garrett-eclipse thanks for the ticket

Moving to the next minor since that would be nice to fix this inconsistency issue in 5.2.x branch.

[garrett-eclipse]

Thanks @audrasjb, sadly #37782 got pushed till 5.3 so I hope you don't mind I have bumped this to match and allow us to release the updates in tandem.

[audrasjb]

Add privacy policy page specific page to customizer menu liste and search tool

[audrasjb]

Privacy Policy page in Pages List

[audrasjb]

Privacy Policy page in Search Tool

[audrasjb]

Patch refreshed

[audrasjb]

Coding standards + add condition if check if the privacy policy page exists

[audrasjb]

The patch still applies cleanly on trunk.
Tested again and the patch looks ready for commit in my opinion.

[desrosj]

I have a few questions I'd like clarified before this can be deemed ready.

@garrett-eclipse Can you clarify the original intent of the ticket? As I understand it, you are saying that all three of those special page types should be denoted in the Customizer and your screenshot just happened to show the Privacy Policy. Is that correct?

Also, although these pages are "special", I'm not convinced that adding them to the menu as a custom type is the correct behavior. Home is kind of an outlier because there usually is not an actual page in WordPress for "home".

For example, say someone selects the page selected as the Privacy Policy page on their site, and then a week later, they change the URL slug for that page. The link would then be a 404. If the menu item was added as a regular Page item, the URL would update automatically.

[garrett-eclipse]

Refreshed patch to align with sister ticket #37782

[garrett-eclipse]

All the important pages labelled according to get_post_states

[garrett-eclipse]

Pages added in customizer still take precedence

[garrett-eclipse]

Search also applies the label, and if you have Front page set 'Home' is suppressed

[garrett-eclipse]

Thanks for the ping @desrosj my goals here was to align with #37782 which introduces the get_post_states function and prioritizes the 3 important pages (Front Page, Posts Page, Privacy Policy Page).

@audrasjb thank you very much for the initial patch pointed me in the right direction there. But I agree we shouldn't be using a custom link type for these pages as @desrosj mentioned it can cause 404's on slug changes.

The Customizer approach and the core menu approach are very similar so I've migrated most of the code from #37782 into patch 46829.3.diff which addresses the following;

1. Introduces the important pages at the top of the list.
2. Updates the label on important pages on the list and in search to use get_post_states and fall page to the post_type singular name.
3. I found a bug where the Home custom page stays even if you have a homepage, I've put the same checks as #37782 in both the load and search functions so Home will only be present if no Front Page is set.
4. I kept the user-created menu nodes at the top above all so when created they don't get lost.
5. In #37782 there was some code to set special flags on the objects, I avoided these as we don't use the objects aside from cloning them into the $items[] array so those flags wouldn't be present.
6. In #37782 there was also a reset if the important pages were all the pages, this isn't necessary in the customizer version as the merge will end up with the same results with or without it.
7. In #37782 we made the label bold, attempting this hear didn't have the desired effect and caused it to look odd as the title was already bold so I didn't carry over that CSS here, how the label weight is now, works much nicer IMO.

Aside form #5 & #6 this is a code re-implementation of the committed #37782 and would be nice to have it join it's sister in trunk.

Please test and review. I feel if we can get another test on this we should be good to move into commit.
CC @whyisjake - Flagging you as you committed #37782 so might want to have a review here.

[audrasjb]

Hi,
Thanks for the work done on this ticket.
Unfortunately, we are now at Beta 3 in the release cycle. I'm moving this ticket to 5.4 early milestone.
Feel free to discuss it if you feel this ticket could land before 5.3 Release Candidate 1.

[garrett-eclipse]

Minor refresh

[garrett-eclipse]

I've made a minor refresh in 46829.4.diff to update some spacing and comments and remove the change to src/wp-admin/includes/class-walker-nav-menu-edit.php as it's unrelated to this change.

The patch applies cleanly and introduces the special pages handling to the Customizer menus.

@audrasjb or @desrosj could you review and test, this is good to go in my books.

Note: I removed the early tag as this can be merged anytime before RC and doesn't need much special handling as there doesn't seem to be any back-compat potential here.

[garrett-eclipse]

Some additional cleanup for CS. Also removed second call to get_post_states to use $post_states as it's made available before the conditional. No change in actual functionality

[audrasjb]

It looks good to go on my side! Thanks @garrett-eclipse

[garrett-eclipse]

Thanks @audrasjb I appreciate you testing let's move this to committers review.

[garrett-eclipse]

Moving to 5.5 early

[whyisjake]

In 47763:

Menus: Denote the special pages in the Customizer menu editor.

The special pages here are the pages that are used for the Privacy Policy, Home, and the Posts page.

Fixes #46829.
Props garrett-eclipse, audrasjb.

[whyisjake]

I didn't want to block the merge, but it might be worth ensuring those labels are brought up a level in the customizer screen too @garrett-eclipse.

[SergeyBiryukov]

Reopening to address comment:23.

[audrasjb]

Removing early keyword.

[dlh]

@audrasjb @garrett-eclipse I see what you mean about this last Customizer piece being tricky. I don't have any Customizer-specific ideas about how to handle it, unfortunately.

46829.6.diff​ is a tentative approach, but it still involves some logic duplication, and I haven't been able to completely think through any backwards compatibility implications.

[audrasjb]

Not sure it deserves a dev note since it doesn't introduce any new function or filter WordPress developers and/or Plugin authors can use. Not sure it introduces any breaking change for them as well :)
Feel free to re-add the keyword if you think I'm wrong :-)

[audrasjb]

needs-dev-noteadded back as it will deserver a small place in the miscellaneous changes dev note :)

[SergeyBiryukov]

Replying to dlh:

@audrasjb @garrett-eclipse I see what you mean about this last Customizer piece being tricky. I don't have any Customizer-specific ideas about how to handle it, unfortunately.

It looks like moving get_post_states() from wp-admin/includes/template.php to wp-includes/post.php, so that it's also available on frontend, is enough for the existing code in wp_setup_nav_menu_item() added in [47211] to handle this without any additional changes to the Customizer.

[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.

[desrosj]

Looking this one over, I'm not sure I see anything here that needs to be detailed in a developer note. I'm going to remove the tag.

If I am missing something specific that should be noted, (how to properly use the new feature, how to adjust the behavior of the new feature, etc.), just let me know! But it seems that this change will mostly "just work" without any changes required by plugin/theme devs.