Navigation: Display the templates in which a navigation is used

[scruffian]

What problem does this address?

It would be useful to know which templates a navigation block is used in, so I can know whether its safe to delete it.

What is your proposed solution?

When in Navigation Focus Mode, we could display the template it is used in, in the sidebar:

This is similar to #20476

[annezazu]

This has come up in the FSE Outreach Program in various ways and would be a huge help when it comes to the general navigation experience!

[getdave]

@scruffian @draganescu Any ideas for technical implementation of this feature?

I'm thinking probably the only way is to set post meta on the Nav Post via REST which indicates which templates it's used within.

On a practical level:

• user inserts Nav block into template
• Navigation Menu X is set as a ref.
• REST request sent to update wp_navigation post meta with the slug of the Template.
• if Nav Menu is changed then the same request is sent to update (remove and add).

Questions:

• What did I miss?
• What edge cases are there?
• What other solutions should/could we consider?

[scruffian]

That's not going to work for templates that are manually edited. Could we consider getting all templates and parsing them for navigation blocks? The performance would be the main issue.

Do we also care about which posts the navigation is used in? I'm thinking we do.

[draganescu]

Outside of a solution that is a mapping stored and managed it's all reverting to scrubbing posts for block markup which is a no go. I think Dave's take with post meta is a good way or maybe even leveraging the options table and storing the mapping there for all navigation block <-> post relationships.

[scruffian]

all reverting to scrubbing posts for block markup which is a no go

why?

[draganescu]

all reverting to scrubbing posts for block markup which is a no go

why?

Because it is extremely slow. Every edit of templates will have to check what happened to the navigation block, evey open navigation block will call a query that is looking for LIKE stuff. It's just a bad design, for tens of thousands of items in the posts table ...

Plus there is no upside compared to storing a map in options. It's more complicated to do right :)

[scruffian]

We would only need to make the query when the user is asking where their navigation is used, not every time an edit was made.

[draganescu]

Of crouse, but it's still weird query to make. As I said, there is no upside to storing a map in options which is simple to implement and fast to access.

[SaxonF]

I'm not sure if this affects the implementation but its important to highlight that we want to surface connections across other blocks too. For example:

• Where synced patterns are currently being used
• Where template parts are being used
• Which posts/pages a template is applied to

If we could build an approach that works for all that would obviously be ideal

[getdave]

Thanks Saxon. So this is definitely an editor wide concern that needs addressing at a fundamental level.

[SaxonF]

I'm assuming this now goes beyond what's possible for 6.4 so moving it out. Feel free to move it back in if you think its still possible.

[talldan]

Late to this discussion, but it's also something I've thought about for patterns.

I think the option @getdave outlines is interesting but falls down when a user deletes a post containing a navigation block—you need some way to update the navigation menu's meta, or else you have stale data.

To solve that it could instead handled server side on any kind of CRUD update to a post type that contains blocks. So not when you interact with navigation/pattern/template part block itself, but instead on the posts that contain them.

So for example, if the user changes a template/page/post/anything, as part of the saving process the content is parsed and blocks like navigation, template part, pattern are discovered (I think use a block supports config like indexable to indicate what blocks can be indexed). The refs are discovered and indexed in a mapping (perhaps as @draganescu describes in the options table).

It falls down if a user updates post content another way, like an SQL query, but there could also be a cron job or something that keeps the index up to date daily, or a way to trigger the re-indexing for all posts.

The other option could be scraping all posts as mentioned, but that does sound expensive to do on a regular basis, particularly for patterns in posts.

[draganescu]

@talldan yes in #55782 and all the discussions and attempts there its clear that scraping posts is likely a dead end. It's why I did not push that one forward even with all the limits discussed and optimisations offered by @dmsnell

I think going the way of an index is way more profitable long term.