-
Notifications
You must be signed in to change notification settings - Fork 2k
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
FSE: Add Current layout to starter page templates page layout picker when editing a homepage #43980
FSE: Add Current layout to starter page templates page layout picker when editing a homepage #43980
Conversation
This PR does not affect the size of JS and CSS bundles shipped to the user's browser. Generated by performance advisor bot at iscalypsofastyet.com. |
{ this.props.isFrontPage && | ||
this.renderTemplatesList( | ||
currentTemplate, | ||
__( 'Current', 'full-site-editing' ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ℹ️ String reuse speeds up translation and improves consistency. The following string might make a good alternative and has already been translated 100 times:
translate( 'Current' )
ES Score: 10
Caution: This PR affects files in the FSE Plugin on WordPress.com D46093-code has been created so you can easily test it on your sandbox. See this FieldGuide page about developing in the FSE Plugin for more info: PCYsg-ly5-p2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated this to:
- Show the dynamic preview for the 'current' layout tab button.
- Skip the 'current' section if there are no blocks on the page. (empty/new page scenario)
Unfortunately, In implementing the preview I have also introduced a bug/error that I am having a hard time tracking down. Sometimes it happens right when we open the layout picker, but it is mostly reproducible when we have the 'current' tab selected and press "Tab" to move to the next in an a11y style flow. The editor breaks and there is an error in the console about using getBoundingClientRect
of undefined:
I have not yet been able to pinpoint this or work around it.
On another note, if we do get this working in an acceptable manner I wonder if we want this available for all pages, not just the homepage? 🤔
<Disabled> | ||
<BlockIframePreview blocks={ blocks } viewportWidth={ 960 } /> | ||
</Disabled> | ||
<BlockIframePreview blocks={ blocks } viewportWidth={ 960 } /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Disabled component here causes 2 problems:
- It styles push the preview below/outside the tab window.
- It has zero height, which in turn causes the scaling to give the preview 0 height in:
Line 119 in a983b61
const height = parentNode.offsetHeight / scale;
Removing this allows the preview to be viewable. Similarly, there is already a Disabled component further down in the chain in:
Line 25 in a983b61
<Disabled key={ recomputeBlockListKey }> |
So Im not sure if its necessary here. If it is, we may need to work-around the default component styles and scaling implementation to account for out purposes here.
I am finding the noted getBoundingClientRect
error both with and without the Disabled component, it seems to be specific to using the BlockIframePreview here. 🤔
Nice work on this @Addison-Stavlo — I've done a small update to move the blocks for the I looked into the So, it looks like we might be okay without having to add back in |
Oh, and yes, I agree, if we get this working acceptably, I think it’d be great to include the current layout option for when a page already exists and someone is looking to swap layouts. Another thought re: the getBoundingClientRect error being thrown while tabbing within a preview — it’s almost like it’s trying to open the toolbar pop up for each block or something like that? More broadly it feels like this approach to previews has a lot more going on than we might need to a non-interactive preview, but I see it’s very similar to the block pattern previews in Gutenberg. Just a bit of food for thought if we get the time to rethink these previews in the future! |
Very nice, the Its odd how that doesn't solve the same issue for the large preview though 🤔 although thats less of a concern for this PR I think. (investigate/created #44038 regarding that) |
Testing this some more it seems to work well! Especially considering that the error we have encountered seems to be present on master and is a recent problem stemming from core Gutenberg after 8.3. I removed the check for |
@@ -413,6 +438,11 @@ class PageTemplateModal extends Component { | |||
) : ( | |||
<> | |||
<form className="page-template-modal__form"> | |||
{ this.renderTemplatesList( | |||
currentTemplate, | |||
__( 'Current', 'full-site-editing' ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ℹ️ String reuse speeds up translation and improves consistency. The following string might make a good alternative and has already been translated 100 times:
translate( 'Current' )
ES Score: 10
Hi Andy and Addison,
I implemented this one, although I'm not entirely sure about the validity of the criteria I used to tell if the page is new. I took inspiration from this line. And it seems to work as expected. As for
This seems to be already done. I changed the text color to red and the button reflected that alright: What was not done though is that the big preview isn't showing the "current". It didn't show "Current". So I changed Thanks! |
return DEFAULT_HOMEPAGE_TEMPLATE; | ||
} | ||
return blankTemplate; | ||
// if the page isn't new, select "Current" as the default template |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ℹ️ String reuse speeds up translation and improves consistency. The following string might make a good alternative and has already been translated 100 times:
translate( 'Current' )
ES Score: 10
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for jumping in on this one @alshakero!
The current option shouldn't display if this is a brand-new page
I implemented this one, although I'm not entirely sure about the validity of the criteria I used to tell if the page is new. I took inspiration from this line. And it seems to work as expected.
Switch on dynamic previews for just the Current button, and see if that works instead of having a screenshot or empty square for this button
This seems to be already done.
My apologies as I forgot to update the original comment to reflect the state of these TODOs. We did turn the dynamic preview on for that in one of the previous commits. I also implemented a check to skip this 'current' option for blank pages (should probably be good enough for the new-page case? see below).
// Skip rendering current preview if there is no page content. | ||
if ( isCurrentPreview && ! blocksByTemplateSlug.current?.length ) { | ||
return null; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what I had added as the condition to hide the 'Current' section on a new page. I was assuming that a new page would always have no content, or that if it did have content we wouldn't want to hide 'Current' ? 🤔 Similarly if it is not a new page and has no content, we don't need the 'current' section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these are valid assumptions. We probably don't need "Current" for any empty page. New or not.
880d697
to
1ac7213
Compare
No worries. I probably should have paid more attention to the convo here. I reversed my redundant check and only kept the change that renders the "current" contents in the preview iframe. I tested and all works as intended. |
Going to rebase. |
1ac7213
to
ac2eeb3
Compare
ac2eeb3
to
6e70f45
Compare
Rebased again as there was an issue in an unrelated sub-plugin that were crashing wp-admin. 🙂 |
This looked good to me and tested fine...
EDIT:
@andrewserong, @Addison-Stavlo: AFAICS this has already been sorted out in 7019cbe. |
Rebased after #44501 |
You couldn't just
lol, yeah it feels awkward for me to self-approve as well since I worked on it some previously. ✅ Consider your changes in c3df4b0 approved via this comment if it makes approving the rest feel less awkward. 😁
I can't think of anything beyond what Andrew just said above. Thanks for picking this up! |
apps/editing-toolkit/editing-toolkit-plugin/starter-page-templates/page-template-modal/index.js
Show resolved
Hide resolved
Other than a relatively minor doubt, I'm seeing two visual glitches:
This is caused by the One way we could fix this is to replace <div class="wp-block editor-post-title editor-post-title__block">
<div class="editor-post-title__input">{ title }</div>
</div> It is slightly fragile, but we might want to assume that the
It's likely caused by Given the flash is barely noticeable, and the fix could be complicated, we should probably rather tackle it in a follow up. |
I think that seems reasonable for the time being? the DOM manipulation is fragile as-is, I don't think this is going to make it much more fragile in comparison? It will be great when we can get rid of the DOM manipulation all together.
That sounds fair as well. Although are there circumstances where this would take much longer and be very noticeable? 🤔 |
c3df4b0
to
9673db5
Compare
It's definitely noticeable on slow connections. I've also given more thought about replacing Given that this PR works, and the 2 updates are normal (the title cut off in some cases) or low (the FOUC) priority, I'd say let's merge this and try to tackle the updates before the next Editing Toolkit release. |
That sounds fair. Other possible ideas for the title issue - Either remove it from from the preview when it is showing 'current' or maybe just hardcode it as 'Current Layout'. When you select other layouts to look at previews, the title it shows ends up being title of the preview and not the actual post title anyways? 🤔 |
The current layout seems to show up for me, I wonder what the difference here is 🤔 . Either way, if clearing the cache fixes it on your end that seems reasonable to me.
Yeah, that seems fair. Injecting the style like that should fix it without introducing any of the negatives @Copons was mentioning above. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested with the most recent changes and it works well on my end. The current layout is displayed and the title issue is resolved.
…editing a homepage
…yTemplateSlugs is memoized
6ad9c0f
to
bdbfa60
Compare
Changes proposed in this Pull Request
Still to do
Screenshot
Testing instructions
apps/full-site-editing
directory and runyarn wp-env start
apps/full-site-editing
directory and runyarn dev
or if you want to sync to your sandbox, runyarn dev --sync
)?new-homepage
query param so that you open up the page layout selector for a homepage, where you should then see the Current layout option. E.g. for my own local test site, the URL ishttp://localhost:4013/wp-admin/post.php?post=2&action=edit&new-homepage
Related to: #43933