Make Permalinks editable

[pento]

Description

It's time to make permalinks editable.

Fixes #1285.

Screenshots (jpeg or gifs if applicable):

[codecov]

Codecov Report

Merging #3418 into master will decrease coverage by 7.31%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #3418      +/-   ##
==========================================
- Coverage   39.08%   31.76%   -7.32%     
==========================================
  Files         290      290              
  Lines        6967     7706     +739     
  Branches     1273     1386     +113     
==========================================
- Hits         2723     2448     -275     
- Misses       3570     4425     +855     
- Partials      674      833     +159

Impacted Files	Coverage Δ
editor/post-permalink/index.js	0% <0%> (ø)
components/notice/index.js	0% <0%> (-100%)	⬇️
components/panel/row.js	0% <0%> (-100%)	⬇️
blocks/block-controls/index.js	0% <0%> (-100%)	⬇️
blocks/url-input/button.js	0% <0%> (-100%)	⬇️
blocks/alignment-toolbar/index.js	16.66% <0%> (-83.34%)	⬇️
editor/components/post-last-revision/check.js	0% <0%> (-75%)	⬇️
editor/components/post-taxonomies/index.js	28.57% <0%> (-57.15%)	⬇️
editor/components/document-outline/index.js	17.85% <0%> (-57.15%)	⬇️
blocks/block-alignment-toolbar/index.js	33.33% <0%> (-55.56%)	⬇️
... and 298 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5aabd70...9efecec. Read the comment docs.

[afercia]

There are a few accessibility concerns with this UI, starting from the placement in the source: it's difficult to tab to it, the only way is to tab backwards. When tabbing forwards, the whole component is rendered when the tab sequence has already "skipped" it so assistive technologies users won't have a clue something appeared on the screen.

The button to edit should be a separate control: currently the button is announced based on the slug value, this doesn't give a proper feedback about the button action. The input field is unlabeled. There's no "cancel". In the current interface, the permalink is a fully functional link and it's clickable. Instead, now it's just a span with text styled as a link.

However, the first thing to check is probably the input field is actually not editable:

Warning: Failed form propType: You provided a value prop to a form field without an onChange handler. This will render a read-only field. If the field should be mutable use defaultValue. Otherwise, set either onChange or readOnly.

About the UI and interaction, I'd recommend to try to replicate the current one in the Classic editor. There are good reason why each action has a dedicated control. For reference:

[afercia]

P.S. the demo page crashes when clicking on some blocks, I guess because there's no slug there?

[pento]

Yeah, I quickly hacked this into the existing UI to see how it feels - I'm not particularly enamoured by it. It feels super hidden, you can really only discover it by accident.

@karmatosed, what are your thoughts on a slug editing UI?

[karmatosed]

I have a suggestion (a little bit out there maybe), but I would like to get feedback from @jasmussen on this. If we can, I would like us to use the format we have right now. Here is my suggestion for that without clicking in to make active:

The second is when you click in to edit:

[aduth]

Can we know for certain that the viewLink already includes other query parameters? Maybe we ought to use addQueryArgs from the @wordpress/url package?

https://github.com/WordPress/packages/blob/master/packages/url/README.md

[aduth]

We shouldn't offer the option to edit permalink if %postname% doesn't exist in the permalink structure.

[aduth]

Can you explain these regular expressions, preferably in a code comment?

[aduth]

Why do we need to prevent default here?

[aduth]

Why do we need to prevent default here?

[jasmussen]

@karmatosed I like your screenshot, I think it's an enhancement.

However I do agree with both you, Pento and Andrea that this UI (showing the permalink when clicking the title field) is a failed experiment. I can say that because it was my idea ¯\(ツ)/¯

There are some alternative designs in the ticket that I think we should explore (including the link icon).

So yes, we absolutely need to make a better UI for it. However the question is whether we need to do it as part of this PR. Perhaps we can do it in a two-parter — first part being to get this PR in, so it's at least editable, and then we make sure to reopen #1285 (or open a new separate ticket) to improve the UI.

[afercia]

Just to note that in the classic editor, the visible permalink is a fully functional link and it's clickable. Personally, I use it a lot of times to view the post in a new tab, because in the current UI is the most prominent "preview" link for me.
In the new editor this will change, because the permalink UI will be displayed only when needed, but I'd consider to keep the link clickable. The last part shouldn't be a button or input field by default. It should transform in an input field when editing and there should be a separate "Edit" button.

[karmatosed]

Thanks for inputs. I am going to take this on and look at what a next version would be design wise. I'll update here once have that.

[karmatosed]

I did a little digging into this and went back to the idea of what we have currently:

Right now copying is by selecting and copying. We also have a click to view. I thought about what we have in Gutenberg:

This is nice because of the simplification. However it loses the ability to edit easily and copying is a step. What about combining?

The flow to this would be:

• Click to change permalinks: this is a useful feature for users and I think worth putting back in, at least until we can find a better place for it.
• Editing is a one step with an 'ok' being closing and cancelling. This works as both get the same end result. Saving would happen only if a change had happened. Over having a cancel button.
• Clicking the permalink shows it just like in the original version.

The benefit of this is we keep the minimal UI but we get back some of the features expected.

@jasmussen what do you think of this as a suggestion?

[jasmussen]

@jasmussen what do you think of this as a suggestion?

I dig it, and any improvements here are welcome. I don't know that the original issue is solved, though, around discoverability.

Perhaps we should revisit the design that had a floating icon symbol next to the title.

[karmatosed]

@jasmussen true, it does solve the editable issue though. I do think this icon has a potential:

[jasmussen]

I think the stock dashicons link icon could work, yes. Should it be vertically centered in the title box?

[karmatosed]

@pento are you up for iterating on this?

[amandablum]

how can I help? (other than to test, which I'm happy to do)

[karmatosed]

This seems ready to me to get merged with what we have. One potential improvement would be for the link icon to be a copy of the url. I actually found myself wanting to do that. Right now you can't highlight and copy from within Gutenberg the url easily, it clicks to show and you can't copy.

[afercia]

Apart from accessibility concerns to address, there are still some functional and design issues.

• the slug field is still not editable (JS warning missing onChange handler)
• I have no idea how the permalink gets saved 🙂
• when a notice is displayed, for example "Post updated") the whole UI is hidden behind the notice, only a tiny part of the button is barely visible:

Re: the accessibility issues, I'd like to remind UI controls should be grouped in a logical order so I'd recommend to not make the left icon a "Copy" button (it would also miss the confirmation message that appears in place of the original button text). I'd rather place two buttons on the right. Other changes will be necessary to address a11y but I'd say to make it functional first and then improve the a11y part.

[schlessera]

It looks like the permalink is editable even if permalinks are not being used:

This should obviously not be possible, I guess the Edit button should then be greyed out or hidden.

[afercia]

In the Classic editor, when the permalink setting is set to "Plain", the UI is not editable and shows just a button (actually a link) to the Permalink Settings page:

Edit:

When set to "Numeric", it's not editable and no link is shown:

When set to "Custom", it's editable only if it contains the postname, otherwise it's not editable and no link is shown:

[afercia]

Current "logic": https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/post.php?rev=42343#L1367

Looking a that, there are at least a couple more things to address:

• it should check also for '%pagename%' and not just for '%postname%'
• when it's a page and it's the front page, the permalink is not editable and doesn't show the link to the permalinks settings

[schlessera]

I pushed some changes to the PR to make the editing of the permalink work all the way through persistence.

Right now, the validation is solely done on the server end. The slug is pushed through the REST API, and the server then sanitizes the slug. It returns a modified post object, that contains the (potentially adapted) slug.

The Permalink component waits for that response and then adapts its state to accept whatever the server provided. So, as an example, if you already have a post called test, and you rename another post to test as well, it will change to test-2 a few moments after saving the post.

An obvious improvement would be to add basic sanitization at the client level, but proper sanitization would require roundtrips to the server. I think that this implementation is good enough for a first basic implementation, and further UI/UX iterations should be done before delving too deep into the sanitization rabbit hole.

[pento]

It's still a bit buggy, but this PR has been going on way too long. I'm going to merge it, then we can iterate on it a bit more in subsequent PRs.

[karmatosed]

There are a number of issues with this that are blockers to releasing.

Firstly, if you make an edit, then save, it doesn't take until the second time you edit. Aside from that there are a number of visual issues that diverge form the designs:

• The input area is out of line.
• There are 2 buttons : copy and edit beside each other the same styling.

[gziolo]

Reverted with #4675 to proceed with 2.1 release.

[afercia]

I guess the branch should be restored?

[schlessera]

I can continue work on this based on the recent feedback. Just a couple of questions:

• Will the branch be restored or shall I create a new PR?
• Is there a reference somewhere of what components are meant to be used, and when or how? It is difficult to find out what can be reused to base new code on.

[aduth]

I can restore the branch, though it's my understanding that it's not possible to reopen a merged pull request within GitHub. I'm unsure whether a prompt will become available to create a new pull request from the same branch.

Is there a reference somewhere of what components are meant to be used, and when or how? It is difficult to find out what can be reused to base new code on.

If the components are within the same top-level folder, all components can be accessed via relative paths (import from '../../'). For other top-level folders, it depends on whether it's exported (usually from its index.js), but generally I'd say most components are fair to use. That said, there's a loose hierarchy of decreasing specificity from edit-post (post editor) > editor (general block editor) > blocks (blocks API, library), and these components should ideally not be consuming upwards in the hierarchy (i.e. the generalized block editor editor should not be using components from the post editor edit-post).

[schlessera]

Continued in #5414 .