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 way to programmatically remove editor panels from UI #11802

Merged
merged 6 commits into from Nov 15, 2018

Conversation

@gziolo
Member

gziolo commented Nov 13, 2018

Description

Closes #6225.
Related to #6533.

This PR addressed the following requests:

Is there anything equivalent for Gutenberg, i.e. to remove a panel from the settings on the right side?

From @ecobux:

is there any solution how to remove the panel of the post tags?

How has this been tested?

Execute the following code in the JS console to remove one of the panels and ensure it is not present in the sidebar and Options modal (you can access it from More Menu):

wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'taxonomy-panel-category' ) ;
wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'taxonomy-panel-post_tag' );
wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'featured-image' );
wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'post-excerpt' );
wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'discussion-panel' );

Note that you can't remove Post & Visibility panel. The following (despite being valid) won't be reflected in the UI:

wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'post-status' );

Screenshots

With all available panels completely removed:
screen shot 2018-11-13 at 10 20 40

With a few panels completely removed:
screen shot 2018-11-13 at 09 41 43

Known issues

@noisysocks I would appreciate your help here:

screen shot 2018-11-13 at 09 59 42

When you remove all panels, the section title is still there. Is there an easy way to hide it, too? I know I could use CSS but I would prefer to do it properly :)

Another thing I'm not happy about is that this setting persists. I think this could cause some issues when someone uninstalls a plugin which would use this feature as marked panels would remain removed. Should we move this outside of the persisted state?

Types of changes

New feature (non-breaking change which adds functionality for backwars compatibility).

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

@gziolo gziolo added this to the 4.4 milestone Nov 13, 2018

@gziolo gziolo self-assigned this Nov 13, 2018

@gziolo gziolo requested review from youknowriad, noisysocks and WordPress/gutenberg-core Nov 13, 2018

@tofumatt

Should we move this outside of the persisted state?

I think yes, because: as you say—these panels being removed after a plugin that does so is uninstalled is very weird UX.

Really, they should be persisted changes if they were user-made changes (hiding the tag panel, etc.) but they shouldn't be persisted if a plugin made them (hiding the default tag panel to show a custom one).

Also: your testing instructions read like they'd make good E2E tests and this seems an important part of the UI we're modifying, so I think writing some E2E tests to confirm things work and revert as intended would be wise here.

@gziolo gziolo force-pushed the add/panel-remove-action branch from 7cca809 to 7707607 Nov 13, 2018

@noisysocks

This comment has been minimized.

Member

noisysocks commented Nov 13, 2018

It feels weird to me that we have isEditorPanelEnabled() / toggleEditorPanelEnabled() and isEditorPanelRemoved() / removeEditorPanel(). Could we consolidate these APIs?

When you remove all panels, the section title is still there. Is there an easy way to hide it, too? I know I could use CSS but I would prefer to do it properly :)

It's a shame that there's no way to ask React if props.children will render as empty...

I had a similar problem with <MetaBoxSection> and ending up having to add logic to the section rather than keeping it in each option.

I'm struggling to think of a nice way around this. Perhaps need to bite the bullet and move away from having <OptionsModal> implemented with nested components. Instead, we can have a function generate the options data which a dumb <OptionModal> component then renders a UI for.

Another thing I'm not happy about is that this setting persists. I think this could cause some issues when someone uninstalls a plugin which would use this feature as marked panels would remain removed. Should we move this outside of the persisted state?

Not persisting it makes sense to me.

@youknowriad youknowriad modified the milestones: 4.4, 4.5 Nov 15, 2018

@gziolo gziolo force-pushed the add/panel-remove-action branch from 7707607 to 03e99bb Nov 15, 2018

@gziolo

This comment has been minimized.

Member

gziolo commented Nov 15, 2018

Also: your testing instructions read like they'd make good E2E tests and this seems an important part of the UI we're modifying, so I think writing some E2E tests to confirm things work and revert as intended would be wise here.

@tofumatt, I added e2e test with 03e99bb.

I think yes, because: as you say—these panels being removed after a plugin that does so is uninstalled is very weird UX.

Not persisting it makes sense to me.

Now I that have e2e and unit tests in place, I can refactor store to avoid persistence layer. It looks like there is common agreement that it's wrong :)

It feels weird to me that we have isEditorPanelEnabled() / toggleEditorPanelEnabled() and isEditorPanelRemoved() / removeEditorPanel(). Could we consolidate these APIs?

Agreed on this one, however, I didn't find a better way to distinguish between user's interaction which hides the panel and site owners willingness to never offer this panel to their users. If you have any ideas I'm happy to update PR.

I'm struggling to think of a nice way around this. Perhaps need to bite the bullet and move away from having <OptionsModal> implemented with nested components. Instead, we can have a function generate the options data which a dumb <OptionModal> component then renders a UI for.

Yeah, it should be a follow-up issue as it might be a lot of work for an extremely rare case.

@tofumatt

I agree with @noisysocks that it would be nice to consolidate these selectors or make them more consistently named, but I'm a bit short on ideas for it at the moment. They are expressing different ideas though; maybe it's fine 🤷‍♂️

At any rate, the tests and the code look good to me.

@gziolo gziolo modified the milestones: 4.5, 4.4 Nov 15, 2018

@gziolo gziolo added the [Type] Task label Nov 15, 2018

@gziolo

This comment has been minimized.

Member

gziolo commented Nov 15, 2018

@tofumatt one more commit before we proceed: d1c9038 :)

This moves removedPanels out of preferences which are persisted by default.

Update: one more fix which deletes dead code: 54fce2e.

@gziolo gziolo changed the title from Add a way to programatically remove editor panels from UI to Add a way to programmatically remove editor panels from UI Nov 15, 2018

@tofumatt

Works for me!

@gziolo gziolo force-pushed the add/panel-remove-action branch from 54fce2e to 33b4cb3 Nov 15, 2018

@gziolo gziolo merged commit 87d940f into master Nov 15, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@swissspidy

This comment has been minimized.

Member

swissspidy commented Nov 16, 2018

Is there any way to add panels? And no, I don't want to add an old-school meta box or a separate plugin sidebar.

@gziolo

This comment has been minimized.

Member

gziolo commented Nov 16, 2018

You can always register your own sidebar with as many panels as you want. See:
https://github.com/WordPress/gutenberg/tree/master/packages/plugins#plugins-api
https://github.com/WordPress/gutenberg/tree/master/packages/edit-post/src#pluginsidebar

There is no way to add a panel to the Document Settings sidebar.

grey-rsi pushed a commit to OnTheGoSystems/gutenberg that referenced this pull request Nov 22, 2018

Add a way to programmatically remove editor panels from UI (WordPress…
…#11802)

* Add a way to programatically remove editor panels from UI

* Add e2e test to ensure it is possible to remove sidebar panels

* Edit post: Remove obsolete panel reducer

* Edit post: Refactor state to not persist removed panels

* Edit post: Remove old action handler for removed panels in preferences

* Docs: Update data documentation for edit-post package

@noisysocks noisysocks referenced this pull request Dec 3, 2018

Open

Missing Post Type supports in Options Modal #12394

4 of 4 tasks complete
@ecobux

This comment has been minimized.

ecobux commented Dec 6, 2018

@gziolo Thank you for that! I need exactly

wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'taxonomy-panel-post_tag' );

But how can I apply it when none of my blocks are in use? It should be independent from the blocks.

@ecobux

This comment has been minimized.

ecobux commented Dec 7, 2018

Never mind, I found a way. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment