search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
9.99k stars 4.02k forks source link

Navigation Project Tracking Issue #38275

Open getdave opened 2 years ago

getdave commented 2 years ago

This issue captures ongoing work for Navigation project.

Here are some suggested guiding principles for work on this project.

The Navigation Overview Issue provides more detail about the current focus of work on this block for Phase 2.

This isn't a tracking Issue for a particular WordPress release. Rather it is somewhere to track the high level issues that need to be addressed for Navigation within the Editor as a whole.

This Issue is based on an assessment of user feedback and community defined goals for the wider Navigation system.

Bugs should be reported with the [Type] Bug label and added directly to the Navigation Project Board.

High Priority

The following Issues are considered essential to the next iteration of block-based navigation menus.

Managing and editing menus

Foundational work

Theming & Customisation

Normal Priority

The following issues are "nice to haves" but are unable to be considered for the next iteration of the block.

Backlog

The following are issues we are aware of which may be addressed in the future.

getdave commented 2 years ago

Update 1st Feb 2022

getdave commented 2 years ago

Update 9th Feb 2022

getdave commented 2 years ago

Update 16th Feb 2022

getdave commented 2 years ago

Update 23rd Feb 2022

getdave commented 2 years ago

Update 2nd March 2022

getdave commented 2 years ago

Update March 9th 2022

getdave commented 2 years ago

Update March 23rd 2022

gziolo commented 2 years ago

@getdave, is there any feature that you think could still land until Wednesday next week to be included in WordPress 6.0 release? To increase visibility, we can add it to the WordPress Editor 6.0 project board.

getdave commented 2 years ago

@gziolo realistically "feature" wise it's probably:

gziolo commented 2 years ago

Awesome, thank you. We track now both PRs. The one that is merged https://github.com/WordPress/gutenberg/pull/39290, is it behind the feature flag? Otherwise, it should be just included out of the box since it's ready.

getdave commented 2 years ago

The one that is merged #39290, is it behind the feature flag? Otherwise, it should be just included out of the box since it's ready.

Still being discussed. May be dropped from inclusion if deemed not ready. The PR was merged in order to get the basic code into the repo, but the feature isn't necessary "finished". If it doesn't make the cut then I'll disable it or place behind feature flag prior to Gutenberg code cut off date.

getdave commented 2 years ago

Update April 6th 2022

getdave commented 2 years ago

Update May 18th 2022

Two regressions were spotted on the block during testing for WP 6.0:

  1. https://github.com/WordPress/gutenberg/issues/41080
  2. https://github.com/WordPress/gutenberg/issues/40908

The former has been fixed thanks to great work from @draganescu 🙇

The other still needs attention but will not make it in time for WP 6.0.

getdave commented 2 years ago

Update 15th June 2022

https://github.com/WordPress/gutenberg/issues/40908 still needs to be fixed.

Aside from this, contributors are largely focused on Issues which are complementary to the block such as https://github.com/WordPress/gutenberg/issues/38277.

We are actively seeking more contributors to help progress the block.

The complementary Navigation Block Overview Issue also has a list of tasks grouped by focus area.

getdave commented 2 years ago

Update 29th June 2022

Contributors are aligning around next steps to make preserving Navigation Menus on Theme switch a reality. This is a highly nuanced topic with a lot of moving parts so a few contributors have outlined how they think this should work. We'd be grateful for more opinions however.

Various bug fixes have also been committed including a fix for a permissions issue in https://github.com/WordPress/gutenberg/pull/41862.

getdave commented 1 year ago

Update 21st July 2022

It's been a while since the last update, principally due to AFK.

getdave commented 1 year ago

Update 27th July

jameskoster commented 1 year ago

Possibly worth considering as a part of the work here: https://github.com/WordPress/gutenberg/issues/40884

getdave commented 1 year ago

Update 7th Sept 2022

In other news the work to allow Navigation Menus to be referenced by slug is nearly ready to merge. However, after much discussion it is unlikely contributors will look to merge this in time for WP 6.1 (see link for context).

Contributors will soon switch focus to bug fixes and code quality.

getdave commented 1 year ago

Update 27th Sept 2022

Some key features have landed in time for WP 6.1. If you want to learn more about them then you can checkout @draganescu's Dev Note on the changes to the block's fallback mechanics.

Or if you prefer I have made a quick video covering all the changes to the Navigation block in WordPress 6.1.

Contributors are now focused on bug fixes for 6.1.

jasmussen commented 1 year ago

I unchecked the box for introducing the list view in the inspector, as the issue was mistakenly closed. The issue has been updated and is ready for a dev: https://github.com/WordPress/gutenberg/issues/42257

getdave commented 1 year ago

Update 14th Oct 2022

mrfoxtalbot commented 1 year ago

Could we please add https://github.com/WordPress/gutenberg/issues/37712 to the backlog? Thank you!

getdave commented 1 year ago

Could we please add #37712 to the backlog? Thank you!

Excellent. I've been searching for that Issue and now you've found it for me! Much appreciated. Proposed added to Normal pending feedback from the community on our priorities for WP 6.2.

Marc-pi commented 1 year ago

@getdave In term of writing flow / site building process optimization, i would say the most frequent needs are (for a daily usage), so we don't have to use custom css (actually, the customizer is hidden, we are not supposed to add custom css code ;-))

That's so far what i've noticed for a daily usage. Maybe it can help you to adjust top priorities for 6.2...

getdave commented 1 year ago

@Marc-pi Thank you for your feedback. It's much appreciated.

What we're finding that the moment from user testing in the FSE outreach programme is that users of the block are suffering from UX issues around creating and editing menus. This is clearly a major problem as unless we resolve these issues everything else we do will have a (relatively) minimal impact. After all, if you can't successfully create/edit a menu then you are unlikely to care about any other aspects of the block.

This is why we're proposing focusing the next 6.2 cycle on improving the block from an end user perspective as opposed to problems which effect developers / creators.

Whilst we recognise all the items you suggest are important and we certainly share your frustration, WordPress remains end user-focused and thus we are suggesting we address the editing/creating problems as a primary priority.

That's not to say that the the items above are off the table - far from it. PRs are always welcome and contributors will be more than happy to undertake reviews.

If you are open to diving in, one easy way to help would be to create Issues for any of the items you've listed which don't already have an Issue 🙏

Thank you again for taking the time to feedback 🙇

getdave commented 1 year ago

Update 17th Nov 2022

The priorities for WordPress 6.2 (and Gutenberg "Phase 2") are being managed over at https://github.com/WordPress/gutenberg/issues/41549. Further updates for 6.2 will be posted there.

This Issue will remain canonical for the overall project tracking.

As mentioned the priorities for contributors is working on improving the ability to edit/manage menus. There is an Gutenberg experiment underway to add a List View to the Navigation block sidebar to enable this. To test this out enable the Offcanvas Editor experiment from the Gutenberg -> Experiments menu in WP Admin.

There will be an official call for testing once the experiment is deemed sufficiently advanced. This will allow contributors to gather feedback and adjust accordingly before deciding whether to merge the experiment into Gutenberg Core (i.e. remove the feature flag).

Technical Implementation

During the experiment we have branched out with a copy/paste version of the <ListView> component. We will now look to remove this component and "backport" all necessary features to the main list view.

The list of features is actually relatively small and shouldn't cause undue bloat to the List View's API surface area, but each feature will be raised as an individual PR to ensure there is time for code review and a11y audit.

getdave commented 1 year ago

Update

I have tidied up this list remove all closed items and reorganising as appropriate. Reminder that the overview Issue for Nav block in Phase 2 will list the next priorities for 6.3 cycle.

getdave commented 1 year ago

Fixing the flows

Contributors have been discussing fixing the key flows on the Navigation block. We've created the following issues:

Update: I moved these to https://github.com/WordPress/gutenberg/issues/50165#issue-1688330463.

getdave commented 1 year ago

I've created a new Overview Issue to track what contributors are focusing on for 6.3. This is currently a WIP but we will try to firm it up in the next few weeks.

getdave commented 1 year ago

Updates for this project in the 6.3 cycle will continue to be posted on https://github.com/WordPress/gutenberg/issues/50165.

getdave commented 1 year ago

Just collating some things I'm thinking about as potential low hanging fruit for the Navigation block in the 6.4 cycle. Larger tasks will be collated separately:

getdave commented 10 months ago

Update 7th September 2023

WP 6.4 is heavily focused on consolidating existing features and tightening up the interface. As a result there has not been any significant progress specifically on the Navigation system.

Contributors have continue to engage with ongoing work to improve the Link creation interface as that has a major impact on the ability to manage Navigation.

Contributors will try to address the following issues but there may be insufficient time due to the short release window in the 6.4 cycle:

getdave commented 9 months ago

Update 27th September

WP 6.4 is heavily focused on consolidating existing features and tightening up the interface. As a result, there have not been any further PRs merged which focus on the Navigation system.

However, contributors have made some progress in a PR on adding "current item" control to theme.json. As with many things related to Navigation this looks like it will require significant modifications to the existing Theme JSON system and so it's much more complex than contributors expected.

Bug fixes will continue to be actioned during the 6.4 release period.

fabiankaegy commented 8 months ago

Hey 👋

I'm not sure this is the right spot for this feedback, but I wasn't sure where else to share this :)

Since navigation areas were deprecated a while ago in the navigation block this essentially means that there can never be a block-based theme where the header template part is not modified by the user. This means that features such as the new Block Hooks will never be able to trigger for headers. Also, any code-based updates to headers in the theme are never applied because instead the customized version from the Database will be used.

For a lot of Agency work where a site is continually developed on it's a great thing to be able to have scheduled code deployments that update global elements such as headers through the template parts system. But since we can no longer specify a navigation area in the navigation block but need to specify an environment-specific ID value in the ref of the navigation menu this is no longer possible.

Additionally, there were many cases in the past where the Navigation block was not just used for Global navigations, but also local in page navigations that should never be synced were possible. This no longer really is the case. Yes you can create a unique synced menu location for every instance of the navigation block you insert. But the flow for that is not ideal.

If we need all navigation menus to be synced, I think we should refine the insertion UX of the block to be more like the image, columns, group, or query block and render a placeholder first where a user can select an existing navigation menu or create a new one right then and there. That would make it much clearer for users whats actually happening :)

CleanShot 2023-10-12 at 20 04 51@2x

getdave commented 8 months ago

Thanks for taking the time to feedback here Fabian. Much appreciated.

I think the best thing is to make dedicated Issues for both (one already has an Issue).

The former one about "areas" is quite complex and I'll need more time to wrap my head around the concept.

The later is a known concern but one that hasn't been raised as a concern for a while until you mentioned it here. I'll post a comment there.

draganescu commented 8 months ago

Excellent feedback @fabiankaegy thank you.

jasmussen commented 8 months ago

Good feedback.

I think we should refine the insertion UX of the block to be more like the image, columns, group, or query block and render a placeholder first where a user can select an existing navigation menu or create a new one right then and there. That would make it much clearer for users whats actually happening :)

I would avoid this placeholder, it would break the layout of a template that included an empty navigation block.

In fact for this reason more and more blocks are moving away from the traditional "placeholder" concept, and towards something that is much more in line with content. The Site Logo block is an example of where I could see future placeholders go. This affords better patterns and layouts. I see this interface as a more likely one to improve in terms of elevating visiblity:

Site editor → Navigation section

alexstine commented 8 months ago

@jasmussen Honestly, this sounds like a pretty terrible idea for accessibility. We already have a huge problem with communicating to non-sighted users how to use a block, removing initial placeholder content will further worsen this problem. BTW, why would anyone insert an empty navigation block?

fabiankaegy commented 8 months ago

I tend to agree here. I think the pattern established by the Image block is a nice one. When the block doesn't have an ID associated and is not selected it renders a visual placeholder that looks like the actual content it will produce. This takes care of making it look correct in Patterns etc. Then when the block is selected and doesn't have an ID we show the placeholder with the appropriate controls to give a user guidance on how to get started. In this case allowing them to choose an existing navigation menu or allowing them to create a new one.

When we don't do this and a user drops in the navigation block anywhere it is almost impossible to understand which menu navigation you have selected and how to switch to a different one / create a new one. The synced nature of the block is not clear and users therefore make more mistakes destroying navigation menus they weren't aware are used elsewhere.

@jasmussen I would love to better understand the struggles you find with this pattern of a visual placeholder like the image block has when the block is not selected but isn't setup with the propper data yet? :)

draganescu commented 8 months ago

@alexstine I think we have had some crossed wires: it is the other way around, we're trying to never have empty blocks. We do not want to remove initial placeholder content, some of us argue that it should not be a setup form but something which resembles content.

Just to answer the other question an empty navigation block is:

In these states we aim via fallback to never show an empty, invisible block. So again, it's a misunderstanding in this context.

draganescu commented 8 months ago

@fabiankaegy I don't think the "setup in canvas" idea is something we want to be back to. I think across the board, in time, these indetermined states via "setup in canvas" UIs will be phased out.

You're right to point at the image block as a good path. It, or the site logo block, implement "placeholder content". However, what the image block does is possible because an image block "fills up" some space according to a layout. The navigation block is in an undetermined layout state, when it's empty. It's hard to determine how that should look.

As Joen notes slapping a form in the space of a block creates these problems:

In the case of navigation We have quite a handful of rules to try our best and avoid an empty navigation in a fresh theme or fresh setup: we fall back to a list of pages, we fall back to most recently edited classic menu, we fall back to most recently edited block menu. All this is to have a sort of placeholding behavior for the navigation block. Showing a form with random width and height is probably not great.

On the other hand I love the feedback on:

In other words instead of this:

image

we should all aim at:

alexstine commented 8 months ago

Take the site logo block for example. How is it supposed to know which image to use? It's out of scope for this issue but I want to make sure we're not replacing valuable placeholders on blocks that need it.

jasmussen commented 8 months ago

Andrei explained it better than I managed to, apologies for the diversion. We're not moving away from traditional placeholders; there should always be some sort of state for empty blocks.

getdave commented 8 months ago

Nice discussion and it's good to ensure everyone is aligned on the goals and aims for this block and other Core blocks.

I hope you won't mind if I suggest that perhaps if further discussion is required about block "setup" state, then we consider moving to a dedicated Issue?

It's just this Issue is a Tracking Issue and is primary used for folks who want to check in on the latest state of progress on the Navigation project. Therefore I think we should try to avoid creating long threads on specific features.

I appreciate your understanding 🙇

draganescu commented 8 months ago

Once there are issues for the above we can hide the replies here.

getdave commented 7 months ago

Update 6th Dec 2023

Contributors are primarily focused on two long standing feature requests:

These are complex endeavours with a lot of backwards compatibility concerns so feedback is encouraged on the linked PRs.

getdave commented 5 months ago

Update 11th Jan 2023

Since returning from the holiday season, contributors undertook a research spike on enabling the ability to custom the Navigation Overlay via Template Parts.

The spike produced a working prototype but also uncovered a lot of complexity. As a result the proposal is now that this is not targeted for WP 6.5 but rather a later release. Opinions are welcomed.

Contributors are also hard at work on an opt-in "auto-wrapping" feature which aims to detect when the Navigation block needs to wrap and handles that automatically (rather than relying on a fix breakpoint). Feedback and contributions welcomed.

kauaicreative commented 5 months ago

Core Navigation Submenu Block - "Links are not crawlable" SEO lighthouse warning

Top level menu items (Core Navigation, Submenu Block) insert empty tags when a link is not entered. The Submenu Block can be used to open the submenu on mouseover (without clickinging) and there is no intention of using it as a link. Google page speed score warns - "Links are not crawlable". It would seem that the a tag should not be inserted in this case. Or inserted with some code that would allow it to pass google page speed score.

Is this the best place to report this issue? You can find the original report here: https://core.trac.wordpress.org/ticket/60351#comment:2

image

getdave commented 5 months ago

Hi @kauaicreative. Thank you for reporting this. Very much appreciated.

The best place to log the bug is at https://github.com/WordPress/gutenberg/issues/new/choose. Please drop the link here once you have raised an Issue.

Thank you for contributing to WordPress 👍