Make WordPress Core

Opened 8 months ago

Last modified 2 weeks ago

#59283 new defect (bug)

Block Editor: Edit permalink slug for posts is only possible after clicking "save as draft"

Reported by: youknowriad's profile youknowriad Owned by:
Milestone: 6.6 Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch changes-requested
Focuses: Cc:

Description

Originally posted in Gutenberg https://github.com/WordPress/gutenberg/issues/50469

When creating a new post using the block editor, it's impossible to set the permalink of the post before you actually save the first draft of the post. It's different for the page editor where you can do so before.

@andrewserong tracked this to the permalink_template property not being set on the initial request to fetch the auto-draft post.

Change History (13)

This ticket was mentioned in PR #5138 on WordPress/wordpress-develop by @youknowriad.


8 months ago
#1

  • Keywords has-patch added

When loading the post editor the permalink_template property is not set properly on the post object (REST API) (it uses the plain post permalink instead of the pretty permalink). This causes the editor to not offer a way to edit the slug before actually saving the post which results in the permalink_template being set properly.

I tracked this down to get_sample_permalink and get_permalink return the plain permalink structure for auto-draft posts.

I'm not entirely certain about this fix as it's a bit low level, would appreciate a review from folks familiar with this.

@youknowriad commented on PR #5138:


8 months ago
#2

I'm happy to add tests and all later, just want to check whether this is the right fix or if there's something else that we should be doing.

#3 @iamfarhan09
8 months ago

Hello,

I'm interested in contributing to this issue. I can review the proposed code change and assist with testing. However, I'd appreciate some more context on how this change affects the editor and whether there are any specific testing scenarios to consider.

Looking forward to helping out.

#4 @oglekler
7 months ago

  • Keywords dev-feedback added

@spacedmonkey can you please look at the PR discussion, which went a bit beyond the scope into a performance aspect? Thank you!

#5 @hellofromTonya
7 months ago

This ticket isn't ready yet. The discussion is still happening the patch, i.e. how to solve it and what the impacts might be.

The proposed fix is a starting point for discussion:

I'm not entirely certain about this fix as it's a bit low level, would appreciate a review from folks familiar with this.

There are concerns about unknown potential regressions that the change might make harder to identify:

...
I'm not entirely certain about all the consequences here

Yep, thinking this is not such a good idea. It might result is some "unexplained" regressions in other unexpected code/places as (as far as I see) that deals with post caching.

Permalinks for non-published posts are a tricky thing. They are considered "temporary" as they may become unavailable by the time the post is published. On top of that the users can edit them. Generally auto-draft posts should never have a permalink as these posts "don't exist" in the real sense. They are simply placeholders indicating a possible intention to maybe have a post with that ID :)

And it needs discovery of the differences between posts and pages:

And why do we have a different behavior for pages? For pages, it's possible to set the slugs right away and this functions returns the right permalink right away. This is something I was not able to track down.

It would be hopeful for any contributors with deep expertise in this area could take a look and offer insights.

For now, dev-feedback keyword is appropriate to flag more responses from those in the know.

#6 @spacedmonkey
7 months ago

From a performance standpoint, I don't see an issue. I do see a problem with the PR in general. The get_sample_permalink is used to generate a sample permalink from draft post, as they are likely to have title which you can generate a post slug from. Without that, I don't what the post slug would be.

#7 @youknowriad
7 months ago

I don't think the PR has any issue. If you really want to edit the permalink slug before it's auto-generated from the title, it's your decision and the starting point doesn't matter much. It matches the existing behavior in the page editor where it starts from the ID.

#8 follow-up: @nicolefurlan
6 months ago

@hellofromTonya what do you think about #comment:6 and #comment:7? With just over a week before 6.4 RC1 I'm wondering if this would be better for a Future Release.

#9 in reply to: ↑ 8 @hellofromTonya
6 months ago

Replying to nicolefurlan:

@hellofromTonya what do you think about #comment:6 and #comment:7? With just over a week before 6.4 RC1 I'm wondering if this would be better for a Future Release.

Thanks for the ping. The patch/ticket is marked for dev-feedback for discussion of the concerns raised in the PR by @azaozz:

Yep, thinking this is not such a good idea. It might result is some "unexplained" regressions in other unexpected code/places as (as far as I see) that deals with post caching.

Reaching to him to discuss. Will circle back today with a follow-up.

#10 @hellofromTonya
6 months ago

  • Keywords changes-requested added; dev-feedback removed
  • Milestone changed from 6.4 to 6.5

Spoke with @azaozz who confirmed it's best to punt.

His latest comment on the PR:

Right, looking at this again best imho would be to save as a draft if it is an auto-draft at that point, then do that "permalink hack". I.e. the change here will be that a new draft post is created when someone edits the permalink before doing anything else like adding title, content, etc.

Just adding 'auto-draft' to that "hack" (i.e. allowing auto-drafts to have proper permalinks) may open some edge cases like permalinks for non-existing post IDs as old auto-drafts are deleted without warning (garbage collection).

As this ticket needs more time to settle on a solution, punting it from 6.4. Future Release or 6.5? While there's not yet consensus on an implementation, there's good momentum and enough bits and pieces to show a way forward. I think moving it into 6.5 gives it visibility for possible resolution.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


2 months ago

#12 @audrasjb
2 months ago

  • Milestone changed from 6.5 to 6.6

As per today's bug scrub, we decided to move this ticket to 6.6 to give it more time to be discussed.

Last edited 2 months ago by audrasjb (previous) (diff)

ofmarconi commented on PR #5138:


2 weeks ago
#13

Is this not ready yet? Damn

Note: See TracTickets for help on using tickets.