Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#54024 new feature request

Internal links with href=outdated-slug and a data-type data-id as fallback should use that and update href=new-slug instead of resulting in broken link (404)

Reported by: abitofmind's profile abitofmind Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Editor Keywords:
Focuses: Cc:

Description (last modified by SergeyBiryukov)

1) The main expectation is in the issue title:

  • Internal links, that are inline A elements with href=outdated-slug and which have the attributes data-type data-id as fallbacks should indeed use that fallback and update href=new-slug instead of resulting in a broken link (404), as I experienced it on Wordpress 5.8 on a PHP 8 server with the Astra theme.


  • Maintaining and updating internal pretty-URLs, I deem that a core feature of a CMS.
  • I really hope it's only a bug, but that use case in general is handled by WordPress or if not by a pretty - robust and popular plugin (recommendations appreciated, if that's the case!).

2) An appreciated feature would be: When changing a post's title (for all post types!) offer an option to bulk process the link text of incoming links.

  • Definition of "link text" a.k.a. "link label" a.k.a. "navigation label":
    • That is the text between the opening and closing of the html a tag:
      <a href="/slug-remains-same-or-gets-changed">
      Link Label was like Old Title or was a Custom Label
  • Overall expectation: If a link has a custom link text, I'd expect that no automatic mechanism of WordPress ever kicks in, but the link text remains as is, as the link creator surely put some (contextual) consideration into it.
  • When changing a page's title or slug, it would be cool to have these "Processing options" in a "Title Widget" of Gutenberg or the Classic Editor:
    For internal incoming links update their link text to the new title?
    (•) Don't change existing link text at all!
    ( ) Only if the old link text was exactly the old title [√] and in the same case
    ( ) Regardless of the old title  ⚠️
    • Note: The options and also the defaults are sorted from no changes at all to most destructive.
    • Hover/click on ⚠️ gives this tooltip: Warning: Authors probably put special contextual consideration when creating custom link text (aka label). This resets all those link texts to the new title. It is an un-doable batch operation! In doubt, first perform a backup.


  • For both 1+2 see my screenshot series full with annotations, which will be attached below.
  • Questions:
    • I'm not sure into which component this falls.
    • Whether 2) should be a separate ticket.
    • I used Gutenberg's "Insert link" feature and this creates the markup. But I am pretty sure what I observed is not Gutenberg-specific, but that generated markup and its handling the the database for rendering, is core functionality.

Attachments (14)

54024a1.png (115.0 KB) - added by abitofmind 3 years ago.
54024a2.png (99.1 KB) - added by abitofmind 3 years ago.
54024a3.png (99.8 KB) - added by abitofmind 3 years ago.
54024a4.png (96.1 KB) - added by abitofmind 3 years ago.
54024b1.png (126.2 KB) - added by abitofmind 3 years ago.
54024b2.png (106.9 KB) - added by abitofmind 3 years ago.
54024b3.png (232.1 KB) - added by abitofmind 3 years ago.
54024c1.png (108.6 KB) - added by abitofmind 3 years ago.
54024c2.png (114.7 KB) - added by abitofmind 3 years ago.
54024c3.png (94.6 KB) - added by abitofmind 3 years ago.
54024c4.png (90.1 KB) - added by abitofmind 3 years ago.
54024c5.png (124.8 KB) - added by abitofmind 3 years ago.
54024b3.2.png (217.6 KB) - added by abitofmind 3 years ago.
Replaces the old screenshot, which had outdated details on the proposal in it.
54024d.png (251.3 KB) - added by abitofmind 3 years ago.

Download all attachments as: .zip

Change History (17)

3 years ago

3 years ago

3 years ago

3 years ago

3 years ago

3 years ago

3 years ago

3 years ago

3 years ago

3 years ago

3 years ago

3 years ago

3 years ago

Replaces the old screenshot, which had outdated details on the proposal in it.

#1 @SergeyBiryukov
3 years ago

  • Component changed from General to Editor
  • Description modified (diff)

3 years ago

#2 @abitofmind
3 years ago

  • Type changed from defect (bug) to feature request


This support answer by moderator @bcworkz confirms that none of my expectations/ideas are yet implemented.

The need for links being: durable + beautiful + auto-healing, all at the same time:
1) durable — IDs are 100% durable, only broken if deleted.
2) beautiful — Slugs are semantic and quite durable, but may change (especially in early lifecycle).
3) auto-healing — A clever combination of ID + slug — Would be a very cool method to have!

As far as I as a UX designer see it, some functionality seems to be already in place.
But the feature would require a clever integration into a functional whole.

1) Link markup already provides href=slug + data-type=postType + data-id=numericalID.
2) Requesting a numerical ID redirects to the slug as the canonical URL if it exists.
3) Requesting a slightly-missstyped-slug performs a fuzzy lookup and redirects if it finds a single close enough match.


I see these possibilities to "hook in" for link healing:

1) Event: Slug change
--> Look for all incoming links and correct them accordingly fully automatically. Ideally combined with my convenience options as stated in my original post to also change the incoming link labels to your liking. Either fully automatic to a preference you set globally. Or incidence based by manual choice.

2) Event: Request of outdated-slug by any user
--> Existing functionality 2+3 tell me that there is an event handler for "slug not found". In that case if you arrive by internal link (=referrer URL is from the same domain) then you can parse the referrer page content for HTML A elements pointing to href=outdated-slug and if there's only one or there are multiple but they all have the same data-id pointing to a valid resource, then perform the auto-healing on the fly. This should usually not arise when having always used method 1 "Event: Slug change". But if you did some editing by non-standard ways which bypass method 1 you may encounter them, i.e. direct DB access or plugins which alter not through standard methods.

3) Batch process:
--> Which searches all your pages (or a limited subset) and performs the auto-healing of the links and the adaption of the link labels according to your liking.
3a) Triggered manually. For your first initial cleanup. Or for later cleanup occasions with a prior backup if deemed too risky or performance-costy. Although I see no risk to auto-heal links which have a valid data-id and no ambiguity.
3b) By cronjob: As a last resort if any of the other methods did not pick up. Or again for risk/performance reasons.


  • Regardless which event triggers the link-healing, a corresponding 301 permanent redirect entry gets added.
  • Only exception if you set the global option "When auto-healing links create a redirect entry" to deactivated.
    • You may do this when you are in the phase of building a website which is not yet publicly exposed.
    • Hence no broken links or broken SEO ranking resulting from it.
    • As soon as the website goes live you should then activate this option.

#3 @abitofmind
3 years ago

  • 👍 All issues outlined here can be solved with plugins (examination in link below)
  • ❌ Except healing broken links in the markup when having intercepted a slug-change during the event of saving a page or when pages in hierarchical structures are moved or parents changed their name.
Note: See TracTickets for help on using tickets.