Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add a way to programmatically remove editor panels from UI #11802
This PR addressed the following requests:
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
wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'post-status' );
@noisysocks I would appreciate your help here:
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).
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.
It feels weird to me that we have
It's a shame that there's no way to ask React if
I had a similar problem with
I'm struggling to think of a nice way around this. Perhaps need to bite the bullet and move away from having
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 :)
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.
Yeah, it should be a follow-up issue as it might be a lot of work for an extremely rare case.
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.
referenced this pull request
Nov 15, 2018
You can always register your own sidebar with as many panels as you want. See:
There is no way to add a panel to the Document Settings sidebar.