-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Edit Site: Add template loading. #19081
Conversation
settings.templateId | ||
), | ||
[] | ||
); |
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.
just noting that the logic in this PR is already available in editPost, we can tell it to just load the template directly. so for now, these packages are still equivalent.
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.
They are very different.
This doesn't load @wordpress/editor
and all of its unnecessary-for-this-context logic.
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.
Ultimately, it might have to load the editor package because there's a lot of useful components there. Save buttons, Editing Post Title (template title)...
I think you're right when you say, they'll be different it's just not there yet.
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 package, yes, but not the provider and/or data flow.
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 package, yes, but not the provider and/or data flow.
0abc8dd
to
9590317
Compare
981c3ec
to
fa7a8cb
Compare
042999d
to
2e171f9
Compare
2e171f9
to
f52a2f3
Compare
create_auto_draft_for_template_part_block( $block ); | ||
} | ||
} | ||
$_wp_current_template_id = $current_template_post->ID; |
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.
Why do we need to change the template resolution code in this PR?
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.
Because we need the current template ID saved, and to create template part auto drafts for custom saved templates as well as file ones.
import { useSelect } from '@wordpress/data'; | ||
import { Button } from '@wordpress/components'; | ||
import { __ } from '@wordpress/i18n'; | ||
import { EntitiesSavedStates } from '@wordpress/editor'; |
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.
It seems like we're importing the editor package, just to use this component. What does this component do? I'm wondering whether it belongs to the editor package.
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.
It's the entities saving modal. Maybe it belongs in core-data
?
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.
It's the entities saving modal
What does it do exactly?
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.
Isn't it the modal that lists entities with unsaved changes and lets the user choose if they want to update them all at once?
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.
Isn't it the modal that lists entities with unsaved changes and lets the user choose if they want to update them all at once?
Yes
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.
Interesting, I guess@editor
is the right place though but it makes me think we can reuse more than that from the Editor package (save buttons....) I also thought the components from "editor" had a dependency on EditorProvider. I guess this one is a bit different?
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.
but it makes me think we can reuse more than that from the Editor package (save buttons....)
Not without refactoring them.
I also thought the components from "editor" had a dependency on EditorProvider. I guess this one is a bit different?
Yes
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.
Thinking more here, I feel this component might be misplaced. We could be tempted to update it tomorrow to use the Editor store somehow to enable advanced flows in the editor screen and this will break the Edit Site screen without notice since it's not directly dependent on the editor store aka EditorProvider.
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.
Can we move it to core-data
?
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.
Maybe yes, I don't mind if it's done in a separate PR though to think it properly.
f52a2f3
to
7f8488c
Compare
Trying to test this, something I don't understand, why I get "no template found" when I enable the demo templates? |
In the front-end? Does the same happen in |
// Get root template by trigerring `./template-loader.php`'s logic. | ||
get_front_page_template(); | ||
get_index_template(); | ||
apply_filters( 'template_include', 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.
What is this line about? Should we comment?
I would have expected something like
$template_id = get_front_page_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.
We need to run the filters so that the template-loader
code runs.
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.
How does this prevent us from having a dedicated function that returns the 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.
The way we hijack the template hierarchy is by filtering the template getter functions to store the template hierarchy in a global and then filtering template_include
to return the template canvas with the found block template. There is no straightforward way to "return" the IDs from there.
This code is doing the same thing the front-end renderer does to set all those things in motion, but instead of echoing the template canvas at the end, it just uses the set globals to get the IDs it needs.
@@ -39,13 +41,32 @@ export default function BlockEditor( { settings: _settings } ) { | |||
}, | |||
}; | |||
}, [ canUserCreateMedia, _settings ] ); | |||
const [ blocks, setBlocks ] = useState( [] ); | |||
const [ content, _setContent ] = useEntityProp( |
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.
Why underscore?
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.
To avoid shadowing.
I'm replacing this with useEntityBlockEditor
in the follow-up PR. Can we ignore it for now?
); | ||
const setContent = useCallback( ( nextBlocks ) => { | ||
setBlocks( nextBlocks ); | ||
_setContent( serialize( nextBlocks ) ); |
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.
Do we need to set content (run serialization) on every change? Can't we do something like the editor (use a function edit)
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'm replacing this with useEntityBlockEditor
in the follow-up PR. Can we ignore it for now?
export default function SaveButton() { | ||
const [ , setStatus ] = useEntityProp( 'postType', 'wp_template', 'status' ); | ||
// Publish template if not done yet. | ||
useEffect( () => setStatus( 'publish' ), [] ); |
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.
Why set the status as soon as we render? It's not clear? should this be done on submit?
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.
It was more natural to write this way and we'll rarely have non-published templates.
We can look at extending EntitiesSavedStates
to support additional callbacks.
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.
For me, this is an error. Someone will call our selectors to check the status for this entity and he'll get "published".
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.
Only for the edits selectors.
<EntitiesSavedStates isOpen={ isOpen } onRequestClose={ close } /> | ||
</> | ||
); | ||
} |
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 don't like that EntitiesSavedStates
handle the saving and that this component retrivees the status. It feels like related concerns are separate and most importantly in two separate packages. Not sure how to improve the situation though.
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.
Maybe EntitiesSavedStates
should render the button?
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.
Or what do you think of this API?
export default function SaveButton() {
return (
<EntitiesSavedStates>
{ ( { isDirty, isSaving, open } ) => {
const disabled = ! isDirty || isSaving;
return (
<Button
isPrimary
aria-disabled={ disabled }
disabled={ disabled }
isBusy={ isSaving }
onClick={ disabled ? undefined : open }
>
{ __( 'Update Design' ) }
</Button>
);
} }
</EntitiesSavedStates>
);
}
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.
It does seem reasonable but I know we've been talking about rethinking the saving flow (pre/post publish...) regarding FSE so it could have an impact on the API. Maybe we can start as it is right now but not push too far this direction api wise until we're certain of the flows.
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.
To be fair, code-wise I'm not totally satisfied with this PR.
- I don't like the usage of globals to retrieve the template
- I don't like the dependency to the editor package for just a component.
- The saving component is a bit convoluted.
That said, I'm all for follow-up PRs to improve the situation (If we can solve the first one in this PR, that would be cool though).
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 don't like the usage of globals to retrieve the template
I don't like the dependency to the editor package for just a component.
The saving component is a bit convoluted.
I proposed an alternative, but if I read this correctly:
You are suggesting we wait until we rethink the whole pre/post-publish flow, which I think is reasonable.
Follows #19054
Description
This PR continues the
edit-site
work by loading the front page template into the block editor.How has this been tested?
It was verified that the site editor now loads the front page template dynamically.
Screenshots
Types of Changes
New Feature: The site editor now loads the front page template.
Checklist: