[wp-trac] [WordPress Trac] #54024: 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)

[WordPress Trac]

#54024: 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)
-----------------------------+------------------------------
 Reporter:  abitofmind       |       Owner:  (none)
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Editor           |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------
Changes (by abitofmind):

 * type:  defect (bug) => feature request


Comment:

 **CHANGING TYPE TO "FEATURE REQUEST":**

 [https://wordpress.org/support/topic/internal-links-with-hrefoutdated-
 slug-fail-despite-redundant-data-type-data-id/#post-14827903 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.


 **EXISTING FUNCTIONALITY:**
 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.


 **NEEDED INTEGRATION:**

 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.


 **ACCOMPANIED BY PROPER 301 PERMANENT REDIRECT ENTRIES:**
 - 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54024#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform