-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Add a basic Options modal #10215
Add a basic Options modal #10215
Conversation
c7c3e1f
to
77f702c
Compare
edit-post/store/reducer.js
Outdated
} | ||
|
||
return state; | ||
}, | ||
panels( state = PREFERENCES_DEFAULTS.panels, action ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if I should modify the existing panels
state tree for our needs e.g. panels: { 'post-status': { enabled: true, shown: false } }
instead of adding a whole new disabledPanels
key.
And, if so, is it worth writing migration logic so that the shown/hidden panel state isn't lost when users update Gutenberg?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think I'll merge disabledPanels
and panels
. It doesn't matter that users upgrading Gutenberg will have to re-open a few panels here and there.
Hey - had a test of this. Looks nice. 👍 When toggling tips you I saw this, which looks a bit weird. I wonder whether the modal should be elevated over the tip. Fun with z-indexes 😄 Confusingly, clicking outside of the tip dimisses the modal, even though the tip is on top. Also, separately, the blank space at the bottom of the modal seems like it shouldn't be there. I imagine you'd only see that on larger screen sizes: |
Hmm, but then what happens when we inevitably want to have a tip point to something in a modal? I might look at saving the Tips on/off setting when the modal is dismissed.
👌 will look into this! Thanks for the review. |
I also thought that, but then thought probably not worth worrying about until it happens.
That might be a better user experience generally - definitely less noisy. Just for tips though or all options? Only drawback would be if the user tries to navigate away with unsaved changes to the checkboxes. |
@noisysocks ping me when you are ready with the updates around making data layer API more general we discussed last week 🙇 |
77f702c
to
7fcbf7c
Compare
36f037e
to
2645689
Compare
Hi! 👋 @talldan: I've rebased this and updated it to handle custom taxonomies and set the 'Show Tips' setting when the modal is dismissed. Would you mind giving it another comprehensive review? @gziolo: I did not add an API that lets developers disable block inspector panels to this PR. I'd rather that we tackled this in a future PR so that we can give that new code the attention that it deserves. Still, if there's anything here that you think should change to make our lives easier in the future—let me know about it! |
1c8e6e6
to
5308f95
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@noisysocks - This looks really good! In terms of UX, I only have a concern about the inconsistency with some options enabling immediately and others being deferred, but lets proceed see if anyone mentions it (probably unlikely).
I think I might have spotted a couple of things around deprecations, but let me know if I'm wrong.
} | ||
} | ||
|
||
export const EnablePublishSidebarOption = compose( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is very compositiony! Really nice use of composition. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'm pretty pleased with this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope to do more in-depth review on Monday. However, don't wait for me if you think it's ready to go. We already pair-reviewed most of the code so this is definitely aligned with what I envisioned for this feature.
|
||
case 'TOGGLE_PANEL_OPENED': { | ||
const { panelName } = action; | ||
const isOpen = state[ panelName ] === true || get( state, [ panelName, 'opened' ], false ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Backward compatible 💯
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙂
I didn't expect that, I think your data related changes look solid, it should make this earlier in the future. I think that inspector panels won't be customizable until we start phase 2. It's too much work. Let's focus on backward compatibility. |
- Allow users to enable or disable Page Attributes within the Options modal. - Only display the Page Attributes and Post Excerpt options when they are applicable.
Expands the click area of an option to fill the width of the modal so that it's easier to toggle on and off.
1169eaa
to
fed61bb
Compare
I see you have already fixed the issue with Status & Visibility which should always be rendered. I see that it's possible to hide |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All my feedback was addressed. It works as expected. There is still this open discussion about doing refactor for panel names and their components: https://github.com/WordPress/gutenberg/pull/10215/files#r225102139. However it isn't a blocker in my opinion. We can handle it as follow-up when we agree how to make it more conistent.
There is still this issue @afercia raised which isn't introduced by this PR. It existed before with the Keyboard shortcuts
modal dialog, as well with sidebars as filed in #1918. I personally believe, that we should find a proper way of handling this issue globally rather than trying to patch it with some hardcoded focus return in this PR. I added comment #1918 (comment) to ensure it's taken into account when #1918 is solved.
Should definitely be handled globally as we cannot assume plugin / block authors would adhere to it consistently. I propose keeping track of a |
I agree; the issue of focus is not specific to this PR and should not hold it up. |
Good job @aduth, your check works, Travis fails because:
It took me a while to figure out because we run everything concurrently. |
Yeah, was raised in #core-restapi as well yesterday. See #10625. |
@tofumatt has a specific issue been opened? If so, can you please me point me at it? |
It's pretty hard to spot the error among the noise—thanks for the pointer! 😅 |
Why not add in Options modal an option for resizing editor (content) width ? With live preview. You would make life easier for all non coders who install finished themes. Not a small number, you have to agree. I personaly each time I go to the Gutenberg to test new things think, damn how narrow is editor content width. I literally stare in huge empty white space. Someone here on Github mentioned survey, and how this width is most natural for majority of Users. I would like to see results of this survey, not to blindly trust anyone's statement. |
@StaggerLeee: We won't be adding any more features to Gutenberg so that we can focus on polishing what we have for WordPress 5.0. I'd encourage you to open up a new issue with your feature suggestion and we can look into it for a future release 😄 |
If you promise me not to close it directly. I am tired of playing Pinata. 😃 |
Implements half of #10210.
Adds a basic Options modal:
Not included in this PR is the ability to toggle "advanced panels" AKA metaboxes.
To test: