Improving FSE for the Agency Use Case

[colinduwe]

Full Site Editing for the Agency Use Case

In a recent FSE Outreach hangout, FSE was described as being in its "awkward teenage years." As FSE matures, what needs to happen so it becomes a world-class tool for both DIY website builders and agencies that craft custom sites with more explicit design constraints? It's a spectrum from fully customizable, overridable everything for an editor or an admin to fully locked down by the theme (agency).

It would be helpful to use this discussion to draw together items that are currently a bit scattered across the Git repo, Make.WordPress, and a variety of blog posts.

Existing features and techniques

• Block locking
• Template locking
• Enabling and Disabling features in theme.json
• Examples of the above features: https://make.wordpress.org/core/2022/02/09/core-editor-improvement-curated-experiences-with-locking-apis-theme-json/
• Conditional block lock controls
• Use theme.json but disable template editing remove_theme_support( 'block-templates' )

Missing features

• Proposal: robust permissions system for FSE theme templates
• Allow editing of only Template Parts, or some specific Template Parts
• Lock controls for block settings (lock text color, unlock background color, etc)
• Developer tool to author theme.json (https://www.themegen.app/)

Features that could be improved

• Multi-entity permission management
• Allow developers to opt out of !important CSS rules generated from theme.json #37590
• WordPress inline CSS doesn't respect editor-font-sizes #38252
• Proposal: Standardized block markup, theme.json design tokens, and CSS classes to improve interoperability #38998 / Explore options for standardizing and extending theme.json design tokens for colors #39372

How-to, etc.

• Integrate changes made in the Site Editor into version control
• Moving Site Editor edits between environments

[annezazu]

Thanks so much for kicking this conversation off. As a heads up, I updated your initial post to include a link to #37943 and template locking. The only other item off the top of my head that I've seen mentioned is this: #39270 but I'm keen to hear from others whether that holds true.

Either way, I'll be following along to see where this discussion leads. As we can, let's make sure new issues are created and perhaps the [Focus] Blocks Adoption label is put to good use.

[ramseyp]

Thank you for this discussion. In addition to the items above, clarity around inline CSS and "default" css being generated would be appreciated. Such as in issues like #38252 and #37590

Essentially providing a method to disable WordPress from loading a lot of styles with !important as this may break already-established style rules. Maybe not "technically" part of FSE, but it's at least related in the eyes/minds of many users and teams working with WP in projects.

[justlevine]

I think #38998 / #39372 make the cut as features that could be improved. Overriding core block css only gets more convoluted each release, making it really hard to cohesively customise the design system.

[ridesirat]

Hi
I don't know if it's just me but I always feel a bit overwhelmed when I try to contribute to WP.
I'm not a full dev, I'm a designer. Maybe I'm not used to Github.
WP is so big (documentation + Github), I have to search a lot to see if what I want to propose already exists or not. And if I don't find it I think it's probably me who can't find it.

It took me a bit to get to this discussion. And it seems the right spot but I'm still not sure.
Isn't there a way to just propose something (and someone filters it to the appropriate space, or discard it if not needed? @annezazu , in my searches I realize you do that a lot (thank you :)

But I will ask/propose here anyway.
As an agency owner, and thinking in FSE, I don't imagine myself editing JSON files. Please, no -
and I do frontend programming (HTML, CSS, JS & basic PHP).
So, thinking in delivering a theme where I don't want a customer to edit anything, just write, could there be a way to lock all formatting - paragraphs, colors, etc?

Maybe a lock all / unlock all in the settings panel, and then individual lock/unlock per setting or/and per parent setting, children.. -like other software, like Figma?

Maybe this is already implemented in FSE templates and I haven't try it..? sorry :(

Also, the list view has so much space, there could be a way to lock blocks there directly with no need for right click. And other options too..?

Thanks for listening

[colinduwe]

@ridesirat A block locking feature was released in 6.0. Template locking It requires a bit of effort to restrict who can lock/unlock a block. Conditional block lock controls
I'm unaware of a ticket to add lock controls to controls within a block.

But I agree 100% that information is spread pretty wide which makes it challenging to find solutions to what are pretty common issues for us. So that's my hope for this discussion: how do we gather the resources we need and influence the direction of FSE to be the best tool possible.

[annezazu]

I have to search a lot to see if what I want to propose already exists or not. And if I don't find it I think it's probably me who can't find it.

For the record, share anyway! Always share. Those of us who help with triage and dot connecting will handle consolidating. Does it help to search and find a nice spot for it? Of course. Is it reasonable to expect everyone can? No :) Thank you for your efforts to find and contribute to this discussion.

I'm unaware of a ticket to add lock controls to controls within a block.

I'm not aware of this either as currently the approach takes on less locking the tools and more removing or changing the defaults of what's offered. You can see some of that in this post: https://make.wordpress.org/core/2022/02/09/core-editor-improvement-curated-experiences-with-locking-apis-theme-json/

[colinduwe]

@annezazu Thanks for the link. @ridesirat Trying to author JSON by hand is certainly a pimple of FSE's awkward teenage years. I know folks are working on tools for this (https://www.themegen.app/). I dream of a developer plugin I can install on my local environment that gives me a UI for tweaking my theme's theme.json file.

[annezazu]

I dream of a developer plugin I can install on my local environment that gives me a UI for tweaking my theme's theme.json file.

Wanted to cross connect this discussion with a proposed handbook page: WordPress/Documentation-Issue-Tracker#401 It may not go through but it offers some solid resources for now!

[colinduwe]

The folks on the Genesis team over on WP Engine are working on a tool: https://twitter.com/mikemcalister/status/1539622809390956544?s=20&t=6MrvQG6mzG2yvQtPnbbYlg

[ridesirat]

Thank you both.
I wish I could go further in my collaboration but I own a very small agency that needs my full attention, unfortunately I don't really have time to go deeper in reading all the material.
But even reading quickly I see some hidden gems like the one in the link @annezazu shared. Things like these should be more easy to discover.
And @carolinan amazing "tool" - which for me is not visible enough
https://fullsiteediting.com/lessons/creating-theme-json/
https://fullsiteediting.com/lessons/remove-settings-in-theme-json/

It would also be super useful to have graphic cheat sheets very accessible about the different UIs when editing in WP to get to know all the names of things to help describing them: panels, menus, settings in each area..

"So that's my hope for this discussion: how do we gather the resources we need and influence the direction of FSE to be the best tool possible."

I think there could be a simpler way of displaying the main info. I don't know if it's just me but I think we can build things in WP via dev and via FSE, right? And they are different (it seems to me), so, why not create like a sitemap with main topics to develop for each - it would be a super simplified and compressed version of the main things [and hidden gems] needed to put something to work. Then, inside them, the rest of the details.
Organized not like a book with all the stuff, but like a tool you want to put your hands on.
This is a oversimplified example:
FSE
|__Templates
|    |__Make
|    |__Locking Blocks
|    |__Locking Settings
|__Blocks
| |__Make
| |__Edit
|__Patterns
| |__Make
| |__Edit
|__Etc
|__Under Development (link to "Discussions" in Github) where there could be a very simple description saying "Share your ideas".
Then you just click in what you want to explore.

the approach takes on less locking the tools and more removing or changing the defaults of what's offered

It makes total sense. But I have to be honest, I didn't understand it and if it's already in progress or not.

Is there a way for something like this - disabling through parent level?

"typography": {
	"display": false,  // display, disable, visible..?
	"lineHeight": true,
	"customFontSize": false,
	"dropCap": false
}

or, higher:

"styles": {
	 "disable": true,
	"color": {
		"background": "#FFF",
		"text": "var(--wp--preset--color--primary)"
	}
}

I have the feeling that asking and replying to you too much makes you waste too much time.
If true, this should be acknowledge and optimized somehow.
Please don't feel the need to reply : )

[cr0ybot]

I love the idea of FSE in theory, but it is so focused on presentation that it becomes hard to separate from the data required for more complicated functionality. I can't speak for every agency, but we are doing more than simple "brochure" sites, and often we need one or more custom post types that act as data entities that can be efficiently queried for certain bits of post meta, and often times it doesn't even make sense for the post type to use the Gutenberg editor.

What I wish we could have from FSE is a way to define a post template that is output-only that could be fed by data, or for a true post template that, once edited, affects all posts using that template. I know this sounds like the antithesis of FSE—maybe it is—but currently if some new feature or design update is added to the site, often times it means going back through every published post to update them manually.

The idea of FSE is great, but there also just doesn't seem to be enough demand for such a completely editable WYSIWYG website from the kinds of clients we work with. They usually want to be able to add and update content efficiently, and sometimes that means that the block editor ends up being too much visual noise and requires too much custom code to handle the output, particularly when it comes to optional "fields".

We decided last year to redesign and build our own site with a custom block theme to determine if it was feasible to start doing this with clients, but the project stalled halfway completed because of the amount of work required. You might think it's due to the React learning curve, but I am also a React and React Native app developer. FSE starts with the premise that everything should be customizable, and it doesn't really synergize with the idea of "explicit design constraints".

[cr0ybot]

One year later, I wanted to post an update here and, in a roundabout way, apologize. I've been using the site editor more and more, on every personal project at least, and I feel that it is going in the right direction for agency work. My initial post comes across as a little naive now, honestly.

It's funny because I read some of it now and think "you're so close, you're almost there". See, what I was originally asking for—mainly, templates that display structured data that can be updated later—is what "full site editing" is all about, and I see that now. You can make a template for a post type and design it in the block editor almost exactly as you would hardcode a PHP template. Are there core blocks that will output your custom field data exactly as you want? No, of course not—that's your job as the custom theme developer! I build custom blocks to output custom post meta, referencing core blocks that utilize postType and postId context values, and add them to the post type block template, and now I have an editable post type template that "updates" all posts. The idea that you have to go back into each post to update them manually is very un-FSE.

The takeaway is that, if you need custom fields as agencies often do, you can still use them. Install ACF or Pods framework and do your worst, just be prepared to build custom blocks to handle front-end output.

I am very happy with "synced patterns" as well—a huge missing piece for sure that I'm excited to use more often in client projects.

Edit: I'd like to add that I think ACF blocks, while fantastic, actually delayed these realizations, because ACF blocks are self-contained and do not save to post meta but to the block itself. You can now basically do the same thing we used to do—add values to custom fields on the post in a "metabox", and then output them in a custom way in a template. It's just that the template is editable with a GUI.

[annezazu]

One year later, I wanted to post an update here and, in a roundabout way, apologize. I've been using the site editor more and more, on every personal project at least, and I feel that it is going in the right direction for agency work. My initial post comes across as a little naive now, honestly.

Thanks for looping back, continuing to use FSE, and sharing your stance now. For anyone following, please keep sharing where you're getting blocked. Please keep opening issues, asking questions, and giving feedback. It's what helps the project iterate ❤️

In terms of Custom Fields, you might be interested in this recent issue and discussion: #51373

[cr0ybot]

Thanks @annezazu, I am familiar with that discussion and should catch up on it.

Somewhat separate from the usual agency work, I'm developing a plugin that needs to output special headings, images, etc from a separately controlled source, and creating custom blocks for those things did not feel great. Looking forward to a future in which you can control a core image block to output not just a specific meta value, but any value imposed upon it via some API.