Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow setting a defaultBlock attribute on the navigation block #51026

Closed
wants to merge 505 commits into from

Conversation

sethrubenstein
Copy link
Contributor

What?

This adds a new defaultBlock attribute to allow site owners to customize the core/navigation block experience for end users.

Why?

This solves for #50982

How?

This adds a new defaultBlock attribute and a check for it along with a quick sanity check if it fails it falls back to the DEFAULT_BLOCK constant.

Testing Instructions

  1. Open a post or page
  2. Copy and paste this block markup into the editor:
<!-- wp:navigation {"defaultBlock":{"name":"core/navigation-link","attributes":{"type":"category","kind":"taxonomy"}}} /-->
  1. Click + inside the navigation block.
  2. Now category links should be the default when clicking + inside this navigation block.

Testing Instructions for Keyboard

n/a

@github-actions github-actions bot added the First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository label May 27, 2023
@github-actions
Copy link

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @sethrubenstein! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

@skorasaurus skorasaurus added the [Block] Navigation Affects the Navigation Block label Jun 1, 2023
@mtias mtias added the [Feature] Extensibility The ability to extend blocks or the editing experience label Jun 2, 2023
@paaljoachim
Copy link
Contributor

paaljoachim commented Jun 16, 2023

Thank you very much for contributing @sethrubenstein Seth! It is much appreciated!

I will go ahead and ping @getdave and @MaggieCabrera so they know about this PR and can check it out.

@sethrubenstein
Copy link
Contributor Author

@paaljoachim Thanks! I look forward to any feedback!

@ndiego ndiego added the [Type] Enhancement A suggestion for improvement. label Jun 16, 2023
Copy link
Contributor

@talldan talldan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your contribution @sethrubenstein.

I left a couple of comments. The biggest issue seems to be that __experimentalDefaultBlock isn't a stable API, so I don't think we can comfortably expose it via the nav block's attributes.

I think there's some work to do to stabilize __experimentalDefaultBlock first.

// If the `defaultBlock` attribute is set and itself has an attributes object with values then use it
// otherwise fallback to the DEFAULT_BLOCK constant.
// This allows site owners to set the default `core/navigation-link` variation to use.
const navDefaultBlock = defaultBlock && defaultBlock.attributes && Object.keys(defaultBlock.attributes).length > 0 ? defaultBlock : DEFAULT_BLOCK;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about the part that checks the length of the attributes. Wouldn't that disallow setting a new default that doesn't have any specific default attributes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@talldan Thats correct, my intention here was to assume if a developer/user hasn't included some attributes that actually changes something about the default core/navigation-link block to be inserted that we'd default to DEFAULT_BLOCK. But I can also see how that might confuse people at first. Ideally I think we'd get rid of DEFAULT_BLOCK altogether and rely on the block.json defaultBlock value... but I didn't want to assume I could unilaterally make that call.

So I'm completely open to however you all want this to work this was just my very opinionated approach to respecting the default behavior already present.

@@ -98,7 +104,7 @@ export default function NavigationInnerBlocks( {
onChange,
allowedBlocks: ALLOWED_BLOCKS,
prioritizedInserterBlocks: PRIORITIZED_INSERTER_BLOCKS,
__experimentalDefaultBlock: DEFAULT_BLOCK,
__experimentalDefaultBlock: navDefaultBlock,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given this was introduced as an experimental API, I'm not sure about exposing it as a stable attribute of a block.

It might be worth stabilizing the __experimentalDefaultBlock API first so that this becomes defaultBlock: navDefaultBlock and deprecating the __experimentalDefaultBlock property.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved by #52083

@@ -98,7 +104,7 @@ export default function NavigationInnerBlocks( {
onChange,
allowedBlocks: ALLOWED_BLOCKS,
prioritizedInserterBlocks: PRIORITIZED_INSERTER_BLOCKS,
__experimentalDefaultBlock: DEFAULT_BLOCK,
__experimentalDefaultBlock: navDefaultBlock,
__experimentalDirectInsert: shouldDirectInsert,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In terms of stabilizing __experimentalDefaultBlock, I think it could be worth looking at stabilizing __experimentalDirectInsert too, as I believe the two props were designed to work together.

Perhaps if there's consensus that defaultBlock should be added as a block attribute, the same should also apply to directInsert. 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved by #52083

@getdave
Copy link
Contributor

getdave commented Jun 19, 2023

Thanks for your contribution @sethrubenstein.

I left a couple of comments. The biggest issue seems to be that __experimentalDefaultBlock isn't a stable API, so I don't think we can comfortably expose it via the nav block's attributes.

I think there's some work to do to stabilize __experimentalDefaultBlock first.

@talldan I think we're at a point where those two "__experimental" properties have been used extensively for several releases. Based on that do you agree we can stablise them for 6.3?

If so next steps would be:

  • PR to stablise the two APIs
  • Rebase this PR

@talldan
Copy link
Contributor

talldan commented Jun 19, 2023

Looks ok to stabilize to me 👍

Not sure if there's anyone else you want to run it past. I think @tellthemachines originally implemented it, but hasn't worked on these blocks for a while.

@getdave
Copy link
Contributor

getdave commented Jun 20, 2023

I'll just say now that - as much as I'd like to - I will not have capacity to work on this in time for WordPress 6.3. Happy to work on it afterwards though.

@sethrubenstein
Copy link
Contributor Author

@getdave I'm not sure if you want to give first time contributors such a large ticket but I'd be happy to offer up some of our teams time to stabilize __experimentalDefaultBlock and __experimentalDirectInsert if that would be of help or desirable? Complete transparency, not sure what that work would entail beyond getting rid of the __experimental wording across Gutenberg for these two, setting the default values in block.json where in use (looks like buttons and navigation right now), and of course testing; but we have the labor and are available.

@getdave
Copy link
Contributor

getdave commented Jun 21, 2023

@sethrubenstein That would be fantastic. Thank you.

I would recommend separate PRs for:

  • __experimentalDefaultBlock
  • __experimentalDirectInsert

My understanding is that we would remove the prefix, but also retain the original in its entirity for backwards compatibility purposes. We would likely also add deprecated calls to the __experimental function to encourage folks to migrate.

This is a procedure for legacy code, whereas in future all "experiments" will be hidden via the private apis mechanism that is now available.

@talldan
Copy link
Contributor

talldan commented Jun 21, 2023

This PR might serve as an example the process - #47183. Though it's stabilizing a slightly different API, it still showcases keeping the original with the __experimental prefix but adding a deprecation message to it.

@sethrubenstein
Copy link
Contributor Author

@getdave @talldan Sounds good, we'll try and get PR's for that work together in the next week.

@sethrubenstein
Copy link
Contributor Author

@getdave @talldan I have a PR ready for stabilizing those API's and related selectors: #52083.

I'll re-work this pr to get rid of the __experimental references, and I think get rid of the DEFAULT_BLOCK constant in favor of the block.json defined defaultBlock for core/navigation once that PR gets merged into trunk probably best?

getdave and others added 5 commits July 13, 2023 12:15
* Add new state handlers for setting Nav Menu

Fixing unlocking

Avoid unnecessarily effectful code

Fix bug with persistent Nav block locking

Reinstate effect to limit calls to selectBlock

Reinstate effect to run selectively

Isolate Nav specific code

Refactor settings to hook

Isolate Editor Canvas to component

Extract mode statuses to hook

Colocate editor canvas dependencies

Remove requirement for Nav hook to return data

Extract entire canvas to component

Get blocks directly from the store

Use factory to provide default editor component

Extract independent components for default and wp_navigation

Remove template dep from Navigation focus hook

Delete redundant hook

Remove need for settings prop

Extract hooks to files

Export boolean to avoid render

Remove redundant prop and var

Extract Site Editor Canvas component to file

Extract factory to file

Remove need to pass props to abstract component

Improve abstract component and factory naming

Improve usage of constants

Be explicit about entity mapping in factory

Remove templateType prop from SiteEditorCanvas component

Improve variable naming

Use more performant selector

Improve documenting rule for showing appender

Move Navigation specific editor settings to relevant provider

Remove useSiteEditorMode hook

See WordPress#39286 (comment)

Reintstate bug fix with comment

Fix error in rebase

Add edit button

Use Navigation icon and label

Use correct labels

* Add descriptive text as instructed

See WordPress#39286

* Update edit link for Navigation post type

Fixes revisions link

* Fix PHPCS
…ss#51254)

* Update: Adjust modal radius to be between frame and buttons.

* Update changelog.

* Try moving changelog.
…rdPress#51463)

* Mobile - Image block - Fix issue with set width and height images

* Mobile - Update changelog
@sethrubenstein
Copy link
Contributor Author

Oy vey, I messed up my merge. Going to open a new pull request with this change reflecting the latest from trunk. I'll open a new PR shortly @getdave

@sethrubenstein
Copy link
Contributor Author

Sorry for the mess, new PR here @getdave #52610

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Navigation Affects the Navigation Block [Feature] Extensibility The ability to extend blocks or the editing experience First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow selecting the default core/navigation-link variant in the core/navigation block