-
Notifications
You must be signed in to change notification settings - Fork 4.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
Site editor - try redirecting to homepage before the react render #37248
Conversation
const { postType } = params; | ||
return ( | ||
! getIsListPage( params ) && | ||
! [ 'post', 'page', 'wp_template', 'wp_template_part' ].includes( |
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 really get why the site editor is limited to these post types 🤔
(This replicates the else
case of the effect where showHomepage
was previously called in URLQueryController
)
Size Change: -58 B (0%) Total Size: 1.13 MB
ℹ️ View Unchanged
|
|
||
export default function HomepageRedirect() { | ||
const params = useSelect( | ||
( select ) => select( editSiteStore ).getHomepageParams(), |
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 an awesome improvement!
I'm wondering though, if we could select it upfront before rendering the React app like you mentioned. We can use resolveSelect
and await for the promise to resolve before rendering the app. As long as the request is properly preloaded, I think the promise should resolve in just a few ticks. And then we won't need the loading state either. We still need this selector in React though for client side navigations.
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.
Yeah, I figured this should be possible, but I needed a bit more time. I managed to get it working with the latest commit though.
I went with using apiFetch
for most of the api calls, as a resolver/selector combo feels unnecessarily complicated.
What do you think? It could probably use a bit of refining and error handling at the moment, and the preloading is still not working for wp/v2/settings
for some reason.
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.
LGTM 👍 ! This feels like the right approach, at least until #36873 😜 .
export default function EditSiteApp( { reboot } ) { | ||
return ( | ||
<SlotFillProvider> | ||
<UnsavedChangesWarning /> | ||
|
||
<Routes> | ||
{ ( { params } ) => { | ||
if ( getNeedsHomepageRedirect( params ) ) { | ||
return <HomepageRedirect />; |
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 we should only render it in /editor/index.js
? Since that we won't need to redirect if we're already on the list page.
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.
True, though rendering it here makes it easier to bypass all the react hooks in the Editor
component.
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 no longer an issue with the latest commit, as there's no component now 😄
const { | ||
show_on_front: showOnFront, | ||
page_on_front: frontpageId, | ||
} = siteSettings; | ||
|
||
// If the user has set a page as the homepage, use those details. | ||
if ( showOnFront === 'page' ) { | ||
return { | ||
postType: 'page', | ||
postId: frontpageId, | ||
}; | ||
} |
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.
Most of this code is replicating showHomepage
, but I wasn't sure how to test this as there's no customizer where this setting can be changed. Is it still possible to configure a homepage in this way?
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 you can change some of these via Settings -> Reading -> Your homepage displays.
@ockham, do you think we can use |
76d8810
to
7cdd4be
Compare
I've rebased this. What do you think @kevin940726 and @Mamaduka, is it worth getting this in? |
Apologies, I've seen your ping only now. |
More like to load the current page context in Site Editor via editor settings. I did a little more testing today, and it should work, but any help is appreciated 🙇 |
This seems to work-ish (patch against diff --git a/src/wp-admin/menu.php b/src/wp-admin/menu.php
index 5d550fb55d..b31409b434 100644
--- a/src/wp-admin/menu.php
+++ b/src/wp-admin/menu.php
@@ -203,6 +203,8 @@ if ( ! is_multisite() && current_user_can( 'update_themes' ) ) {
$submenu['themes.php'][5] = array( sprintf( __( 'Themes %s' ), $count ), $appearance_cap, 'themes.php' );
if ( wp_is_block_theme() ) {
+ $home_template = resolve_block_template( 'home', array(), '' );
+
$submenu['themes.php'][6] = array(
sprintf(
/* translators: %s: "beta" label */
@@ -210,7 +212,13 @@ if ( wp_is_block_theme() ) {
'<span class="awaiting-mod">' . __( 'beta' ) . '</span>'
),
'edit_theme_options',
- 'site-editor.php',
+ add_query_arg(
+ array(
+ 'postType' => 'wp_template',
+ 'postId' => $home_template->id
+ ),
+ 'site-editor.php'
+ ),
);
}
Needs a bit more work though since it doesn't quite reflect the template hierarchy yet. (Arguably, the extra logic should be absorbed into |
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 looks like a great improvement to land 👍
I will swap a few things once I've server-side resolves ready for #36873.
Thanks @Mamaduka! |
Cherry-picked for 5.9.1. |
…7248) * Replace showHomepage with a selector and dedicate redirect component * Remove show homepage * Remove component based redirect, instead use an async function prior to rendering app * Use a default export * Pass siteUrl in as a param
Description
Related #36873
After #36488, the way routing works in the site editor has changed significantly.
The store state is now mostly derived from the query parameters in the URL. Previously it was the other way around where a change to the store state caused the
URLQueryController
component to update the URL.The
showHomepage
action is an exception though. This is the action that's triggered when the site editor is visited with nopostType
andpostId
query params.This PR removes that action in favour of a handling the updating the location to the homepage when the application is initialized. The idea being that it's good for the application to have the right state before anything else happens. It should mean there are fewer chances of bugs like the redirect loop one that briefly happened in #36488, since everything the app does is derived from having the right
postType
andpostId
params at the start.A caveat is that I'm not all that familiar with this code, so it needs some critique! There might be some edge cases I'm missing.
How has this been tested?
Types of changes
Code quality
Checklist:
*.native.js
files for terms that need renaming or removal).