Navigation Overlay customisation via Template Parts #55657
Conversation
getdave
requested review from
MaggieCabrera,
ajlende,
jeryj,
richtabor and
scruffian
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
Warning: Type of PR label error To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. |
|
Size Change: +2.22 kB (+0.1%) Total Size: 2.13 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in d8b1479. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7226914157
|
packages/block-library/src/navigation/edit/edit-overlay-button.js
Outdated
Show resolved
Hide resolved
TodoDumping a load of todos that are top of mind:
|
|
Here is how we can fetch the overlay in the PHP code $theme = 'emptytheme';
$custom_overlay_id = $theme . '//' . 'navigation-overlay-' . $attributes['ref'];
$custom_overlay_query = new WP_Query(
array(
'post_type' => 'wp_template_part',
'post_status' => 'publish',
'post_name__in' => array( 'navigation-overlay-' . $attributes['ref'] ),
'tax_query' => array(
array(
'taxonomy' => 'wp_theme',
'field' => 'name',
'terms' => $theme,
),
),
'posts_per_page' => 1,
'no_found_rows' => true,
'lazy_load_term_meta' => false, // Do not lazy load term meta, as template parts only have one term.
)
);
$custom_overlay_post = $custom_overlay_query->have_posts() ? $custom_overlay_query->next_post() : null;Then we can render it dynamically via |
|
Next step - break apart the rendering of the Nav block inner blocks so that we have x2 "modes":
Alternatively we might be able to configure the Responsive Wrapper to render different content depending on whether there is a custom overlay. But that might be causing it to know too much. |
Doesn't filtering the block edit component allow us to do this?
Did the idea of an overlay block fall off the map? Would this group be targetable from theme json by themes?
If the navigation block refs the same navigation cpt what is there to sync?
why do we want this? |
Yep probably. But we only want to filter if the block is within a specific Template Part. What data is there to access that provides this info? Some discovery needs to be done. For example, we might need to add post meta to the Template Part to denote it as a "overlay" so that we can filter the Nav block accordingly 🤷
Yes we decided we didn't need that. Indeed, we should avoid additional blocks if we can. However, if the problem above proves insurmountable we may need to revert to this approach.
The question raised by others was, what happens if the menu in the parent Nav block is changed? Currently in this PR a totally new overlay will be created based on the template part provided by the Theme. However, that may not be desireable.
Because that's the objective of the entire exercise 😅 The idea as I understand it, is that you could have totally custom content in the overlay. Therefore the rendering of the overlay needs to know how to render
This is in contrast to the current system which renders the exact same markup on all viewports. Literally it uses the same components - it's just displayed differently using JS and CSS. |
Because the content from desktop will not be the same as on the overlay once the user changes it |
|
Quick summary of how the classes at play for the block works today. We are using the same HTML for mobile and desktop, and we alter its appearance with CSS. This will need to change for our purposes here. For my own better understanding and anyone else's:
|
|
Although there is no necessity to maintain backwards compatibility, we want to try to preserve the markup of the block as much as possible to avoid breaking sites that rely on custom CSS for the navigation block. The markup when an overlay is present but has not been customized by the user will stay the same: And the proposed markup for when the user creates a custom overlay would be: The new customized overlay nav items will stay hidden until the menu is toggled. There are two questions this raises:
The navigation items would only be duplicated only when the user has created a custom overlay for mobile. /cc @WordPress/block-themers EDIT: A codepen with this mocked up: https://codepen.io/Marga-Cabrera/pen/GRzmxVR |
MaggieCabrera
added
the
Needs Accessibility Feedback
getdave
force-pushed
the
add/nav-overlay-as-template-part
branch
from
84cb759 to
918487f
Compare
This comment was marked as resolved.
This comment was marked as resolved.
|
This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress. If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged. If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack. Thank you! ❤️ View changed files❔ lib/experimental/navigation-overlay.php ❔ lib/blocks.php ❔ lib/experimental/blocks.php |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
packages/block-library/src/navigation/edit/edit-overlay-button.js
Outdated
Show resolved
Hide resolved
| const onClick = () => { | ||
| if ( isSelected ) { | ||
| // Exit navigation overlay edit mode. | ||
| history.back(); |
There was a problem hiding this comment.
There are more routes available, so this doesn't work. Example repro:
- From the Site Editor
- Go to the Overlay Template Editor
- Click the Site Logo/W in the top Left to open up the left Sidebar
- Click the Editor Canvas
- Click the Overlay X
- The Editor Sidebar will open, and you can't exit the overlay edit directly back to the edtior
There was a problem hiding this comment.
Also, we should still have the Back button navigation in the central header area as on other templates.
There was a problem hiding this comment.
Also, we should still have the Back button navigation in the central header area as on other templates.
That's turned into a wider problem. I agree we need it but it will need to be a seperate PR.
UpdateI have posted (on the Issue) a set of what I believe to be the high level user requirements for this feature. |
There was a problem hiding this comment.
We should comment this to explain what is happening here. Basically it's show/hiding the different content depending on whether it's being shown within the overlay.
getdave
force-pushed
the
add/nav-overlay-as-template-part
branch
from
6fdda8b to
139d7cb
Compare
packages/block-library/package.json
Outdated
| "@wordpress/private-apis": "file:../private-apis", | ||
| "@wordpress/reusable-blocks": "file:../reusable-blocks", | ||
| "@wordpress/rich-text": "file:../rich-text", | ||
| "@wordpress/router": "file:../router", |
There was a problem hiding this comment.
Router shouldn't be a dependency of the block library package as not every editor has one.
@glendaviesnz added a way to handle navigation in #57036 via an editor setting that will work across the post and site editors.
There was a problem hiding this comment.
Thanks for the pointer Dan 👍
There was a problem hiding this comment.
There may be some modifications coming to that approach now as we need to extend it a little probably in order to get rid of the template-only mode, will hopefully get that sorted today.
There was a problem hiding this comment.
the template-only mode
What is this mode you speak of?
There was a problem hiding this comment.
What is this mode you speak of?
It was added temporarily as part of the editor unification work, but we are now in the process of pulling it out again. Context being we wanted a way to edit a synced pattern in isolation in the post editor, so we looked at adding a pattern-only mode, but it was then decided that this was not very scalable as we didn't want modes for lots of different entities.
It was decided that a better approach would be to change the entity that was passed into the editor provider, and we added a getPostLinkProps editor setting which is a callback that returns an onClick event and href that changes the current entity in the editor.
We initially just used this for editing synced patterns in the post editor but I am now looking at doing the same for editing templates from the post editor, which currently uses the template-only mode. When working through this it seems our initial implementation doesn't extend quite so well for the wider use case, so I have a suggested refactoring of this here.
|
I posted an update regarding this PR on the Issue. |
|
For anyone coming here late the latest status is available. |
|
I'm rebasing this PR |
getdave
force-pushed
the
add/nav-overlay-as-template-part
branch
from
d8b1479 to
a4ccff6
Compare
| postId: overlayId, | ||
| postType: 'wp_template_part', | ||
| canvas: 'edit', | ||
| myNavRef: navRef, |
There was a problem hiding this comment.
| myNavRef: navRef, | |
| myNavRef: navRef, |
Let's rename this 🙏
|
I've rebased this and starting to take a look at it again after a long break. Here's what I'm thinking may help us to unblock this work a bit. Essentially we need to decouple when and how the Nav block receives a
We could continue with the ability of the Navigation block can function without a ref being set as an attribute ( a "temporary ref"), but still behave as though a ref is set. A block should be able to retrieve its "temporary ref" from various contexts including:
In addition, Navigation Overlay as an template part area feels a little over the top. It's extremely specific semantically - it's basically an area that exists for a single block only. That feels wrong. However, we can't easily have an "Overlay" area as that's too broad. Therefore we should look to find a different mechanism for identifying template parts that are "Navigation Overlays" (e.g. following a slug pattern, tags, post meta...etc). Todo
|
|
A template part / pattern still makes sense to me for this purpose. Perhaps we can model it after #61577 since it should be easy to unregister, replace, etc. |
|
I'd like to advance this for a forthcoming WordPress release. I'm revisiting the current state and will try and summarize the work that is required and any outstanding blockers. |
|
I just tested this PR for the first time and the overlay is not displayed on the front end, sadly. 😢 |
Thank you for testing and the feedback. That functionality will definitely need ot be in place prior to merging 👍 |
|
|
||
| // The new overlay should use the current Theme's slug. | ||
| const newOverlay = await createOverlay( overlayBlocks ); | ||
|
|
There was a problem hiding this comment.
The overlay should be assigned to the block attributes here. Then the attribute can be used for backwards compatibility in index.php (if it has the attribute, do the new thing, else do the old thing)
| const history = useHistory(); | ||
|
|
||
| function goToOverlayEditor( overlayId, navRef ) { | ||
| history.push( { |
There was a problem hiding this comment.
This API has be removed it seems. I cannot seem to get history.navigate to work 😕
getdave
force-pushed
the
add/nav-overlay-as-template-part
branch
from
9049cb0 to
76f22d4
Compare
getdave
force-pushed
the
add/nav-overlay-as-template-part
branch
from
76f22d4 to
dc567e3
Compare
| ); | ||
| } | ||
|
|
||
| export default EditorCanvas; |
There was a problem hiding this comment.
@scruffian I think this is now legacy. We don't want to reinstate it.
| postId: overlayId, | ||
| postType: 'wp_template_part', | ||
| canvas: 'edit', | ||
| myNavRef: navRef, |
There was a problem hiding this comment.
@scruffian We were passing the ref around trying to be clever. We need to consider if we still want to go down this route.
|
This was a useful exploration but is now quite dated. I also feel some of the concepts may be too complex. I'm going to close this out. Nothing here is lost or wasted - we can draw on it in the future. Let's continue to explore this effort with a fresh pass in #73084. |
🔧 List of outstanding tasks is here.
Closes #43852 and #39142
What?
Provides the ability to fully customise the overlay that is shown when the Navigation block is rendered on a smaller viewport (e.g. "mobile" phone).
Closes #39142 and #38201 and #43852
Alternative to this branch.
Co-authored-by: Ben Dwyer [email protected]
Co-authored-by: Rich Tabor [email protected]
Co-authored-by: Maggie [email protected]
Co-authored-by: Alex Lende [email protected]
Co-authored-by: Jerry Jones [email protected]
Co-authored-by: Andrei Draganescu [email protected]
Why?
Currently users only have minimal control over the contents and apperance of the overlay menu that is shown when clicking on the "hamburger" icon button which is shown when the Navigation block is rendered on smaller viewports.
This is very restricting and also very difficult to provide adequate control over because the exact same block (e.g. markup) is used on "desktop" layout and "mobile" layout.
Users have repeatedly requested the ability to
This PR seeks to address this requirement as an opt in experience, whilst also maintaining full backwards compatibility with the existing experience (😅).
How?
The premise of this PR is that the overlay should be a template part. This allows us to render the overlay's blocks within a dedicated editor (e.g. the same editor you use to edit your "Header" template part) and therefore provide full customisation of its contents.
At a high level it should work like this:
By default a new "Overlay" template part is created for each Navigation Menu (not block) only when the user chooses to customise the overlay.
The overlay template part will be created from a template part named
navigation-overlay.htmlmeaning the Themes can provide a default Overlay.Similarly, if the user creates their own "Navigation Overlay" template part within the editor then this will be used.
If a Theme does not provide an Overlay, then a default "Core" template will be used instead.
User Requirements
Please see the list of user stories on the Issue description.
Tasks
Editor(not required as we go to the template part editor instead 🎉 ).Xbutton can become a simple block which only has minimal options.Submenu & overlay text/backgroundoptions) on the Nav block (in parent and the block in the overlay). We should however, leave in theSubmenupart of the control as we still need to be able to Style submenus.Set the template part resizable canvas into a mobile viewport by default when this template part gets loaded.We decided against optimising for this for now.Ready for Dev
Displaypanel within inspector controls entirely for the navigation within the overlay.navigation-overlaytemplate file a.phpfile and implement translation of all strings.Defaultsetting for the Overlay's vertical padding which automatically takes into account the following variables that are outside of the "editor":Testing Instructions
Overlay Menu.Alwaysas this makes testing easier.OVERLAY MENU.Testing Instructions for Keyboard
Screenshots or screencast