Open ramonjd opened 5 months ago
I did a little splashing around the shallow waters of the editor, while thinking about possible approaches.
Here are some notes.
They may or may not have import in relation to the main issue 😄
wp_template
, wp_global_styles
is the "main" entity in the site editor.
setEditedEntity
store action in useInitEditedEntityFromURL, which is called in App. Fetched via selectors getEditedPostType
and passed (id and post type) to the Editor from Editor packagecurrentPost
is set in ExperimentalEditorProvider via setupEditor
, then synced with setEditedPost
The Site Editor component load sequence:
edit-site
package loads App componentroute
from useLayoutAreasuseLayoutAreas
returns EditSiteEditor (site) based on postType
and postId
. It can swap layout areas, e.g., sidebar in and out depending on post type etc.EditSiteEditor
renders the shared Editor component from editor package, passing postId
, postType
propsA bit of rambling...
Load a global styles CPT as the "currentPost", and then the UI will decide what to do, e.g., instead of wp_template, wp_global_styles is the "main" entity in the site editor.
I started off doing this just to see how far I could get. I created a custom Editor in the edit site package that expected a global styles postType and postId, but ran into snags pretty quickly as I had to recreate the entire interface skeleton and load a global styles side bar that actually worked :D
I mean, it would be possible to build another editor interface from the ground up. Maybe as a separate package, e.g., styles-editor
, but the effort might not be of value right now.
Build a completely different UI and load in the site editor on demand.
Passing a child to <Editor />
that can actually render instead of the <VisualEditor />
has some promise, but there are a lot of things to "turn off", e.g., the unnecessary toolbars in the header, showing only the global styles sidebar, and preventing the Visual Editor rendering in the first place.
Basically, the editor package would have to know that an alternative view needs to render instead of a post etc
One avenue might be to refactor the Editor to be able to load a "global styles" post.
I'm not following here. What's the advantage of doing this, vs. what we have in place today?
What's the advantage of doing this, vs. what we have in place today?
Good question!
TL;DR - I think the point here is to reduce technical debt and support a top-level global styles editing experience. My take is that it's primarily a technical nice to have, and its dependent on the direction of such PRs as https://github.com/WordPress/gutenberg/pull/65619, so the priority in relation to the redesign tasks already in motion is lower.
@youknowriad first raised the technical and UI concerns: https://github.com/WordPress/gutenberg/pull/62146/files#r1620915555
The case for:
Two global styles-related UIs rely on a custom slot in the editor package: style book and global styles revisions.
The purpose of that slot is to display alternative canvas views independent of whatever entity is loaded. For example, if I'm editing a page and I flip to style book, it won't affect the current state of my page edits.
There are a couple of things that could be improved:
The case against:
Things work okay for now, and we don't have dire need of refactoring, or the justification in terms of time and resources.
As mentioned, this idea will gain focus — for or against — as we work on PRs that offer discrete global styles editing experiences like https://github.com/WordPress/gutenberg/pull/65619
I think for me it's clear that the slot is a hack, it's not really clear in the editor whether you're editing global styles or a template/post.
It's true that issue is technical mostly but I would say that the technical difficulties are just highlighting a UX issue as well. What's the header about when you've actually switched the canvas to focus on global styles...
This is very similar to the journey we had in the site editor: we started by mix and matching editing templates and pages at the same time and it quickly became confusing to users forcing us to come back to have a single focused entity at any given moment in the editor. (Either a template or the page, not both at the same time). Making that change brought a lot of clarity both UX wise and also technically (which is what allowed the unification of the editors). The current issue is basically, the same struggle/issue but for global styles and templates (or global styles and pages)
Just writing some more notes for now.
I've been looking into how to balance the various demands of global styles views in light of the latest discussions, e.g., style book in classic themes, and the discussion about a dedicated styles screen.
A one-size-fits-all approach — one that would cater for the above plus existing style book and global styles revisions — any "styles" view or "styles editor" would need to:
n
historical revisions. It's not yet required but it could even load another theme's theme.json tree.If we think of a world where only a dedicated styles screen exists, for block and classic themes, there's a reasonable argument for a separate, dedicated package with its own interface, canvas and so on, e.g., edit-styles
. This could handle global styles as its main "entity".
However, there's still a case for being able to preview global styles while in the block editor. In fact, that's the reality right now. And that means either making this functionality live in and cooperate with the editor, or, assuming an edit-styles
package existed, linking off to that view. The latter could disrupt the flow of users working on a template in the site editor.
The slot hack works because it allows us to quickly swap in anything we want in place of the editor. Refactoring the editor to do this I think might be too hairy.
Assuming a dedicated styles screen becomes a "thing", this makes me wonder whether the style book needs to be extricated from the site editor. So users could still browse and load revisions, but the style book would be a separate experience. Clicking on the style book would take the user to the dedicated screen, which itself could handle anything related to styles.
</unintelligible-rant-over>
Appreciate the rant! And it was entirely intelligible! I wanted to note in context of that an update I wrote here, urging a focus first on style book, classic theme improvements, and other pieces first. We absolutely need to get the foundations for these screens in a good place eventually, so this is all valid. But there are arguably some smaller, more focused wins (a few suggested in that link), we can get to first!
I'm not sure yet how I feel about a dedicated package. My initial reaction is to avoid early abstraction here as the work is still very much in flux and the direction not settled yet.
That said, one main question here seems to be whether global styles editor/screen is just a regular Editor
from @wordpress/editor
package where the "post" prop (entity) is the global styles entity or whether it's a completely different UI/component StyleEditor
or something like that.
I don't have a clear answer yet, what's clear to me is that:
I think to answer the first question about whether this is just @worpdress/editor
or a new dedicated component/package, we need to check the UI mostly. Is the header the same, is the sidebar the same, is the main area the same.
The more I think about it, the more it feels like these things are very different (only share some small things with the regular post/template editor), so yeah we could have a style-editor
package (probably start as a component).
Background
The Editor Canvas Container is a slot for the Site Editor that was intended to act as an "alternative" editor canvas to render blocks and styles independently of the main canvas container.
It was first added in https://github.com/WordPress/gutenberg/pull/45960 and refined in https://github.com/WordPress/gutenberg/pull/49973
The important feature, at least for global style revisions, was to have a "separate" editor view that could be edited independently of the main editor canvas. So changes could be made to styles and so on in the alternative canvas view. When it closes, the user is returned to the main editor canvas in whatever state they left it.
The slot is currently used by:
What is your proposed solution?
Refactor the way Gutenberg displays these alternative slots.
Options could be:
See feedback:
There are a lot of unknowns. An approach needs to be confirmed.
What problem does this address?
Since https://github.com/WordPress/gutenberg/pull/62146, the Site Editor uses the editor interface from the editor package, which means that the post editor could theoretically fill the Editor Canvas Container is a slot. Currently the only use case for the slot is to house alternative Site Editor views.
Also the way the alternative views are rendered and tracked by is cumbersome and not scalable. Example.
Beyond
The potential is there for Global Styles could be "promoted" to be a top-level entity.
So much like the editor can load a template or a page, it could "load" the site's merged global styles entity with the style book, in conjunction with the global style panel and controls, being the "interface".
Related