Add global styles page and package

[jorgefilipecosta]

The page is available at:

/wp-admin/admin.php?page=gutenberg-edit-global-styles

It does not show anywhere on the normal WordPress UI it is only open when the user opens that URL.

For now, the page is mostly blank but it loads the modules required to start the work on global styles (wp-data, components i18n etc...)

How has this been tested?

I opened /wp-admin/admin.php?page=gutenberg-edit-global-styles and verified an editor global styles page appears as in the screenshot.

Screenshots

[youknowriad]

I thought this was supposed to go to the edit-site package and page. What happens to that plan?

[jorgefilipecosta]

I thought this was supposed to go to the edit-site package and page. What happens to that plan?

Hi @youknowriad, the reason for that is that we don't want to have this UI accessible in the UI until the design team decides on a flow to access this UI. This way, it only appears if you type a URL, there is no UI flow. That makes sure we are not introducing any bias in the decision the team will take.

Regarding an external package, I received some feedback from @epiqueras that a package for global styles may be useful to not mix with edit-site related functionality.

[ItsJonQ]

@youknowriad + @jorgefilipecosta

Apologies for the confusion! To clarify, from our last group meeting, we were unsure of (the ideal) user workflow in regards to updating styles. As such, we felt it may be better to have a dedicated area for now, as @jorgefilipecosta expressed here:

we don't want to have this UI accessible in the UI until the design team decides on a flow to access this UI

However, after some feedback, folks felt like it would be better to have it within edit-site - as we continue to explore user interactions and placement.

There was a lack of communication from my end in coordinating these updates.

Apologies all!

I'll be more mindful to better coordinate efforts moving forward.

[jorgefilipecosta]

Given the change of direction, I think this PR is not useful. I think the new direction is better and edit-site is a good place to iterate we can follow that direction in #20061.

[epiqueras]

Yes, but the code should still be in its own package.

[youknowriad]

Yes, but the code should still be in its own package.

What's the reasoning for this. What's the purpose of said package. The API/contract should be clear if we decide to extract something to its own package and I'm not really sure it's clear from the start.

[epiqueras]

It's a separate UI that can be used in other screens and editors.

[youknowriad]

Why not "block-editor" in that case? Do we have a precedent for a similar UI?

[youknowriad]

Starting to work in an experimental package like edit-site and extracting to generic package (that become APIs) when stable is I think a good pattern to ensure that what we're exposing is good enough. It doesn't mean we shouldn't add new packages when we gain confidence about the APIs.

[epiqueras]

The concerns are very different, and it will be filled with extra code like style resolvers and what not. It makes sense to have it all under one global-styles package that doesn't have to be published until we think it's stable enough, but mixing it with edit-site is just going to create lots of conflicts and make code harder to navigate.

[paaljoachim]

My impression here is that this PR is something that needs/should also be discussed during the core editor chat. Please bring it up and perhaps also post about it on the core editor agenda (if needed).