Data View - Page view: Add slug field control

[gigitux]

What?

Part of #64519

Screen.Capture.on.2024-09-10.at.12-42-17.mp4

This PR adds the slug field control to the Page view. Most of the logic is copied from:

• getPermalinkParts: https://github.com/WordPress/gutenberg/blob/5682b928356f624f6ed820d066689423d08d5d88/packages/editor/src/store/selectors.js/#L994-L1016
• isPermalinkEditable: https://github.com/WordPress/gutenberg/blob/5682b928356f624f6ed820d066689423d08d5d88/packages/editor/src/store/selectors.js/#L937-L944

Currently, these two functions are public selectors and rely on the editor state, so we can't refactor those. I think that for now, we can keep this duplicate code and when the post editor sidebar will be powered by the dataview, we can think to refactor those, but I'm open to feedback on this.

Similar to #64496, this code could be moved to the @wordpress/core-fields-control package if we agree to create it.

Validation

There is an edge-case that I think that we should take care, but I will wait for your feedback before to proceed. When the input is empty, the save button is clickable:

This isn’t ideal because a page/post should always have a slug set. Currently, if the input is empty, the original slug is restored on the onBlur event, which is not the best UX.

How?

Testing Instructions

Ensure that Quick Edit in DataViews and Quick Edit in DataViews are enabled.

1. Visit the Site Editor.
2. Click on pages.
3. Toggle to the table view.
4. Click on the settings.
5. Click on details panel icon.
6. Ensure that the link field is visible
7. Click on it.
8. Update the slug.
9. Save.
10. Ensure that the page is visible to the new link.
11. Visit /wp-admin/options-permalink.php.
12. Select plain setting.
13. Save it.
14. Repeat 1-7 steps.
15. Ensure that you can't update the slug.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core.
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[jameskoster]

There is an edge-case that I think that we should take care, but I will wait for your feedback before to proceed. When the input is empty, the save button is clickable:

This is a tricky one, and technically an existing issue (see video below) so perhaps not one we have to fix here?

slug.mp4

Some validation might help; maybe the field should error when empty, and revert to the current value on blur? The Save button would be disabled when the field is empty. Some validation to avoid duplicate slugs might be handy as well.

---

We also need to think about the conditions in which the Link field is shown in the quick-edit panel. In the vast majority of cases it's not possible to apply the same slug to multiple items, so maybe we just hide it for now?

[gigitux]

This is a tricky one, and technically an existing issue (see video below) so perhaps not one we have to fix here?

Yeah, this is something that I noticed too.

Some validation might help; maybe the field should error when empty, and revert to the current value on blur? The Save button would be disabled when the field is empty.

I'm fine following this approach. I'm going to try to implement it!

Some validation to avoid duplicate slugs might be handy as well.

Yeah good point. I would see this kind of validation on the backend side when the user clicks save. For now, I would skip this point because it impacts some work not specifically related to the scope of this project.

We also need to think about the conditions in which the Link field is shown in the quick-edit panel. In the vast majority of cases it's not possible to apply the same slug to multiple items, so maybe we just hide it for now?

True! Let's hide it!

Thanks for your precious feedback, @jameskoster! 🙇

[oandregal]

This works because our APIs are already extensible. However, there's an alternative that @joshuatf mentioned somewhere. Instead of doing:

{
  id: 'slug',
  Edit: /* custom slug Edit */,
  render: /* custom slug render */,
  isValid: /* custom slug isValid */,
  // etc.
}

we can do something along these lines:

registerFieldType( 'core/slug', FieldSlug );

const fields = [
  {
    id: 'slug',
    type: 'core/slug',
  }
];

This has a few advantages:

• It gets us a bit closer to making the type field required. We're not there there yet because there are a couple of missing types we need (image, for example), but we should aim to do it.

• We offer higher semantics and gets us a bit closer to having no-code JSON-oriented fields. This may sound a bit abstract, but imagine the following scenario: in the future, there's a mechanism for users to create screens based on declaring which fields they want from a dataset. All via UI. In that scenario, that UI needs to be no-code, and users shouldn't have to provide a "custom render", "custom edit", "custom validation", etc. if they just want a field to be a "slug". Instead, they should work with types: the basic ones provided by DataViews (string, integer, date, etc.) but also any other one that is domain-specific (slug, cart-status, etc.).

Another aspect of this PR is what should be the API offered by the wordpress/field package?

This suggest it should export individual field properties (render, edit, isValid, etc.). There are a few. What if it exported the whole field instead? An advantage of exporting the whole Field is that the wordpress/field package can implement new APIs as they come without having to modify the consumers:

// The consumer doesn't have to modify any code when
// a new Field property is introduced, renamed it, etc.
// It's the FieldSlug responsibility to implement it.

const fields = [
  {
    id: 'slug',
    type: 'core/slug'
  }
];