Allow users to more seamlessly create page-based nav menus during customization

[westonruter]

Upon first installing WordPress, new users may find themselves in the Customizer to set up their site, given the big blue Customizer button on the Dashboard. The new user experience (NUX) is one area highlighted in the ​roadmap. The number of tasks the user can do in the Customizer is largely a subset of what they can do in the WP admin. Most notably, one of the first things that a user may want to do is add pages to their site. I understand that new users to WordPress do not understand the nav menu item vs page distinction, and in the Customizer I am guessing that many users would expect to be able to add nav menu items for all of the pages they want to be on their site, whether they exist yet or not. This is not currently possible in the Customizer, meaning that users get stuck and have to exit the Customizer to create the pages and then come back into the Customizer to then create the nav menu items. This user ​flow blockage is a poor experience.

Authorship via Nav Menus

I propose that the UI for selecting an item to add a nav menu item should be extended with a button to add a new instance of the item type right there in the Customizer. If wanting to add a new page, then an editor overlay can appear over the preview which allows the user to supply the standard post/page fields such as the title and content via a TinyMCE editor (also allowing the setting of the featured image and page template would be useful, since these cannot be previewed via Post Preview either). This could serve as a first step toward a full post editor experience in the Customizer in a UI similar to ​Calypso on WordPress.com, but starting with just the title and content we can get our feet wet. Perhaps we could even fully re-use the ​post-editor in Calypso.

☞ Nota bene:

• I am not suggesting to add a post editor to the Customizer narrow pane, due to lack of space.
• Nothing would be removed from the post editor in the WP admin.
• The WP admin editor is where all of the plugin metaboxes would be accessible.
• Upon Save & Publish, the user can be provided edit post links to continue editing the newly added posts/pages in the WP admin to flesh out the basic content they added in the Customizer. In other words, the editor in the Customizer would be more like Quick Draft feature than the full post editor.

If adding a page in the Customizer via a nav menu item, it could also default the post_parent and menu_order to correspond to the location of the nav menu item when possible so that the page hierarchy could roughly correspond to the nav menu item hierarchy.

(To be clear, being in the Customizer, all manipulation of post/page content would be previewed: no changes would be written to the DB until hitting Save & Publish.)

Editing Existing Content

The same editor interface could also be used to edit existing posts and pages. There could also be a top-level panel for “Content” with sections for “Posts” and “Pages” which would allow editing any post/page that currently appears in the preview. The ​Customize Posts feature plugin has been developed which implements a proof of concept for this.

There should be edit post links added to nav menu item controls, for any nav menu item representing a saved post or page. This would currently have to open in a new tab, but eventually it could also open an in-Customizer editing experience.

[celloexpressions]

This would be awesome.

As a first pass, my suggestion would be to focus on getting the basics working by focusing on the most fundamental issue - the dead-end caused by not having the ability to create content when setting up menus. I think an interface that lets users quickly create items by title only (no content, URL, or other fields) would be pretty doable within the nav menus UI and could facilitate creating multiple, for example, pages, at once. It may not make sense to have this functionality on by default for other post types (like Posts), but would definitely be useful for taxonomies as well, which would need the hierarchy option, when present (same for pages probably).

Once content can be populated via titles, a solution such as an edit button for all nav menu items including new ones could be added that opens a larger editing-oriented interface. Personally I still think that editing the main post contents in the preview via the things the front end editor plugin has been experimenting with would be the best bet, but I don't think we're quite ready to nail down the best approach there yet (then the panel/sections for post objects would contain what is traditionally in metaboxes). Something that creates empty content by title, though, seems very doable for 4.5 both in terms of UI and backend.

[celloexpressions]

Possible UI - inline under list

[celloexpressions]

Possible UI with a button under the list that opens a separate page where item(s) can be added.

[celloexpressions]

Possible UI: full width input with action buttons that slide up with then input is focused (slides back when the input or buttons are unfocused).

[celloexpressions]

I've attached a few possible UI options for this feature:

• An input field & button under the list of available menu items to create a new item of the selected type and add it to the menu.
• A button to add a new item that then opens a separate interface over the list for actually adding it.
• A full-width input with placeholder text and the action buttons become visible with the input sliding up over the list once it's focused.
• A full width input (as above) with placeholder text and no (visible) buttons - must hit enter to add and no choice to create without adding to the menu (possibly not something we should support anyway).

Anyone have thoughts on those options or any other ideas to propose? We also need to decide which menu item types should have support for creating new items from within menus. It may not be as useful for posts, but it may be better to include it for all types for consistency.

We should hammer out the UX as soon as possible to make sure we can get this in to 4.5. Would anyone be interested in doing structured user testing once we have a functional (or even just clickable) prototype?

[melchoyce]

As a first pass, my suggestion would be to focus on getting the basics working by focusing on the most fundamental issue - the dead-end caused by not having the ability to create content when setting up menus. I think an interface that lets users quickly create items by title only (no content, URL, or other fields) would be pretty doable within the nav menus UI and could facilitate creating multiple, for example, pages, at once.

Huge +1.

Of the suggested solutions, I think 34923.possible-ui-input-under-list.PNG​ is the most elegant, but might not work for non-English languages due to space constraints. This could be mitigated by dropping the button label down to just Add.

I don't think having both Create Page & Add to Menu and Create Page makes sense in this context. Creation should be used to facilitate the primary action of this panel, which is making your menu.

[westonruter]

After the settings are published, and any newly-created pages are inserted, a message needs to be displayed to allow the pages to be further edited. This can be done with #35210 at a global level via a notification area, but individual nav menu items for pages can also have an edit link.

[chriscct7]

Punting to next release per discussion with @westonruter

[westonruter]

I've been working on this feature in the context of the ​Customize Posts plugin. The following videos were taken chronologically as additional features and refinements have been made (e.g. the last video introduces the TinyMCE editor).

1) Demonstration of hooking into edit post links so that they actually work in the Customizer and expand the section to edit the given post (as opposed to the link doing nothing at all when clicked), as well as shift-clicking on the title and content (needs better discovery UI, see #27403):

2) Demonstration of integration with ​Customize Setting Validation (#34893) to gracefully handle failures to save due to post locking and concurrent user editing:

3) Demo featuring the WP visual rich text editor (TinyMCE), including the insertion of images from the media library. Post content can be edited in the Customizer and previewed in multiple contexts. For example, this allows you to preview how a Read More tag will appear when the post appears on a post list page, and you can navigate to the single post to continue previewing subsequent paragraphs. You can expand the editor into a full-screen mode to focus on writing and then quickly preview the changes on the site by toggling the editor. You can make changes to as many posts as you want, but none of the changes will go live until you hit Save & Publish: everything is previewed so there is no “save and surprise”.

[mrahmadawais]

Hey, @westonruter !
Everything looks great. A few suggestions, though.

— We can use type="date" here (In the old W.org repo version)

— I really like the idea of Open Editor, I think as the editor opens, the customizer window should be minimized so that one could write in a full width WYSIWYG editor.
E.g.

Which also means that there can be full width and height version or full width and half height version. Button for saving would close the editor and open the customizer window.

[westonruter]

@mrahmadawais thanks for the feedback. Could you open these as issues on the GitHub project? It will be easier to discuss them over there.

[mrahmadawais]

Replying to westonruter:

@mrahmadawais thanks for the feedback. Could you open these as issues on the GitHub project? It will be easier to discuss them over there.

Sure! GitHub it is!

[celloexpressions]

Per Slack conversation linked above, the goal for 4.5 is to introduce the customize-posts framework (which should probably get its own ticket) with one UI feature - the ability to create page stubs from nav menus. This will likely be title-only, with links to the admin to edit pages once they've been created.

Per the above discussion the UI goal should probably be similar to 34923.possible-ui-input-under-list.PNG​. We'll need to decide whether this is applied to all available post types and taxonomies or only pages initially.

[westonruter]

Related: #36879 (add filtering for WP_Post::get_instance() in Customizer preview)

[celloexpressions]

First-pass for inline UI, with an input and button at the bottom of each supported available menu item type, and a filter for disallowed types.

[celloexpressions]

With 34923.ui.0.diff​.

[celloexpressions]

34923.ui.0.diff​ contains a first-pass at the UI for this in the available menu items panel, including a filter to disable it on a per-content-type basis. The next step is to build out the handlers for these fields so that a new menu item is created along with a corresponding post (in the following step) and added to the menu. Finally, we'll need to show information about newly-created posts in the notifications area in #35210.

We'll also need to make sure that the new item is added to the available menu items panel and ideally made searchable there as well, in case users want to add it to another menu.

I'd like for this to go through a progressive review process as each piece of the patch is completed, to avoid holding things up at the end since timing is expected to be tight. Once the next piece (essentially making the "add" button work) is ready, I'll ask for design and accessibility review, as the remaining parts after that are largely internals.

[celloexpressions]

Add event handlers to create-items UI, add menu items to menus. Needs the part that actually creates new posts, which is being worked on in the customize posts plugin.

[celloexpressions]

With [attachmnet:24923.ui.1.diff].

[celloexpressions]

34923.ui.1.diff​ contains a complete pass at UI for creating new post and term objects and adding them to menus. This part is now ready for design and accessibility review, while the remaining pieces are worked on.

Remaining work:

• Add the new item to the available menu items list.
• Create the new content object associated with the new menu item, and connect it to the menu item and its position in the available menu items panel.
• Ensure that the new object can be previewed, and searched for in the available menu items panel.
• On save & publish, show a notification (info) that links to edit the new objects in wp-admin (in new tabs).

I believe that @valendesigns is currently working on the add-posts process, with help from @westonruter, with a goal of having it ready by next week. That should be able to tie into the UI patch at the locations with @todos.

[westonruter]

Changes: ​https://github.com/xwp/wordpress-develop/compare/6ff7e10...7dd1886?w=1

[westonruter]

In 34923.2.customize-posts.diff​ I removed the ability to add new nav menu items for taxonomy terms; this is due to there not being any facility to create “auto-draft” taxonomy terms that will get garbage-collected if they don't get promoted. We can revisit that later I think.

But more importantly, this patch adds integration with the the Customize Posts plugin so that when you add a nav menu item for a post, page, or other CPT, it will actually create an auto-draft and link the nav menu item to it. You are able to navigate to the newly-created auto-draft post that is linked to in the nav menu.

This depends on some Customize Posts code that is currently in a pull request pending merge. @valendesigns has been the major contributor here. The key JS API from Customize Posts is the wp.customize.Posts.insertAutoDraftPost() function. Customize Posts also provides the PHP filters for ensuring that the auto-draft post will be accessible in the preview, and also so that the auto-draft will be transitioned to a publish status when the Customizer state is saved. (Customize Posts also allows you to edit the actual auto-draft post/page itself, including the title, content, and other fields, but this post editing functionality is out of scope for this ticket.)

PR from Customize Posts: ​https://github.com/xwp/wp-customize-posts/pull/134

[celloexpressions]

@westonruter we should keep the filter that's in 34923.ui.1.diff​ (probably with better naming), including the post_type|taxonomy part for future compatibility, so that this feature can be disabled for certain or even all post types if desired.

[westonruter]

@celloexpressions instead of a filter, I think it would be better as a property on the post type object itself. For example, in Customize Posts we've added support for a show_in_customizer option to go alongside show_in_nav_menus, show_in_rest, and so on.

[mapk]

After some discussion about the recent gif on Slack there were two points made that could be explored further.

1. Should new items that are being added also get added to the menu automatically? Or should this be a two step process where I would add the item to the list first, then move it over to the menu?

2. How and where do new items show in the list above the input field? Right now there doesn't seem to be any immediate feedback to the user that the item was successfully added to the list.

[afercia]

Worth considering there is a big issue for keyboard users with the current implementation. Being the input field to create new items at the bottom of the items list, keyboard users would have to tab through the entire list.
Especially about posts, these can potentially be hundreds and... the items list uses infinite scroll. Thus, users would be forced to tab dozens (or hundreds) of times before they can reach the input field.
Not arguing, but maybe this is because the current implementation tries to use a UI that has been designed for a different task and just doesn't fit this new use-case.

Right now, the only solution I can think off the top of my head would be moving the "Create new" field at the to of the list, maybe initially collapsed and with a button to expand it, as for example Press This does for Categories. You can see Press This on your local WP install: /wp-admin/press-this.php. UI people with more experience than me could certainly think at better solutions. I'd just like to invite everyone to consider the functionality, visual, interaction, and the accessibility issues at the same time :)

[celloexpressions]

Note following up on the discussion in #design, 34923.ui.1.diff​ can and should be tested for the UI (without needing the plugin), but don't hit save & publish as the menu items aren't real. Delete them before saving.

@westonruter I don't think a post type parameter would be appropriate here because it's basically an extention of show_in_nav_menus, with a specific part of that UI. Generically showing it in the customizer in the context of customize-posts would mean something different and shouldn't necessarily be tied to the menus interface as well (in addition to not being appropriate for core yet; this would presumably be more related to being able to edit content in the customizer I think, and should be saved for that future use). So I think the best behavior would be for it to be on by default, but able to be disabled with a filter so that core types could also be disabled if desired.

@mapk (and everyone who participated in the design chat): the placement when adding to the list of menu items will be tricky. However, if it's added to the bottom of the list it will always trigger an infinite scroll, for each item added, and as a result the new items wouldn't be next to each other. The best option is probably to insert them at the top so that they're all together. Since this would cause the list to jump down anyway, it should probably auto-scroll to the top when this happens (but that would only happen once if multiple consecutive items are added). Since this is designed to be most useful during the site setup context, this decision won't ultimately matter too much since these would be the first items in the list.

Regarding a separate step to add to menu, I think that would be excessive, similar to 13. Since the primary flow here is to create items so that they can be added to the menu, auto-adding to both places is probably the most appropriate action. If it were a two-step process this flow would become fairly cumbersome, especially for keyboard-only users, but also with touch, especially when adding multiple items at a time. Since we're targeting the site-setup flow primarily, auto-add to the menu is probably the best approach, and there is an existing workflow to remove (and bulk-remove) items from there if a user changes their mind. I would also guess that new users would have trouble understanding the additional step of adding to a menu, based on previous user testing with the old and new menus interfaces (we should user-test that).

@afercia My thought in terms of accessibility would be to move it to the top of the list in tab order but keep it at the bottom visually. Infinite scroll is definitely an accessibility challenge here; pretty much the only way to sanely navigate the available menu items panel is to tab back up to collapse the section before moving to the next one, and putting the input at the top in terms of the html structure would make that easier from there. Perhaps a bit disorienting to jump like that, but probably better than the alternative.

[celloexpressions]

@boonebgorges following up on the discussion in devchat, we need some guidance here with respect to terms.

Are there any future plans to introduce a term_status field, similar to post_status? In the customizer, there is currently no mechanism to create draft terms that become published when the customizer is saved and published. As a result, terms would need to be published immediately, which goes against the customizer's principles of previewing everything and publishing nothing before the user is ready, but aligns with the way terms work everywhere else (for example, when added to post drafts).

Another possible option might be an internal taxonomy for drafted terms in the customizer. Would you foresee that creating issues with the direction core is taking taxonomies and terms currently?

For this ticket, the current question is whether we should wait for future core support for draft terms, investigate the viability of an internal taxonomy for draft customizer terms, or publish terms immediately when they're added in the context of menus, similarly to what happens in the post editor and elsewhere. There is currently some disagreement regarding the acceptability of immediately publishing terms, but that may be necessary based on your perspective on these issues.

[afercia]

Replying to celloexpressions:

pretty much the only way to sanely navigate the available menu items panel is to tab back up to collapse the section before moving to the next one

Yep, this is an outstanding issue for those long lists where maybe using Escape to collapse the section would make sense, but that's for a separate ticket :)

[boonebgorges]

Replying to celloexpressions:

@boonebgorges following up on the discussion in devchat, we need some guidance here with respect to terms.

Are there any future plans to introduce a term_status field, similar to post_status? In the customizer, there is currently no mechanism to create draft terms that become published when the customizer is saved and published. As a result, terms would need to be published immediately, which goes against the customizer's principles of previewing everything and publishing nothing before the user is ready, but aligns with the way terms work everywhere else (for example, when added to post drafts).

Another possible option might be an internal taxonomy for drafted terms in the customizer. Would you foresee that creating issues with the direction core is taking taxonomies and terms currently?

For this ticket, the current question is whether we should wait for future core support for draft terms, investigate the viability of an internal taxonomy for draft customizer terms, or publish terms immediately when they're added in the context of menus, similarly to what happens in the post editor and elsewhere. There is currently some disagreement regarding the acceptability of immediately publishing terms, but that may be necessary based on your perspective on these issues.

I share your discomfort with the idea of immediately publishing draft terms. This is highly likely to result in odd behavior that's hard to debug.

There are no current plans for term_status. I did a couple Trac searches and can't find any mention of the idea.

That being said, I think it's a decent idea. However, it's going to be complex to implement. Even if we don't have anything as robust as a "term status API", we still have to be sure that, at the very least, term_status != 'publish' terms are excluded from most queries - a change that has the potential for weird back compat issues.

An "internal taxonomy for drafted terms in the customizer" sounds more conservative in the short term, but I'm unsure what it'd look like in practice. Would there be a *single* internal taxonomy to represent all registered taxonomies? It's hard to see how this would work: taxonomies can be hierarchical or not, which will probably affect the UI and functionality of the customizer "Add" experience; there are probably also issues with internationalization/strings when you use a single taxonomy for this purpose. It may be easier (maybe more code, but fewer hacks) to do on-the-fly registration of a separate internal taxonomy for each taxonomy that's getting a draft term added via the Customizer.

My take is that term_status is a much more natural and elegant way to solve this, but it's going to take a lot of work and may not happen for a couple versions. One or more internal taxonomies for representing draft terms is a clunky solution, but it can probably be implemented more or less right away - especially now that taxonomies can properly be marked as public=false #21949. I don't think that internal taxonomies like this will pose any serious compat problems in the future. If the general consensus is that it's important for there to be parity between posts-in-the-Customizer and terms-in-the-Customizer in the relatively short term, I'd go with the internal taxonomy idea.

[celloexpressions]

Complete first pass at functionality, no plugin dependency (and customize posts conflicts so it needs to be deactivated). Create auto-draft posts and publish them when the user saves & publishes. Add new content to the available menu items panel, and improve the tab order for accessibility. Prevent race conditions by only allowing one new post to be submitted at a time.

[celloexpressions]

34923.3.diff​ is a complete functional first-pass without the plugin dependency.

The necessary bits of the Customize Posts plugin have been extracted to the patch, but accordingly, the plugin must be deactivated before the patch will work.

The patch also includes the following iterations:

• Create auto-drafts for new posts, and publish them when the user saves & publishes in the customizer.
• Add new content as items in the appropriate available menu items panel section, at the top, and auto-scroll to it.
• Place the new content inputs before the list of available menu items in the taborder for improved keyboard accessibility.
• Only allow one item to be added at a time, and wait for the post to be successfully added on the server before adding the item to the menu (this is how customize-posts works, and probably necessary although it slows the experience down).
• For now, support for terms will be punted to a future ticket, with the information @boonebgorges provided as a basis for research on the best approach.
• Restore the disallowed new content types filter, with future support for taxonomies, as its purpose is in between show_in_nav_menus and show_in_customize for post type registration.
• Use the loading spinner when adding an item.
• Items can be added to other menus once they're created.

This patch is ready for testing (including user testing), accessibility, docs, and dev feedback. @westonruter and @valendesigns have been working through several edge cases that are causing issues for the customize posts plugin; we'll need to identify which also apply here (not being able to edit the newly-added posts simplifies things here).

The biggest known to-do is showing links to edit the newly-published items when they're published, which would ideally use #35210. We could also put in a temporary solution for now that will leverage that API when it becomes available in the future.

[celloexpressions]

Refresh

[celloexpressions]

​https://make.wordpress.org/core/2016/06/16/feature-proposal-content-authorship-in-menus-with-live-preview/

[ocean90]

Let's try to get this into 4.7...

[celloexpressions]

The next few weeks would be a great time for the reviews and feedback requested in the make/core post to happen so we're ready ahead of 4.7. We haven't had any comments here on the ticket since a complete patch was introduced - can anyone test the patch and/or review the code, docs, accessibility, design, etc?

[celloexpressions]

Add info notifications to menu item controls with links to edit new content after it's published. This is displayed inline for each control, and could be compiled into a centralized notifications area in the future in #35210.

[celloexpressions]

Complete flow creating items, saving them, and opening them in the editor to add content.

[celloexpressions]

34923.5.gif​ contains the last missing piece here (other than taxonomy support) - showing users links to edit newly-published content in the editor. This leverages the notifications API added in 4.6, and the notifications would also be shown compiled in the notifications area in #35210. I also added an updated gif above showing the complete flow.

Pending feedback and further review as requested previously, this should be ready for commit once 4.7 alpha is available. I'm removing ui-feedback since there isn't anything particularly dramatic in the proposed UI, but feedback is still welcome. Could use a +1 on the overall UX now that that's complete as well. One potential tweak - since the edit post links have to open in a new tab, we could indicate that visually with an icon, to complement the screen reader text that does the same.

[celloexpressions]

Also, a quick summary of the feedback on the make/core post: 9 commenters were generally in support of it (provided it works, has good flow, can be disabled when needed, etc.), and 4 (generally more vocal) were opposed. The primary complaint is whether this belongs in the customizer, but the purpose is to put this in menus, and being in the customizer has the added benefits of live preview and a robust JS API to build the feature with.

[afercia]

tested a bit the last patch and I'd like to thank you for implementing some accessibility features like audible messages. Noticed a few things that could be improved though.

1
When creating a new page, after pressing the "Add" button, focus is moved back to the input field. With some screen readers (e.g. NVDA) this prevents the message "Menu item added" to be announced because the announcement of the input field immediately interrupts the previous polite message. I'd recommend to don't move focus back to the input field.

2
Users can add more than one page and when saving the newly added pages get published all together. However, seems that the wp.a11y.speak() message gets just the last page. See in the screenshot below, where I've added and published the "Music" and "Movies" pages but just "Movies" is used for the aria live message. Haven't looked at the code though, it could be that there are multiple, consecutive, messages and just the last one gets announced.

Also, the message should not contain the last part "Edit it here etc...". Maybe, announcing the number of published pages would be more useful, something like "2 new pages published".

3
The published pages get a blue border to give a visual indication they're "new". It would be great to add also some hidden text or something in the markup in order to have something in the markup that can be read out by assistive technologies to announce those pages as "new":

4
When opening a new page menu item, there's a notification that uses the same blue border already used for the menu item. Maybe it's just me but I find this a bit confusing, maybe UI/design people could give some feedback here.

The link to edit the page should make sense even when read out of context. I'd strongly recommend to avoid "here" links. Worth considering in the admin these "edit" links are expanded with an aria-label attribute to add the page name. Maybe the whole notification text should be reviewed a bit to highlight the most important thing: the page was just published and it's an empty page.

[westonruter]

@celloexpressions what do you think about adapting the patch for including into the Customize Posts plugin itself? If the features of the patch were part of the plugin today and it was part of a release for a plugin on WordPress.org, that would help with user testing and feedback.

[helen]

Updating the ticket summary to better reflect the problem, which most commonly manifests when setting up a new site and wanting to put certain things in your menu that pages don't yet exist for, forcing you to leave the customizer (and possibly abandon changes) to create pages that you may not yet be ready to think about content for, and then go back to managing the nav menu.

Let's prioritize this for 4.7. The scope of the solution here is to be able to add page stubs (title, no content) when managing nav menus in the customizer, much like categories can be added while editing a post.

[celloexpressions]

Thanks for that @helen, I'd also like this to be a priority for 4.7 and am happy to help continue iterating as needed. I'll circle back this weekend (once I finish up a first pass at a very related project) but a couple quick notes.

Personally I'd really like to see the ability to create taxonomy terms here as well, as part of that site-structuring flow. However, due to the issues raised previously regarding the technical limitations of draft terms, we probably need to address it separately after the initial feature lands. If we get this wrapped up soon enough, that may still be able to happen for 4.7.

Regarding the suggestion from @westonruter above, I don't think it's going to be practical to merge this into the plugin before core, because it won't be very easy to pluginify the patch - in particular the UI requires restructuring the entire available menu items panel JS and CSS. I'm also hoping we can get a first pass committed in the next few weeks, quite early in the 4.7 cycle, since it's fairly mature now. We primarily need feedback on the code at this point, although it would also be great to get some user testing to back up the flow goals here.

@afercia thanks for the accessibility feedback! I will work on an updated patch when I circle back. However, issues 2, 3 (the border is for a notification, in this case also indicating that it's new), and 4 (first part, second part we should work on) are all caused by the notifications API introduced in 4.6 with #32893, and will also be problematic for other features using that API. I think we should address those points in a separate ticket, and make sure they're fixed for 4.7 since this will be the most prominent usage of notifications yet.

And quickly parsing that out - we need to look at the wording and link placement for the new page notification both for accessibility and for general feedback.

[westonruter]

PR: ​https://github.com/xwp/wordpress-develop/pull/152 Changes: ​https://github.com/xwp/wordpress-develop/compare/1722c4d...5bb985e

[westonruter]

In 34923.6.diff​:

• ​6a51eca Fix JSHint issues
• ​120ac63 Fix JSCS issues
• ​93eeb23 Fix PHPCS issues
• ​eeef76d Add sanitization for nav_menus_created_posts setting
• ​1eaa45b Ensure that nav_menus_created_posts is set with clone since arrays passed by reference
• ​c81e576 Eliminate edit post links in notifications per discussion
• ​ee187ad Move auto-draft post insertion into nav_menus component
• ​5bb985e Use flexbox to lay out new-content-item

Todo:

• Insert latest version of ajax_insert_auto_draft_post from Customize Posts: ​https://github.com/xwp/wp-customize-posts/blob/6c52c8a8dc3dca21dc6984b7a5ae274b8e079c89/php/class-wp-customize-posts.php#L1064-L1131
• Integrate latest version of insert_auto_draft_post from Customize Posts: ​https://github.com/xwp/wp-customize-posts/blob/6c52c8a8dc3dca21dc6984b7a5ae274b8e079c89/php/class-wp-customize-posts.php#L930-L968
• Add unit tests (tests can likely be copied from Customize Posts, which has coverage for these functions).

[celloexpressions]

34923.6.diff​ looks good to me. I'll note that the insertAutoDraft function here is intentionally different as it needs to take different parameters (if I remember correctly), but we could potentially sync the rest of the changes here.

[westonruter]

​https://github.com/xwp/wordpress-develop/compare/5bb985e...67b2452

[westonruter]

In 34923.7.diff​:

Changes: ​5bb985e...67b2452

• ​abcbcf3 Don't move focus to input after submitting
• ​d9358ce Remove customize-posts textdomain, phpdoc action tag, and remnant enqueue
• ​5763732 Fix jshint error by removing unused vars
• ​6eb48f3 Remove unused newPostPublished and editPostURL
• ​4285e89 Add CSS prefixes for flexbox
• ​5cb4331 Use type_label instead of label for consistency; fix tests
• ​6addc84 Use type instead as type_label if type_label is not defined
• ​613827f Forbid inserting auto-draft if user cannot publish
• ​7d1c73c Improve sanitization of nav_menus_created_posts setting
• ​d005b4c Ensure '+ Add' dashicon is styled same as elsewhere
• ​67b2452 Ensure invalid style is applied to input; re-focus on input when submitting invalid

Still need to add unit tests, however at least the existing unit tests are fixed.

@celloexpressions I'm still very much not feeling like the customize_nav_menus_disallow_new_content_types filter is necessary to add right now. Since we don't have taxonomies anyway, there is no need for the known use case of Post Formats. To me this filter seems not fully there yet and isn't needed right now. I'd rather we remove it and then bring it back when there is a clear need for it.

[mrahmadawais]

Flexbox Prefixes in line with initial flex prefixes.

[mrahmadawais]

DIFF Flexbox Prefixes in line with initial flex prefixes.

[mrahmadawais]

Enhancement: Minor CSS Changes to make the input element's padding equal to the Add New button

[mrahmadawais]

@westonruter I made a few minor CSS changes.

• For better flexbox support for flex-grow via prefixes in line with those used for flex.
• Minor CSS Changes to make the input element's padding equal to the Add New button

The input element was pretty weird looking.

Before

After

Basically, addition of 1.5px extra padding top and bottom for the input element did the trick.

[celloexpressions]

@mrahmadawais it looks like there's still a pixel or two difference in the height of the button and the input, although that's better.

@westonruter my only concern with not having a filter is that ideally there should be a way for developers to disable this feature, although the naming definitely needs work. We could take that out for the first pass and revisit when we circle back to add taxonomy support.

[westonruter]

@mrahmadawais going forward, please push your changes as commits to the existing pull request: ​https://github.com/xwp/wordpress-develop/pull/152

Coordinating via a PR makes it much easier to see the changes you're introducing and it allows us to all collaborate much more easily, and unit tests will be run automatically on the PR. You have write access

I believe I successfully applied your changes to the pull request: ​https://github.com/xwp/wordpress-develop/compare/67b2452...e17fd31

I don't think the changes you're making to kses.php are warranted here, and should instead be part of a separate ticket. They're not required for this ticket, are they?

[westonruter]

Changes: ​https://github.com/xwp/wordpress-develop/compare/e17fd31...d0f13ae

[westonruter]

In 34923.10.diff​:

Changes: ​c187eb8...d0f13ae

• ​e0c661c Add tests for hooks added in nav-menus constructor
• ​a3ea504 Remove customize_nav_menus_disallow_new_content_types filter until clear use case
• ​2a2ecf2 Revert changes to kses.php
• ​0079362 Normalize params for insertAutoDraftPost and return value; require post title
• ​4a9f079 Ensure user can edit_post specifically beyond just publish_posts
• ​d0f13ae Add non-ajax unit tests for new WP_Customize_Nav_Menus methods

Still needing to add Ajax tests and do a final pass on how some of the identifiers are named.

[mrahmadawais]

Replying to celloexpressions:

@mrahmadawais it looks like there's still a pixel or two difference in the height of the button and the input, although that's better.

Thanks for the feedback. Care to share a screenshot? Where the issue still exists? If you are referring to my screenshots, then it's the button UI which makes it look like that, any more padding would make things worse, I did try. Changing the UI of the button is not ideal since it is consistent everywhere. Will look into it.

Replying to westonruter:

@mrahmadawais going forward, please push your changes as commits to the existing pull request: ​https://github.com/xwp/wordpress-develop/pull/152

Coordinating via a PR makes it much easier to see the changes you're introducing and it allows us to all collaborate much more easily, and unit tests will be run automatically on the PR. You have write access

I agree my bad.

I believe I successfully applied your changes to the pull request: ​https://github.com/xwp/wordpress-develop/compare/67b2452...e17fd31
I don't think the changes you're making to kses.php are warranted here, and should instead be part of a separate ticket. They're not required for this ticket, are they?

My bad, kses.php edits were related to another ticket. Minor issue with my workflow had the clean start commented in the bash script I wrote to get started. Will be careful next time.

[westonruter]

Changes: ​https://github.com/xwp/wordpress-develop/compare/d0f13ae...32afe4c PR: ​https://github.com/xwp/wordpress-develop/pull/152

[westonruter]

OK, unit tests added. Ready for final review before commit.

In 34923.11.diff​, changes: ​d0f13ae...32afe4c:

• ​01477be Add missing false param to check_ajax_referer, improve post type exists checking
• ​e99ca25 Add ajax unit tests for ajax_insert_auto_draft_post
• ​32afe4c Simplify JS in submitNew

PR: ​https://github.com/xwp/wordpress-develop/pull/152

[westonruter]

In 38436:

Customize: Allow users to more seamlessly create page-based nav menus during customization.

Introduces the ability to create stubs for the various post types to add to a given menu. This eliminates the need to leave the customizer to first create the post in the admin and then return to managing menus. Only the title of the newly-created post can be supplied; the post content will be blank and will need to be provided in the normal edit post screen outside the customizer, unless a plugin enables a post editing in the customizer experience. When a post is created and added to a nav menu in the customizer, the newly created post that is added to a menu is given the auto-draft status, and if the changes are not published, the auto-draft post will be automatically deleted within 7 days via wp_delete_auto_drafts(). However, if the customizer changes are saved, then these nav menu item auto-draft post stubs will be transitioned to publish.

Includes portions of code from the Customize Posts <​https://github.com/xwp/wp-customize-posts> and Front-end Editor <​https://github.com/iseulde/wp-front-end-editor> plugins.

For more information, see ​https://make.wordpress.org/core/2016/06/16/feature-proposal-content-authorship-in-menus-with-live-preview/

Props celloexpressions, westonruter, valendesigns, afercia, melchoyce, mapk, iseulde, mrahmadawais.
Fixes #34923.

[westonruter]

In 38479:

Customize: Fix i18n by re-using the add_new_item post type label instead of using a post type name in a generic string.

Props afercia, westonruter.
See #34923.
Fixes #37895.

[westonruter]

In 38624:

Customize: Let static_front_page section be contextually active based on whether there are any published pages.

If there are no pages when the customizer is opened, the static_front_page section will be hidden. As soon as a page is created in the customizer session, the static_front_page section will be revealed. Previously the section would not be registered if there were no pages. Page stubs created via nav menus will appear in the dropdown-pages controls for page_for_posts and page_on_front, and such page stubs will thus cause the static_front_page section to appear. Plugins that facilitate page creation in the customizer by filtering get_pages will also cause the section to appear.

See #34923.
Fixes #38013.

[westonruter]

In 38906:

Customize: Allow page stubs to be created via dropdown-pages controls in the Static Front Page section.

This ability was previously added to nav menus via the available page items panel. The "Add New Page" button only appears when the allow_addition control param is supplied as true. Code is adapted from the Customize Posts feature plugin.

Props celloexpressions, westonruter.
See #38013, #34923.
Fixes #38164.

[westonruter]

In 39002:

Customize: Mark newly-added page/post stubs as added (with checkmark) when they are inserted into the list of available items.

Props ryankienstra, celloexpressions.
See #34923.
Fixes #38499.

[westonruter]

In 39038:

Customize: Prevent auto-draft post/page stubs from being saved with empty slugs or published with non-unique slugs.

• Allow WP_Customize_Nav_Menus::insert_auto_draft_post() to take full post array to pass to wp_insert_post(), except for post_status. Require post_title.
• Ensure empty post_name gets explicitly set to slugified post_title.
• Explicitly allow only post_type and post_title params in WP_Customize_Nav_Menus::ajax_insert_auto_draft_post().
• Use wp_update_post() instead of wp_publish_post() to ensure unique slugs are assigned to published auto-draft posts.
• Re-use WP_Customize_Nav_Menus::insert_auto_draft_post() when inserting stubs from starter content.

See #38114, #38013, #34923.
Fixes #38539.

[westonruter]

In 39502:

Customize: Prevent posts/pages imported via starter content from being dropped when adding post/page stubs via nav menus and the dropdown-pages control.

Props westonruter, dlh for testing.
See #38114, #34923.
Fixes #39071.

[westonruter]

In 41873:

Customize: Use keydown instead of keyup for listening for enter key to add page stub via dropdown-pages control.

Fixes issue with Japanese input.

Props miyauchi.
Amends [38906].
See #34923.
Fixes #42233.

[westonruter]

In 41887:

Customize: Allow post/page stubs to be edited in WP Admin as "customization drafts" when changeset is saved as draft or scheduled.

• Update stubs to have draft status when changeset is saved as draft, instead of preventing auto-draft garbage collection by giving them a far-future post_date.
• Show notice in publish metabox when editing a customization draft indicating that it will be published automatically with its changeset; a link to Customizer is included.
• Include a new "Customization Draft" display post state in the post list table.
• Disconnect stubs from their changesets when they are updated with a status other than "Draft".
• Trash customization drafts when their related changeset is trashed or deleted.
• Add a _customize_changeset_uuid postmeta to stubs to link them with their associated changeset.
• Include customize_changeset_uuid as context when requesting to insert a new auto-draft.

Props westonruter, melchoyce.
See #39896, #39752, #34923.
Fixes #42220.

[westonruter]

In 42148:

Customize: Ensure customization drafts are published instead of trashed when scheduled changeset goes live while non-admin user is authenticated (such as during WP Cron).

Props designsimply for testing, dlh for testing, melchoyce for testing.
See #28721, #34923, #42220.
Fixes #42489 for trunk.

[westonruter]

In 42149:

Customize: Ensure customization drafts are published instead of trashed when scheduled changeset goes live while non-admin user is authenticated (such as during WP Cron).

Props designsimply for testing, dlh for testing, melchoyce for testing.
See #28721, #34923, #42220.
Fixes #42489 for 4.9.