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

Add interface package with sidebar functionality #20698

Conversation

@jorgefilipecosta
Copy link
Member

jorgefilipecosta commented Mar 7, 2020

Description

Supersedes: #20336
This PR starts an admin-screen package suggested by @youknowriad in #20336 (review).

This package for now just contains the sidebar functionality but other functionality will be added (e.g: fullscreen mode).

The sidebar functionality is renamed the ComplementaryArea as suggested by @gziolo.
This package, for now, is experimental should be private and is bundled with other packages.

Regarding the admin screen store:

We implement an API in the store that allows keeping track of which area is active in a given zone when only one area can be active at a time. For example what sidebar is being rendered, what tab in a tab system is enabled etc...

wp.data.dispatch('core/admin-screen').setSingleActiveArea( 'edit-site/complementary-area', 'edit-site/block-inspector'  );

wp.data.select('core/admin-screen').getSingleActiveArea( 'edit-site/complementary-area' ); -> "edit-site/block-inspector"

wp.data.dispatch('core/admin-screen').setSingleActiveArea( 'edit-site/complementary-area', 'edit-site/global-styles'  );

wp.data.select('core/plugins').getSingleActiveArea( 'edit-site/complementary-area' ); -> "edit-site/global-styles"

wp.data.dispatch('core/plugins').setSingleActiveArea( 'edit-site/complementary-area' );

wp.data.select('core/plugins').getSingleActiveArea( 'edit-site/complementary-area' ); -> undefined

We implement an API in the store that allows keeping track of which areas are active in a given zone when multiple areas can be active at a time
E.g: which plugins are pinned, which panels are open.
This API allows plugins to keep track for example which panels are open and take advantage of the persisting mechanism (when we add it) without the need to implement their own store/persistence.

wp.data.select('core/admin-screen').isMultipleActiveAreaActive( 'edit-post/complementary-area', 'edit-post/block-patterns-sidebar' ); -> false

wp.data.dispatch('core/admin-screen').setMultipleActiveAreaEnableState( 'edit-post/complementary-area', 'edit-post/block-patterns-sidebar', true );

wp.data.select('core/admin-screen').isMultipleActiveAreaActive( 'edit-post/complementary-area', 'edit-post/block-patterns-sidebar' ); -> true

How has this been tested?

I verified the edit-post sidebar still works as expected (namely auto-closing on mobile, keyboard shortcuts, plugin sidebar).
I verified the sidebar mechanism added on edit-site works as expected.

@github-actions

This comment has been minimized.

Copy link

github-actions bot commented Mar 7, 2020

Size Change: +4.23 kB (0%)

Total Size: 861 kB

Filename Size Change
build/annotations/index.js 3.44 kB -3 B (0%)
build/autop/index.js 2.58 kB -1 B
build/block-directory/index.js 6.02 kB +2 B (0%)
build/block-editor/index.js 102 kB +71 B (0%)
build/block-library/index.js 110 kB +38 B (0%)
build/block-serialization-default-parser/index.js 1.64 kB -2 B (0%)
build/blocks/index.js 57.5 kB +1 B
build/components/index.js 190 kB +65 B (0%)
build/compose/index.js 6.2 kB -2 B (0%)
build/core-data/index.js 10.6 kB -1 B
build/data/index.js 8.26 kB +1 B
build/date/index.js 5.37 kB +2 B (0%)
build/edit-post/index.js 92.3 kB +1.3 kB (1%)
build/edit-post/style-rtl.css 8.35 kB -86 B (1%)
build/edit-post/style.css 8.34 kB -85 B (1%)
build/edit-site/index.js 8.63 kB +1.99 kB (23%) 🚨
build/edit-site/style-rtl.css 3.44 kB +455 B (13%) ⚠️
build/edit-site/style.css 3.44 kB +457 B (13%) ⚠️
build/edit-widgets/index.js 4.43 kB +1 B
build/editor/index.js 42.8 kB +30 B (0%)
build/element/index.js 4.44 kB -1 B
build/format-library/index.js 6.95 kB +2 B (0%)
build/media-utils/index.js 4.84 kB -1 B
build/notices/index.js 1.57 kB +1 B
build/plugins/index.js 2.54 kB -2 B (0%)
build/primitives/index.js 1.5 kB -2 B (0%)
build/redux-routine/index.js 2.83 kB -1 B
build/rich-text/index.js 14.5 kB -1 B
build/shortcode/index.js 1.7 kB -1 B
build/warning/index.js 1.14 kB +1 B
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 998 B 0 B
build/api-fetch/index.js 3.39 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/style-rtl.css 760 B 0 B
build/block-directory/style.css 760 B 0 B
build/block-editor/style-rtl.css 11 kB 0 B
build/block-editor/style.css 11 kB 0 B
build/block-library/editor-rtl.css 7.21 kB 0 B
build/block-library/editor.css 7.21 kB 0 B
build/block-library/style-rtl.css 7.49 kB 0 B
build/block-library/style.css 7.5 kB 0 B
build/block-library/theme-rtl.css 669 B 0 B
build/block-library/theme.css 671 B 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/components/style-rtl.css 15.8 kB 0 B
build/components/style.css 15.7 kB 0 B
build/data-controls/index.js 1.04 kB 0 B
build/deprecated/index.js 772 B 0 B
build/dom-ready/index.js 568 B 0 B
build/dom/index.js 3.06 kB 0 B
build/edit-widgets/style-rtl.css 2.57 kB 0 B
build/edit-widgets/style.css 2.57 kB 0 B
build/editor/editor-styles-rtl.css 423 B 0 B
build/editor/editor-styles.css 426 B 0 B
build/editor/style-rtl.css 3.38 kB 0 B
build/editor/style.css 3.38 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/style-rtl.css 502 B 0 B
build/format-library/style.css 502 B 0 B
build/hooks/index.js 1.93 kB 0 B
build/html-entities/index.js 622 B 0 B
build/i18n/index.js 3.57 kB 0 B
build/is-shallow-equal/index.js 710 B 0 B
build/keyboard-shortcuts/index.js 2.3 kB 0 B
build/keycodes/index.js 1.7 kB 0 B
build/list-reusable-blocks/index.js 2.99 kB 0 B
build/list-reusable-blocks/style-rtl.css 226 B 0 B
build/list-reusable-blocks/style.css 226 B 0 B
build/nux/index.js 3.01 kB 0 B
build/nux/style-rtl.css 616 B 0 B
build/nux/style.css 613 B 0 B
build/priority-queue/index.js 781 B 0 B
build/server-side-render/index.js 2.55 kB 0 B
build/token-list/index.js 1.28 kB 0 B
build/url/index.js 4.01 kB 0 B
build/viewport/index.js 1.61 kB 0 B
build/wordcount/index.js 1.18 kB 0 B

compressed-size-action

@jorgefilipecosta jorgefilipecosta force-pushed the add/admin-screen-package-move-sidebar-functionality-admin-screen branch 2 times, most recently from 2ef0838 to ee38298 Mar 7, 2020
@jorgefilipecosta jorgefilipecosta requested review from nerrad, ntwb and talldan as code owners Mar 8, 2020
@jorgefilipecosta jorgefilipecosta force-pushed the add/admin-screen-package-move-sidebar-functionality-admin-screen branch 4 times, most recently from 924d9b5 to e1ed846 Mar 8, 2020
@mtias

This comment has been minimized.

Copy link
Contributor

mtias commented Mar 8, 2020

admin-screen seems like a weird name for this to me.

@jorgefilipecosta jorgefilipecosta force-pushed the add/admin-screen-package-move-sidebar-functionality-admin-screen branch 2 times, most recently from 46fa964 to 4343c53 Mar 8, 2020
@youknowriad

This comment has been minimized.

Copy link
Contributor

youknowriad commented Mar 9, 2020

@mtias we have different things we want to reuse across screens. Sidebar Plugins, EditorSkeleton (PageSkeleton), FullscreenMode

What do you suggest as a name?

@mtias

This comment has been minimized.

Copy link
Contributor

mtias commented Mar 9, 2020

I know it's already in use, but this would be the "editor" package to me (as opposed to the block editor).

@jorgefilipecosta

This comment has been minimized.

Copy link
Member Author

jorgefilipecosta commented Mar 9, 2020

Maybe editor-screen would be a good name?

@mtias

This comment has been minimized.

Copy link
Contributor

mtias commented Mar 9, 2020

Can you list all the "editor" related packages we'd have?

@jorgefilipecosta

This comment has been minimized.

Copy link
Member Author

jorgefilipecosta commented Mar 9, 2020

Can you list all the "editor" related packages we'd have?

Hi @mtias,
We would have "block-editor", "editor" and "editor-screen" plus three packages that would potentially use editor-screen: "edit-post", "edit-site", "edit-widgets".

@mtias

This comment has been minimized.

Copy link
Contributor

mtias commented Mar 9, 2020

What are the conceptual differences among block-editor, editor and editor-screen?

@jorgefilipecosta jorgefilipecosta mentioned this pull request Mar 10, 2020
4 of 6 tasks complete
@jorgefilipecosta

This comment has been minimized.

Copy link
Member Author

jorgefilipecosta commented Mar 10, 2020

What are the conceptual differences among block-editor, editor and editor-screen?

Hi @mtias,

  • block-editor -> Generic block editor, responsible for dealing with the blocks. Given a data structure that represents a set of blocks renders a UI to edit these blocks, to remove, move, and insert new blocks. Not WordPress specific.
  • editor -> Provides a set of helpers to deal with WordPress posts and its edits. I think today we could do almost everything this module does with our data APIs; in the long term, this module should probably be deprecated.
  • editor-screen -> Provides a set of helpers to build a screen UI in WordPress similar to the post edit screen Gutenberg offers. Allows controlling which areas are active or not, e.g., block-inspector, a plugin sidebar, what modes are active, e.g., fullscreen., what items are open or closed the panels, and deals with persisting these settings.
@mtias

This comment has been minimized.

Copy link
Contributor

mtias commented Mar 10, 2020

editor and editor-screen should likely be folded together then.

@youknowriad

This comment has been minimized.

Copy link
Contributor

youknowriad commented Mar 11, 2020

Do you think these components/tools (Skeleton, Sidebar, Fullscreen) are things specific to editor screens or any Admin screen? Personally, I'm thinking the latter.

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Mar 11, 2020

Whatever the final decision is, we should improve the documentation for all mentioned packages and provide a high-level overview of how they all fit together. It's always been an issue for all people that start with Gutenberg development.

@jorgefilipecosta

This comment has been minimized.

Copy link
Member Author

jorgefilipecosta commented Mar 11, 2020

Do you think these components/tools (Skeleton, Sidebar, Fullscreen) are things specific to editor screens or any Admin screen? Personally, I'm thinking the latter.

Good point, I agree these UI artifacts may be the basis to a screen in WordPress that may not necessarily contain an editor, e.g: I may imagine this artifact may contain a system to manage tickets, and the sidebars show information about the person that submitted the ticket.

What do you think @mtias?

@jorgefilipecosta jorgefilipecosta force-pushed the add/admin-screen-package-move-sidebar-functionality-admin-screen branch from bd6618c to a37e622 Mar 20, 2020
@jorgefilipecosta

This comment has been minimized.

Copy link
Member Author

jorgefilipecosta commented Mar 20, 2020

Hi @gziolo, thank you for the review the PR was updated and rebased.

@jorgefilipecosta jorgefilipecosta force-pushed the add/admin-screen-package-move-sidebar-functionality-admin-screen branch from a37e622 to 59f1577 Mar 20, 2020
Copy link
Member

gziolo left a comment

Thanks for addressing the feedback shared. I took another pass, PR is huge :)

Do you plan to add unit tests for the store implementation?

postTitle: select( 'core/editor' ).getEditedPostAttribute(
'title'
),
shortcut: select(

This comment has been minimized.

Copy link
@gziolo

gziolo Mar 23, 2020

Member

Should all sites share the same shortcut for toggling the sidebar/complementary area?

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Mar 23, 2020

Author Member

I think sharing the same shortcut makes sense. I guess we can keep the shortcut prop but in the future add a default value. In our core use cases we would not pass the prop so we would make all the screen share the same shortcut.

type: 'CLOSE_GENERAL_SIDEBAR',
};
export function* closeGeneralSidebar() {
yield* openGeneralSidebar();

This comment has been minimized.

Copy link
@gziolo

gziolo Mar 23, 2020

Member

Is it a bug, why would you call open to close?

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Mar 23, 2020

Author Member

It is not a bug we are calling openGeneralSidebar without any sidebar name so the name is undefined and in that case, we will make sure no sidebar is available in that area.
But I will update the code, to not use openGeneralSidebar as it is confusing.

<PluginComplementaryArea.Slot scope="edit-site" />
<PluginComplementaryArea
scope="edit-site"
complementaryAreaName="edit-site/block-inspector"

This comment has been minimized.

Copy link
@gziolo

gziolo Mar 23, 2020

Member

Would it work if we would simplify it a bit to:

Suggested change
complementaryAreaName="edit-site/block-inspector"
name="block-inspector"

complementaryAreaName could be combined as scope + name. What do you think?

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Mar 23, 2020

Author Member

In most cases, the name of the area is ${ context.name }/${ ownProps.name }.
That means an area is named with the plugin id of the plugin that originated it and the name of the sidebar.
I'm not sure if we should include the scope as the name of the area, because in the store the area is already in a tree under the scope.

In the case for our own core sidebars, we are passing an explicit name I totally agree the name could be "block-inspector" instead of "edit-site/block-inspector", I used the later because in edit-post we were also using "edit-post/document" instead of just "document" and "edit-post/block" instead of "block". Renaming things in this PR will make it even bigger, as we would need back-compatibility for the previous names.

"name": "@wordpress/interface",
"version": "0.0.1",
"private": true,
"description": "Interface module for WordPress.",

This comment has been minimized.

Copy link
@gziolo

gziolo Mar 23, 2020

Member

Do you have some ideas on making this description more friendly for those using npm to find packages?

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Mar 23, 2020

Author Member

I extended a little bit the description, but for now, this package does not offer much and will probably not be very useful to third-party users.
When the functionality of this package is expanded and we are confident with what the package offers I guess we can expand even more the description and make it more concrete.

packages/interface/package.json Outdated Show resolved Hide resolved
@@ -145,7 +145,7 @@ function Layout() {
</div>
) }
<SettingsSidebar />
<Sidebar.Slot />
<PluginComplementaryArea.Slot scope="edit-post" />

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 23, 2020

Contributor

Can you explain the naming here? PluginComplementaryArea?

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 23, 2020

Contributor

Actually, what I'm missing in this PR is documentation, what are these components for? How to introduce plugins to a new screen? This would help personally understand the APIs and provide better feedback.

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Mar 24, 2020

Author Member

Hi @youknowriad, I added docs to the API we are exposing.
This PR is exposing two actions, two selectors, and two pairs of slot fill components.
Let me know If the documentation helped to understand how the mechanism we are adding work.

This comment has been minimized.

Copy link
@gziolo

gziolo Mar 25, 2020

Member

That's useful 👍 @youknowriad see #20698 (comment).

@jorgefilipecosta jorgefilipecosta force-pushed the add/admin-screen-package-move-sidebar-functionality-admin-screen branch 4 times, most recently from b2c7d7d to 96a6fa5 Mar 23, 2020
Copy link
Contributor

youknowriad left a comment

Thanks for the docs, it helps a lot.




#### Store

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 25, 2020

Contributor

Reading the README it's unclear to me what this store is about at this point, I'm introduced to something called areas (multiple and single) but I don't know what these areas are at this point.

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 25, 2020

Contributor

Technical remark: Adding a store to a package make that store a singleton, thus a bit less reusable. I'd have preferred if the API was only based on components but I'm not sure how possible is that.

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Mar 25, 2020

Author Member

I'd have preferred if the API was only based on components but I'm not sure how possible is that.

We can have a provider that keeps state passes it by context and the ComplementaryArea and PinnedItems components access that state.
There are some challenges with that approach:
- As it is not a store we would not automatically use the persistent mechanisms a store provides and we would would need to implement something new.
- Currently to open/close sidebars third-party plugins can dispatch actions to edit-post (our code also uses that). We totally removed the reducers and store logic for edit-post sidebars but we are being back-compatible with all the edit-post store actions and selectors. If we used a components approach without a store being back-compatible would be more tricky.

This comment has been minimized.

Copy link
@gziolo

gziolo Mar 25, 2020

Member

It'd be interesting to explore persistent contexts :)

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Mar 25, 2020

Author Member

It'd be interesting to explore persistent contexts :)

That's is something we could do, the more tricky part would be the second point: being back-compatible with the current store calls.
The provider for this area would also need to be above the plugin content provider and we would need to provide an API probably context-based that plugins can use to open complementary areas in new screens (where they can not use the edit-post back-compatibility layer).

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 25, 2020

Contributor

Seems like a bit too much to replicate, I wonder if at some point we could move away from Global stores and just have "local stores" (which is basically the same thing as a context)


Four components are exposed. The components are based on slot & fill paradigm two components are "fills" and two components are "slots".

`ComplementaryArea` and `ComplementaryArea.Slot` form a slot fill pair to render complementary areas. Multiple `ComplementaryArea` components representing different complementary areas may be rendered at the same time, but only one appears on the slot depending on which complementary area is enabled.

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 25, 2020

Contributor

ComplementaryArea feels like a weird name to me. I don't have a better name though. Thoughts @aduth @mtias

This comment has been minimized.

Copy link
@gziolo

gziolo Mar 25, 2020

Member

complementary is one of the ARIA regions:
https://www.w3.org/TR/wai-aria-1.1/#region

Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other landmark roles, such as main, complementary, or navigation.

A complementary landmark is a supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content.

More details:

https://www.w3.org/TR/wai-aria-1.1/#complementary

https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complementary.html

This comment has been minimized.

Copy link
@gziolo

gziolo Mar 25, 2020

Member

For the full picture, it's based on previous discussions that using Sidebar as the component name is wrong here because it behaves differently on mobile web (modal like) and native mobile (bottom sheet). In addition, we should try to avoid naming high-level components after their placement on the screen but rather phrase them in a way that expresses their intent, some good examples that exist:

  • BlockControls
  • InsepectorControls
  • PinnedItems

#### Store

#### Single Active Area Functionality

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 25, 2020

Contributor

I'm not sure i understand why we need separate actions/selectors for multiple or single active areas. I feel this could be just a prop of the ComplementaryArea.Slot component.

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 25, 2020

Contributor

Also, do we need both use-cases in the current screen?

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Mar 25, 2020

Author Member

Hi @youknowriad, the single reducer handles the case where only one or zero areas are active in a given scope, so enabling an area disables the previous active are. It is used to track which complementary area (sidebar) is active in a given screen. The multiple reducer handles cases, where multiple areas can be active in a given scope, enabling an area, does not impacts the other areas. It is used to track which pinned items are shown.

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 25, 2020

Contributor

Yes, I understand buy why we need separate actions, can we just use the same actions (like we do for selected blocks for instance and their actions). The "prop" for the slot could be responsible of adapting the behavior properly.

What I'm saying is that a consumer shouldn't have to care about whether a single or multiple areas can be enabled at the same time, this should be internal to the Slot. The consumer should just enable/disable areas.

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Mar 25, 2020

Author Member

Hi @youknowriad, so essentially the idea is to remove logic from the store the store? The store would just contain active areas and would be UP for the store users to have the logic and know if multiple active areas can be enabled or not?

If that's the case there are some disadvantages we would for example not be able to open a sidebar by just dispatching an action. In order to open a sidebar, one would need first to check if there is an active sidebar if yes dispatch an action to disable that area and then dispatch an action to enable the new sidebar.

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 25, 2020

Contributor

so essentially the idea is to remove logic from the store the store? The store would just contain active areas and would be UP for the store users to have the logic and know if multiple active areas can be enabled or not?

Not really

If that's the case there are some disadvantages we would for example not be able to open a sidebar by just dispatching an action

this should be a single action still but since the complementary slot has a config saying that it's a single active slot. It will automatically do its magic to disable the old one.

What I'm saying is that a consumer should do just activateComplementaryArea( name ) (random naming here) regardless of whether the slot will display one or multiple at the same time. It's the responsibility of the implementation to know how it's configured, it shouldn't be the responsibility of the caller because otherwise for the same slot, some consumers will say it's single while others will say it's multi

@jorgefilipecosta jorgefilipecosta force-pushed the add/admin-screen-package-move-sidebar-functionality-admin-screen branch from 5a2bc43 to e8d9617 Mar 26, 2020
Copy link
Contributor

youknowriad left a comment

I like this direction. Thanks for the updates.

@jorgefilipecosta jorgefilipecosta force-pushed the add/admin-screen-package-move-sidebar-functionality-admin-screen branch from a0aa2ad to cc9ae9b Mar 27, 2020
@jorgefilipecosta jorgefilipecosta force-pushed the add/admin-screen-package-move-sidebar-functionality-admin-screen branch from cc9ae9b to af54fbb Mar 27, 2020
jorgefilipecosta and others added 7 commits Mar 5, 2020
Squashed commits:
[55e02fd47e] Update packages/edit-post/src/components/layout/index.js

Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl>
[7aa42cba13] Update packages/interface/src/components/plugin-complementary-area-header/index.js

Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl>
[13abfa99d2] Update packages/interface/package.json

Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl>
[61b5b1086e] Update packages/interface/package.json

Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl>
[b5f425096c] Update packages/interface/src/components/pinned-items/index.js

Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl>
[2e5bb80774] Update packages/edit-post/src/components/header/index.js

Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl>
[40e1bb4c4e] Add interface package with sidebar functionality
Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl>
@jorgefilipecosta jorgefilipecosta force-pushed the add/admin-screen-package-move-sidebar-functionality-admin-screen branch from af54fbb to 78d8de7 Mar 30, 2020
@jorgefilipecosta jorgefilipecosta merged commit 16e4f20 into master Mar 30, 2020
3 checks passed
3 checks passed
build
Details
pull-request-automation
Details
Travis CI - Pull Request Build Passed
Details
@jorgefilipecosta jorgefilipecosta deleted the add/admin-screen-package-move-sidebar-functionality-admin-screen branch Mar 30, 2020
@github-actions github-actions bot added this to the Gutenberg 7.9 milestone Mar 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.