The page titles are different
They should be the same
This is actually because "Home" is the page title, which the theme hides by default on the front end. The text you see on the front end is the site title, which is not visible in the editor.
These issues are fixed in the FSE editor, but we should make sure the page title is hidden if it is not visible on the front end.
Check customizer option if homepage title title gets hidden and replicate in Editor
set_theme_mod( 'hide_front_page_title', true );
I initially misread the issue and only thought it's about hiding the title from SPT layout preview where we manually add it above the page blocks. Example here with the title "Team":
I don't think we are ready to hide the title from the actual editor. It's not a feature of the block editor at the moment and could bring more trouble than gains. Users won't be able to rename the page easily or change the permalink, which are features that are hidden in that area.
I suggest we can remove the title right now from our layout preview screen (matching the theme mod) to draw the template more realistic to the result on the frontend but I will rather not touch the title in editor until it becomes an officially supported feature
but I will rather not touch the title in editor until it becomes an officially supported feature
Certainly not a bad idea. I think we actually did this in dotcom FSE in order to get around this issue because it was much more obvious there. We could copy that same solution to solve this one, but there would be no way to edit the page title at that point. Since the page title isn't shown on the front end anywhere in this scenario, it might not matter that much that you can't change it.
I guess it's a matter of figuring out if the trade off is worth it.
I suggest we can remove the title right now from our layout preview screen
Already implemented here, but I'm having second thoughts about it, @marekhrabe.
The "Hide Homepage Title" theme setting in Customizer is specifically about the Homepage title and it doesn't actually apply to any other pages. When adding a new page via the SPT picker, it is never initially a Homepage and so, when created, its title is always visible in both, editor and front-end.
In that case, does that actually make sense to make the SPT page title preview depend on the theme's Homepage settings? TBH, I can't really see how that setting would be valid for SPT now.
These issues are fixed in the FSE editor
@noahtallen, could you please explain how they're fixed in the FSE?
does that actually make sense to make the SPT page title preview depend on the theme's Homepage settings
I think it does make sense if the current page is the homepage. You can edit and update the layout of your homepage after it is created.
could you please explain how they're fixed in the FSE
I think the relevant code is actually in the Varia base theme: https://github.com/Automattic/themes/blob/master/varia/inc/style-editor-wpcom.css.
.hide-homepage-title .editor-styles-wrapper .post-content__block .editor-post-title
This works because in dotcom FSE, the post title component is rendered inside of the .post-content__block
which we control. I think this same approach would work in the editor if the .hide-homepage-title
and .editor-post-title
classes exist.
You can edit and update the layout of your homepage after it is created.
Totally missed that one, thanks! Just need to add another check to determine if an edited page is actually a Homepage then!
I think this same approach would work in the editor if the .hide-homepage-title and .editor-post-title classes exist.
Ah, so you're suggesting to hide the title rather than not render it at all. That sounds like a workaround but one that could actually work reliably I think? I looked into the FSE source and found the editor-template-classes.js. If that's a good place to handle it, we could add a check there if the isFrontPage
and hideFrontPageTitle
are true
and then add the .hide-homepage-title
class to the document.body
as we Currently do in Varia
. The .editor-post-title
class seems to already be in place, so the last step would be to add the style, e.g. to the dotcom-fse/editor/styles.scss
?
Let me know if that sounds like something that would work for us. If yes, I would implement it within the https://github.com/Automattic/wp-calypso/pull/39702 as it's the same context.
Good ideas!
If that's a good place to handle it
I would actually not put it here because the dotcom-fse
files are only loaded when FSE is active on the site. In our case, we'd want that CSS to be loaded for any site.
But the FSE plugin makes sense to me. I'm not sure where would be the best place to put that code. I think SPT is most similar and is also loaded for the same themes that auto-hide the homepage? Perhaps we could create another sub-module for editor hacks :) To be fair, I think most current editor hacks actually live here: https://github.com/Automattic/wp-calypso/tree/master/apps/wpcom-block-editor
I would actually not put it here because the dotcom-fse files are only loaded when FSE is active on the site.
Ah, I've been wondering why it's not loading for me! 馃槵
But the FSE plugin makes sense to me. (...) most current editor hacks actually live here: https://github.com/Automattic/wp-calypso/tree/master/apps/wpcom-block-editor
The more I think about this, the more it looks like something that should be supported regardless of the FSE plugin presence. I'm aware that the FSE is a must-have plugin and it's always active, but if the "Hide Homepage Title" setting should also be supported without it, wouldn't it be wise to handle it somewhere else? 馃
With the above in mind, I'd suggest to:
isFrontPage
and hideFrontPageTitle
prop to the wpcomGutenberg
global object (as a single source of truth),hide-front-page-title.js + css
in wpcom-block-editor
, andwpcomGutenberg
instead of redefining them in the starterPageTemplates
config.What do you think?
but if the "Hide Homepage Title" setting should also be supported without it, wouldn't it be wise to handle it somewhere else?
Yeah, I definitely understand the concern. However, if we're thinking about the best place to put them, wouldn't this make most sense at the theme level since the theme is the entity ultimately adding support for the feature? I'm not sure I see any improvement using wpcom-block-editor vs the FSE plugin itself.
Anyways, other than putting the CSS in the theme, I think your idea makes at least as much sense as the FSE plugin if not more. I also like that we would define a single source of truth there.
Current status:
This feature needs to be partially fixed in FSE and partially in (some) themes (p1583252031480800-slack-ajax).
Why?
Varia, TwentyTwenty and a few other themes all register the hide_front_page_title
mod which can be accessed from Customizer. That setting is correctly reflected on the front-end, but it's not in the Editor, which is the issue here. In the case of the Varia theme, there's a function that adds a hide-homepage-title
class to the body element. There's also a partial with editor-specific styles added, that should hide the title when that class is present:
.hide-homepage-title .editor-styles-wrapper .post-content__block .editor-post-title {
display: none;
}
Unfortunately, those styles work only for dotcom-fse
, where we add the necessary .post-content__block
class to the BlockListBlock
component. That part needs to be fixed in FSE - we need to figure out a way to add this class. (Unless we feel strong enough about updating Varia theme).
Regarding the stuff that needs to be fixed in themes:
As mentioned, a few themes that support the hide_front_page_title
mod (e.g. TwentyTwenty) don't add the hide-homepage-title
class to the Editor body, as Varia does. Because of that, once we have fixed the FSE part I mentioned above, we can copypaste Varia implementation to those themes which would make this functionality implementation consistent.
@noahtallen, @marekhrabe how does that sound to you? Did I miss something there?
Sounds about right to me!
Because of that, once we have fixed the FSE part I mentioned above, we can copypaste Varia implementation to those themes
Honestly, I think we could also update the .css implementation such that we don't have to target the .post-content__block
class.... since we really only need to add that class to non-dotcom-fse flows as a hack so that we don't need to update all the Varia child themes :p
Created a follow-up issue in themes
: https://github.com/Automattic/themes/issues/1846
cc @ianstewart