Skip to content
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

Move duplicateTemplatePart action to the @wordpress/fields package #65390

Open
wants to merge 50 commits into
base: trunk
Choose a base branch
from

Conversation

gigitux
Copy link
Contributor

@gigitux gigitux commented Sep 17, 2024

What?

This PR migrates the duplicateTemplatePart action to the @wordpress/fields package. The primary issue with this action is its dependency on the CreateTemplatePartModalContents component, which resides in the @wordpress/editor package. Due to this, it can't be directly used within the @wordpress/fields package.

For the purpose of the @wordpress/fields package work, I have temporarily moved the component to this package. However, I'm not certain if this is the best long-term solution. Ideally, this component (and potentially others) should reside in a dedicated package, such as @wordpress/template, which would be more appropriate for components related to template and template-parts. A similar package for the patterns already exists: https://github.com/WordPress/gutenberg/blob/d6fcf4aea4aff17cf0910862bf10090e20ba2ab0/packages/patterns/src

Please review and provide feedback on whether this approach is suitable or if there are alternative recommendations for handling these dependencies. Thanks! 🙏 cc @youknowriad @oandregal

Testing Instructions

Ensure that Custom Dataviews is enabled.

  1. Visit the Site Editor.
  2. Visit the patterns view.
  3. Click on header
  4. Duplicate a header template part.
  5. Ensure that the duplicated template part is created.

Testing Instructions for Keyboard

Screenshots or screencast

@@ -152,10 +208,14 @@ export function CreateTemplatePartModalContents( {
label={ __( 'Area' ) }
className="editor-create-template-part-modal__area-radio-group"
Copy link
Contributor Author

@gigitux gigitux Sep 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I update these classes even if it is a temporary solution?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think we should update them ideally fields instead of editor basically.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated it with 199c313

@gigitux gigitux marked this pull request as ready for review October 24, 2024 08:04
Copy link

github-actions bot commented Oct 24, 2024

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: gigitux <[email protected]>
Co-authored-by: youknowriad <[email protected]>
Co-authored-by: oandregal <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@@ -13,7 +13,7 @@ import { symbolFilled } from '@wordpress/icons';
/**
* Internal dependencies
*/
import CreateTemplatePartModal from '../create-template-part-modal';
import { CreateTemplatePartModal } from '@wordpress/fields';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree this is weird, but also not sure what's the best place for these wp-core-data aware components. That said I can live with it being in fields for now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should add a comment explaining the choice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With 47da440 I added some documentation.

plugin: 'plugin',
};

export const TEMPLATE_PART_AREA_DEFAULT_CATEGORY = 'uncategorized';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I hate these constants file and would rather mostly remove them (especially since most of these types are "typed" now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed with 64423cf

[]
);

const defaultTemplatePartAreas = getDefaultTemplatePartAreas( settings );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I think this is the wrong solution to retrieving the default template areas. There might not be a rendered block-editor when using the fields, so I don't think a dependency to "block-editor" is the right approach.

The main issue here is that defaultTemplateTypes and defaultTemplatePartAreas are passed from the server to the client through the editor settings initialization. I think this is the wrong approach. The right approach would be to move these to getEntityRecord( 'root', '__unstableBase' ) endpoint and add them in the server to this endpoint. I believe we did things like that in the past for things like site_icon_url ... Do you think this is something we can try in its own PR. I'm a bit concerned that the current field won't work as expected in all contexts.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think this is something we can try in its own PR. I'm a bit concerned that the current field won't work as expected in all contexts.

I'm happy to work on it with a dedicated PR! 💪

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created #66459. Let me know if you agree with the approach that I took!

@gigitux
Copy link
Contributor Author

gigitux commented Nov 26, 2024

This PR is ready to be reviewed! cc @oandregal @youknowriad @louwie17

- _props.closeModal_ `Function`: - Function to close the modal.
- _props.onCreate_ `Function`: - Function to call when the template part is successfully created.
- _props.onError_ `[Function]`: - Function to call when there is an error creating the template part.
- _props.defaultTitle_ `[string]`: - The default title for the template part.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need both components to be exposed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed with 4583cf8

@@ -42,6 +66,14 @@ Undocumented declaration.

Undocumented declaration.

### duplicateTemplatePart
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this to be a public API here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we using it elsewhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are using only here. I'm happy to make a “private” API.

@@ -35,6 +35,7 @@
"@babel/runtime": "7.25.7",
"@wordpress/api-fetch": "*",
"@wordpress/blob": "*",
"@wordpress/block-editor": "*",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed with e0f518e.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] DataViews /packages/dataviews [Type] Experimental Experimental feature or API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants