Data Views: Add action for pages to set site homepage #65426
Conversation
creativecoder
added
[Feature] Site Editor
|
I thought it was interesting how you handled non-published pages but I noticed an issue; if you set a scheduled page as the homepage it works, but the page remains scheduled resulting in a 404 on the frontend. It might make sense to restrict the action to
The Snackbar copy could use some refinement. Maybe just "Homepage updated"? Testing the flow with reading settings set to display latest posts caused the editor to crash: 
Relating to this, I noticed an oversight in the original design; when setting a static homepage and offering the user the option to set a 
|
creativecoder
force-pushed
the
try/site-editor-homepage-settings
branch
from
ab1c828
to
0f3a986
Compare
|
Size Change: +850 B (+0.05%) Total Size: 1.82 MB
ℹ️ View Unchanged
|
|
@creativecoder is this one ready for review? :) |
|
@jameskoster A few things that still need doing
I'm not sure when I'll be able to get back to this, so if anyone wants to pick this up--feel free! |
|
Thanks @creativecoder! I'm going to have a go at picking this up. I'll start by addressing the items you listed above, and then I'll mark as ready for review. |
| @@ -1,5 +1,5 @@ | |||
| type PostStatus = | |||
| | 'published' | |||
There was a problem hiding this comment.
I just realized we had this in the editor that we also have in the wordpress/fields package (see). It sounds to me the fields package should be the central package for that kind of information about fields and posts. Not for this PR, just sharing a potential follow-up to clean things up later.
| showOnFront: siteSettings?.show_on_front, | ||
| }; | ||
| } ); | ||
| const currentHomePageTitle = getItemTitle( currentHomePage as Page ); |
There was a problem hiding this comment.
This line is failing due to currentHomePage being undefined (which results in item.title checks within this function to raise an error). This happens when the homepage is set to display the latest posts.
Looking at how other code works (in the site editor, for example), to find a homepage candidate we need to check that
show_on_frontispagepage_on_frontis not 0
Is that your understanding as well?
There was a problem hiding this comment.
Reading now the code below, it already considers the two situations (front is page or posts), so perhaps we can just move this line to where it's needed (within the sprintf).
There was a problem hiding this comment.
Thanks, good spot! I've moved this line to within the sprint, here: https://github.com/WordPress/gutenberg/pull/65426/files#diff-4320028e1b1fe30d612641c6c8fe5eab313d695872751b95faeb3d00ba490c91R125. I think this is working as I'm not seeing this error when the homepage is set to latest posts.
|
I've ran into the following: if you select one page, then the "set as homepage" action doesn't refresh the preview (it stays at the selected page). Steps:
Screen.Recording.2024-11-14.at.09.37.55.mov |
I like how simple this is for setting the homepage. I wonder how can we incorporate "setting my homepage to latest posts". Perhaps it can be a different action that is only available in the homepage page? I don't think it should be done in this PR necessarily, but it'd be nice to have an idea about potential direction here. |
|
What do you think about keeping this action out of the "fields" package for now to be able to ship it (and use a React hook to retrieve the action). That way we can avoid |
| @@ -113,6 +122,9 @@ export const registerPostTypeActions = | |||
| ? duplicatePattern | |||
| : undefined, | |||
| postTypeConfig.supports?.title ? renamePost : undefined, | |||
| canManageOptions && postTypeConfig.slug === 'page' | |||
There was a problem hiding this comment.
I see this logic as part of the editor package, so I presumed both the site editor & post editor would have the action. However, I've noticed the post editor doesn't:
| Site editor | Posts editor |
|---|---|
 |
 |
It turns out to be that the canManageOptions check is undefined for the post editor. Would you know why is that?
Checked a few things and:
- the
canCreatecheck works fine in the post editor - the
canManageOptionsis actually resolved when using the post editor to edit apost(not apage)
🤔
| @@ -22,17 +22,39 @@ const { Menu, kebabCase } = unlock( componentsPrivateApis ); | |||
|
|
|||
| export default function PostActions( { postType, postId, onActionPerformed } ) { | |||
| const [ isActionsMenuOpen, setIsActionsMenuOpen ] = useState( false ); | |||
| const { item, permissions } = useSelect( | |||
| const { item, permissions, additionalContext } = useSelect( | |||
There was a problem hiding this comment.
I just learned that, in trunk, we are already augmenting the data with extra info: permissions.
Even it's obscured by the fact that in the editors is done via direct call to getEntityRecordPermissions while in site editor pages is done via the useEntityRecordsWithPermissions utility.
It was introduced here. Before that change, at registration time, we'd wrap the isEligible function so that we had access to the registry. The advantage of doing that at registration time was that every consumer didn't have to care about augmenting the data. Also, we already have eligibility logic for the actions at registration time (see private-actions): though that logic doesn't depend on the item, while the permissions or the homepage info does.
@youknowriad could you share more of the rationale for that change? I dug a bit but I didn't find why we preferred not to do that.
There was a problem hiding this comment.
I've finalized the review: shared some things that don't work and others that could be improved.
The important question we have to address is: how isEligible can access data that is global (not part of the item)? The approach in this PR is augmenting the item like we already do with permissions. So, for me, it'd be fine to merge the PR as it is.
I agree this issue is important to solve, just not a blocker for landing this given there's already precedent for the approach.
Looked a bit into the conversation but I don't have a good answer yet. Actions are a bit special because they are not tied to DataViews, it's an API that should work for both DataViews and the Editor, and I need to dig a bit more into how the editor uses them.
What's the precedent? |
PostWithPermissions (see comment). |
|
Ah I see, I think post permissions is a bit different though because these permissions are different per item, so it actually make sense to be part of the "item" object. In that case we're saying the DataForm and DataViews work only with "full items" (items with permissions). This one is a bit different and we're saying that DataForm and DataViews (actions) work only when you have the random provided context here. We risk also making this context available to actions registered via the APIs and we'll remove it later. While I'm not entirely opposed to shipping this PR as is, I feel like it seems better to consider keeping this action outside the "fields" package. |
Yeah, I see your angle. I agree that we need a better mechanism, we cannot augment the item with every piece of global data we need.
That'd work for me as well. We have some actions defined in the edit-site package. |
|
Thanks for the discussion here 🙏
This sounds like a good path forward, I'll work on that next. |
| return decodeEntities( item.title.raw ); | ||
| } | ||
| return ''; | ||
| } |
There was a problem hiding this comment.
I needed to duplicate the getItemTitle function to avoid importing it from the fields package into edit-site.
Yes, I think this could be handled soon after in a follow-up PR. There's also a separate issue for it here: #63667.
I think this is because the action is being called on a page that isn't being previewed. Should selecting an action on a page that isn't the selected/previewed page cause the preview to update to the item the action has been called on? I think I've addressed most of the feedback here, thank you again! After moving the action to edit-site, I'm not sure how best to add the action to the post editor in the post-actions component. I'm not able to import the new action as it lives in a separate package. Would the action need to be duplicated? |
What?
Adds an action to set the home page from the site editor.
Fixes #63666
Why?
Currently there is no way to change the home setting (Settings > Reading) from the site editor. This PR adds a way to do that.
How?
Adds a dataview action for pages to set the page as the site homepage that can be triggered from the pages data view.
Testing Instructions
Screenshots or screencast