New plugin with no extra per page settings overhead but only behavioral mod
-
Could you make a separate very simple plugin which just alters default behavior of the relationship post status ?? menu visibility and brings no extra per-page administrative overhead? (Btw: No offense! Valid use case!)
Altered behavior: In the menu of certain allowed user roles (default: Admin + Editor) the menu items for pages with an unpublished status are nevertheless visible. For Logged-Out users or disallowed roles they remain invisible in the menu of course!
What do I mean by administrative overhead of your plugin? In addition to the post status which one has to work with anyhow when working in WordPress, one needs to set the extra option “Who can see this link?” per each menu-item/page. Possible advantageous to set the two independent from each other certainly! But extra effort and error prone if all I want is to change the post status ?? menu visibility behavior. Then I’d prefer that this is simply all derived from the post status only.
I wonder why this obviously desire-able user scenario / workflow did yet not make it into WordPress: Admins & editors can get the full “soon to be” website UX — that is they see page content AND also how the new content will fit into the menu (important part of the UX!) — whereas disallowed users see neither.
From your plugin description I guess you have all the necessary subject matter knowhow and/or codebase for this.
BACKGROUND INFO:
Page Status & Visibility in Menu
- If a page has the post status “Publish” and is present somewhere in a menu, it is visible there.
- If the status is not Publish but Draft, Pending Review, Future, Private then:
a) ? … requesting a page as an anonymous user (aka Logged Out) gives you a HTTP 404 Not Found. All fine with that.
b) ? … navigating in the menu as anonymous user, the corresponding menu items are invisible. All fine with that.
c) ? … navigating in the menu even with a top privilege user role (Admin or Editor) does not show you the pages! Why???
There is no good reason for this!
c1) Security: No argument. Page access is anyhow independent from menu visibility. In some cases merely the revealing of a Menu Item Name by itself may be enough of a security breach, e.g. new yet not revealed product or campaign. But still the role system should guard that too ofc!
c2) Performance: No argument either. Caching / web acceleration will still be there for the big majority of users (anonymous or read-only subscribers, etc). And Logged-In users anyhow have no or only reduced caching.
c3) User Experience: No argument either. On the contrary. Being able to open pages only via direct URL entry or from the Backend UI instead of the most natural and integrated way — the normal menu! — Why should this be benefitial?
I can’t think of any good reason. I guess it is simply historic legacy and nobody yet challenged it. Users certainly asked for it but it never got enough momentum I guess.
Page Hierarchy & Menu — Can be independent or in sync
- Creating a page not necessarily adds it to the menu.
a) WordPress Core offers: Menu Settings → ? Automatically add new top-level pages to this menu.
b) Plugin Nested Pages allows that for each page (regardless where in hierarchy) when using: ? Sync Menu. - A page has its position in the hierarchy, e.g. /cat or deeper like /animals/cat :
a) A menu structure by default is independent from the page hierarchy.
b) You can ofc manually recreate the menu accordingly.
c) Or sync page hierarchy to a menu automated with plugins like Nested Pages.
- The topic ‘New plugin with no extra per page settings overhead but only behavioral mod’ is closed to new replies.