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

Feedback and questions about the FSE (also a part of FSE call for testing) #29228

Closed
overclokk opened this issue Feb 22, 2021 · 11 comments
Closed
Labels
[Type] Feedback Issues that relate purely to feedback on a feature that isn't necessarily actionable

Comments

@overclokk
Copy link

I made some test with FSE and here I want to share with you my feedback about it.
Only Gutenberg active, no other plugins.
I tried TT1 and also a custom theme.

Inside post editor

I see that blocks for FSE are under "design" category in the inserter, but I think it's better to put them in their own category to avoid confusion with non FSE blocks. Just saw this issue

I tried to add some FSE blocks like post-content inside a post content and boom, my computer exploded (just kidding), maybe in some context it should not be allowed to add blocks like post-content inside the content or better it should be displayed a notice to inform that to make it works needs to be configured like a WP_Query.

Like before but also now that FSE will be part of the core the post title inside the post editor should not be placed as it is placed now because does not reflect what the real page design is (and never did), maybe in the real design the title is placed in the header.php|html file or inside an image in hero section for example or in another place, maybe adding it to the sidebar on "Post" tab under "Title" accordion? Is it a bad idea? Or inside the topbar so it will be visible.

About the name Full Site Editing

When I see the button "Update Design" inside the FSE I thought why not just called it "Design Editor" and not FSE?

Inside FSE

In "normal screen mode" I don't find the icon to open the left sidebar menu to navigate between pages and templates.
If I activate "full screen mode", open left sidebar menu and deactivate "full screen mode" the left sidebar remain open
without the possibility to close it.

I don't see like in the customizer the possibility to change theme or to modify a new theme and switch it when I'm
ready.

I don't see the option to change the "Your homepage displays" option that is in Reading Settings page.

I see that I can modify a post|page content and title inside the FSE but not the permalink (Theme -> Templates -> index.html (only)), why? This confused me at first, the content should be blocked in FSE and also in CPT wp-template{-part} editor.

It should be clear where or where not to modify content vs template|design.

Without borders around blocks it is very hard to click in the right place at first click, yes, I know there is the list view menu, but I always have to click at least two time whit that menu (open the menu and click in the right place if I'm lucky).
If the focus is in the root the list is too long and if the focus is in the template part I can't go up to the parent, I have first to click in empty part of the root and then select the element.

I see in TT1 there is a page-home.html, why this does not reflect the template hierarchy?

Presentation logic vs business logic

I think that they should be not mixed, starting from template-canvas.php that adds '<div class="wp-site-blocks">' . $content . '</div>' and also in blocks like wp:template-part, wp:query-loop, post-content, navigation etc, they add HTML wrappers.

This behavior should be delegated to the developer and not to the core, I as developer want to have the power to choose if I want to add or not HTML to a block (in this case to a file), what I see are two kind of FSE blocks, a sort of meta-block to include parts of elements (files or other blocks) and regular blocks to display content from a database, for example wp:template-part behavior should be the same as get_template_part() where you have to only include a file in a position you want to display it and do not behave like a "traditional" block where you also have an HTML wrapper element and can modify style, tagName and so on, for displaying HTML elements there are already blocks to do so, if I want to add a wrapper in a file I will inside the file itself and not in the block wp:template-part.

These are from my point of view business logic blocks that should be as abstract as possible:

  • template-part
  • navigation
  • query-loop
  • post-content
  • post-excerpt
  • post-comments
  • And all blocks that add lists

Maybe there are others that now I can't find, I need more time to get a better overview of FSE.

I apologize in advance for any grammar errors, I'm not native english.

@annezazu annezazu added [Feature] Full Site Editing [Type] Feedback Issues that relate purely to feedback on a feature that isn't necessarily actionable labels Feb 22, 2021
@overclokk
Copy link
Author

Just adding more thoughts:

In the FSE left sidebar I can't see if the template or template part is from the theme or from the CPT.
I can't delete or reset the template or template part fromt CPT inside the FSE left sidebar to the theme default.

Also for GS I can't reset the style to default without saving the page, I mean, I want to delete the GS from DB and start from scratch, I know I can reset to default but the style is always saved to DB.

With TT1 if I want to change the BG color I have to click in the only place without blocks above the header, the little space above, and then I can change the BG color, I don't see other way, maybe having a root button in the list view or in another place would be great.

@annezazu
Copy link
Contributor

Thanks so much for taking the time to write up feedback about your current experience with FSE! Much of this touches on larger questions around design and technical consideration so I've reached out to some product folks to chime in. For now, I'll try to touch on some of the feedback I can address/make connections to.

It should be clear where or where not to modify content vs template|design.

Agreed completely! This was a big finding in the first call for testing around template editing. Here's the most relevant issue: #27849

Without borders around blocks it is very hard to click in the right place at first click, yes, I know there is the list view menu, but I always have to click at least two time whit that menu (open the menu and click in the right place if I'm lucky).

Yes. I am finding this to be the case too and mentioned it here just this week as I believe both the add block and border visibility needs to be improved: #26404 (comment)

I can't delete or reset the template or template part fromt CPT inside the FSE left sidebar to the theme default

This is brought up here as well: #23421

Also for GS I can't reset the style to default without saving the page, I mean, I want to delete the GS from DB and start from scratch, I know I can reset to default but the style is always saved to DB.

I wasn't able to replicate this. Any chance you can take a quick video and upload it here? On my end, I found I could use the Site Editor and, upon making any changes to GS, I would see the option to "Reset to Default".

@aristath
Copy link
Member

aristath commented Feb 26, 2021

Thank you for your feedback @overclokk!

I tried to add some FSE blocks like post-content inside a post content and boom, my computer exploded (just kidding), maybe in some context it should not be allowed to add blocks like post-content inside the content or better it should be displayed a notice to inform that to make it works needs to be configured like a WP_Query.

See #26923

Like before but also now that FSE will be part of the core the post title inside the post editor should not be placed as it is placed now because does not reflect what the real page design is (and never did), maybe in the real design the title is placed in the header.php|html file or inside an image in hero section for example or in another place, maybe adding it to the sidebar on "Post" tab under "Title" accordion? Is it a bad idea? Or inside the topbar so it will be visible.

I think there is some confusion right now regarding the post-editor and the site-editor.

Some FSE blocks should probably not show up in the post-editor but only in the site-editor.
This is still a work in progress and we're trying to figure out a viable and future-proof method of handling these things - which is why it has still not been implemented.

I don't see like in the customizer the possibility to change theme or to modify a new theme and switch it when I'm ready.

I don't think there are any plans to implement something like that. The Customizer and FSE/Global-styles are fundamentally different concepts. The fact that something was possible in a certain way in the customizer doesn't mean that it needs to be possible in an FSE context.

I don't see the option to change the "Your homepage displays" option that is in Reading Settings page.

The option is already in your reading settings, but in an FSE content, it doesn't make a lot of sense anyway. You can customize and edit your frontpage adding whatever you want. If you want to show static content you just add that content. If you want to show your latest posts you just add a query block. Or you can do a mix of both - something that wasn't possible before.

I see in TT1 there is a page-home.html, why this does not reflect the template hierarchy?

Actually, it does. If you have a page called home it will use that template.

This behavior should be delegated to the developer and not to the core, I as developer want to have the power to choose if I want to add or not HTML to a block (in this case to a file), what I see are two kind of FSE blocks, a sort of meta-block to include parts of elements (files or other blocks) and regular blocks to display content from a database, for example wp:template-part behavior should be the same as get_template_part() where you have to only include a file in a position you want to display it and do not behave like a "traditional" block where you also have an HTML wrapper element and can modify style, tagName and so on, for displaying HTML elements there are already blocks to do so, if I want to add a wrapper in a file I will inside the file itself and not in the block wp:template-part.

The current structure is built the way it is to accommodate most scenarios and cases that we have observed from themes and what the ecosystem does in regards to theming and structure - while still maintaining the semantic value of all blocks.
If you want to change the default behavior of blocks you can always do that by using the render_block filter and changing the HTML that each block prints.

@oandregal
Copy link
Member

oandregal commented Feb 26, 2021

Also for GS I can't reset the style to default without saving the page, I mean, I want to delete the GS from DB and start from scratch, I know I can reset to default but the style is always saved to DB.

Was looking at this and don't know how to repro.

Perhaps you mean that you'd like the custom post type used to store the global styles metadata removed when the user doesn't have any styles? To that point, this is a technical limitation of how the data flow works: there needs to be a pre-existing custom post type to be able to store data in it, we can't create one from the client on-demand as far as I know. I don't see this affecting the user in any way, though.

@jameskoster
Copy link
Contributor

Like before but also now that FSE will be part of the core the post title inside the post editor should not be placed as it is placed now because does not reflect what the real page design

We have an issue that explores toggling the template in the post editor: #27847 This seems closely related to your comment on how the post title should appear in the post editor.

In "normal screen mode" I don't find the icon to open the left sidebar menu to navigate between pages and templates.
If I activate "full screen mode", open left sidebar menu and deactivate "full screen mode" the left sidebar remain open
without the possibility to close it.

This is probably worth exploring in isolation, if you have the time it would be excellent to see a dedicated issue for this.

I can't delete or reset the template or template part fromt CPT inside the FSE left sidebar to the theme default.

There is a PR for this here: #28141

@annezazu
Copy link
Contributor

I don't see the option to change the "Your homepage displays" option that is in Reading Settings page.

Just tying in this issue as well: #28341 :)

@overclokk
Copy link
Author

Thank you for your reply, I start by reading the reported issues and then I also answer the questions that are still pending.

@overclokk
Copy link
Author

You add here a lot of issue, some of theme I start to follow or I added a message, thank you all

@annezazu

I wasn't able to replicate this. Any chance you can take a quick video and upload it here? On my end, I found I
could use the Site Editor and, upon making any changes to GS, I would see the option to "Reset to Default".

@nosolosw

Was looking at this and don't know how to repro.
Perhaps you mean that you'd like the custom post type used to store the global styles metadata removed when the
user doesn't have any styles? To that point, this is a technical limitation of how the data flow works: there needs to be a pre-existing custom post type to be able to store data in it, we can't create one from the client on-demand as far as I know. I don't see this affecting the user in any way, though.

I made more test about it, what I see is when I click on "reset to default" and update design in database it is restored to {"isGlobalStylesUserThemeJSON":true} so there is no issue here, I'm fine with this behavior.

Only why CPT and not theme_mods?

@aristath

Actually, it does. If you have a page called home it will use that template.

Ok, I tested that, hierarchy is respected, at first page-home.html confused me.

The current structure is built the way it is to accommodate most scenarios and cases that we have observed from themes and what the ecosystem does in regards to theming and structure - while still maintaining the semantic value of all blocks.

Most scenarios and cases are not all the scenarios and cases and for that reason it is better to have a more
abstract system in place, how to add styles or HTML should be a choice of the theme developer and not of the core.

The blocks I mentioned are new and do not reflect what the APIs do in core.

get_template_part( $slug, $name, $args ) does only two things, include a file and pass some arguments, it does not add any HTML wrapper. https://developer.wordpress.org/reference/functions/get_template_part/
If I want to add a wrapper I can do it or outside that function or inside the file I want to include
If I do not need to add any wrapper I just let that function as is.

gutenberg_render_block_core_template_part( $attributes ) does a lot of things and in the end add an HTML wrapper:

return "<$html_tag $wrapper_attributes>" . str_replace( ']]>', ']]&gt;', $content ) . "</$html_tag>";

This is wrong, that wrapper should not be there, if I need a wrapper I would add it by myself or outside the
wp:template-part or inside the file I want to include with wp:template-part.
With that it force me to have a wrapper that I don't need and also I have to add CSS for that.

Let say I want to add a card, and user box, and a header, and other template-things, why adding wrappers to all of
them? This do not make sense to me.

This thing is used in the blocks I mentioned above and also in template-canvas.php, let the developer choose to add
wrappers if they need to, don't do it in the core and avoid mixed content.

@oandregal
Copy link
Member

Only why CPT and not theme_mods?

The infrastructure that comes with CPTs gives a few things for free that would be very useful down the road: scheduling a style change, change revisions, etc. No plans to implement these yet that I know of, though, but when/if we do, they'll be a lot easier to do for that reason.

@overclokk
Copy link
Author

@nosolosw Ok, that make sense to me

@annezazu
Copy link
Contributor

Going to close this out at this point :) Thanks for the awesome discussion and feedback around FSE. This will still be searchable on GitHub but doesn't have any additional actionable information at this point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Feedback Issues that relate purely to feedback on a feature that isn't necessarily actionable
Projects
None yet
Development

No branches or pull requests

5 participants