WordPress.org

Make WordPress Core

Opened 13 months ago

Last modified 4 days ago

#50499 new enhancement

Slug field should not autocorrect in Quick Edit view

Reported by: swb1192 Owned by:
Milestone: 5.9 Priority: normal
Severity: normal Version: 5.5
Component: Quick/Bulk Edit Keywords: has-patch
Focuses: Cc:

Description (last modified by afragen)

When using the Quick Edit view on a Posts admin page, autocorrect is enabled when editing the slug. This may result in the unintended slugs.

By using spellcheck="false" in the input field, browsers including Safari will no longer autocorrect or spell check the slug field.

Attachments (1)

0000.diff (646 bytes) - added by swb1192 13 months ago.
spellcheck disabled for slug field

Download all attachments as: .zip

Change History (15)

@swb1192
13 months ago

spellcheck disabled for slug field

#1 follow-up: @SergeyBiryukov
13 months ago

Hi there, welcome to WordPress Trac! Thanks for the ticket and the patch.

Just noting that per MDN web docs, spellcheck="false" appears to be the correct value to disable the check, rather than spellcheck="off".

#2 in reply to: ↑ 1 @swb1192
13 months ago

Replying to SergeyBiryukov:

Hi there, welcome to WordPress Trac! Thanks for the ticket and the patch.

Just noting that per MDN web docs, spellcheck="false" appears to be the correct value to disable the check, rather than spellcheck="off".

Thanks for catching that! I wrote "off" in the description erroneously, but the patch has the correct "false".

#3 @afragen
13 months ago

  • Description modified (diff)

#4 @SergeyBiryukov
5 months ago

  • Milestone changed from Awaiting Review to 5.8

Just noting that spellchecking was previously enabled for the post title field on Edit Post screen in classic editor, see [30350] / #30338. That appears to be the only instance of the spellcheck attribute in core at the moment.

This ticket suggests disabling it for the post slug field in Quick Edit on Posts screen.

I don't have a strong preference either way here, moving to the milestone for discussion.

Last edited 5 months ago by SergeyBiryukov (previous) (diff)

#5 @Clorith
3 months ago

Since slugs are by intent likely not going to pass a spell-check, since it's just a bunch of words combined into a long string, this seems like a reasonable enhancement to avoid minor confusion without any obvious drawbacks (especially considering WordPress will auto-generate the slug based on the title, which is what I suspect will be used in the majority of situations).

#6 @desrosj
2 months ago

  • Milestone changed from 5.8 to 5.9

Today is feature freeze day for 5.8.

I'd like to allow a bit more time in order to see a bit more feedback on this one before making the change, so I'm going to punt to 5.9.

#7 @swb1192
2 months ago

@desrosj What is the process of garnering more feedback?

#8 @swb1192
5 days ago

@desrosj How can I push for this to be in 5.9?

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


5 days ago

#10 follow-up: @JeffPaul
5 days ago

@swb1192 this seems like a worthwhile and reasonable enhancement (essentially concurring with @SergeyBiryukov's assessment). Are there any other places you know of that might also benefit from this same treatment? If not, then this seems good to go for 5.9 from my view.

#11 in reply to: ↑ 10 @swb1192
5 days ago

@JeffPaul Thanks Jeff - good point! This could also be added to the URL Slug/permalink field in the block editor. I can provide a diff for that too.

#12 @JeffPaul
5 days ago

@swb1192 that block editor change is probably best filed upstream at github.com/wordpress/gutenberg to get into the Gutenberg plugin and eventually back into core.

#13 @swb1192
5 days ago

@JeffPaul Ah, got it. I'll keep pushing for this to be in 5.9 then. Not sure how to get the right visibility of this ticket.

#14 @sabernhardt
4 days ago

GB33612 is open for discussion about the block editor field.

The spellcheck attribute can also be added to the Classic Editor, and I included it in my patch for fixing the missing label for that input on #53725.

Note: See TracTickets for help on using tickets.