Heal link with href=outdated-slug plus redundant data-id to href=new-slug ?

Hey @abitofmind. This isn’t handled by the 404 Solution plugin. The plugin only captures 404s so there’s no preprocessing of the links that caused the 404s. The changes wouldn’t integrate easily into the existing plugin – it would have to be a separate one, like a broken link checker.

The plugin will capture 404s when they happen and log them. It can automatically redirect users if it finds an existing page that matches closely enough, depending on how the slug has changed. e.g. If the URL used to be website.com/food/hamburgers and now it’s website.com/delicious/hamburgers it will automatically redirect to the correct URL.

It can suggest a list of possible matching pages if you use a custom 404 page with the plugin shortcode.

Thanks for taking the time for stating so clearly your plugin’s scope! Thanks!

The plugin only captures 404s so there’s no preprocessing of the links that caused the 404s.

Ok, so it deals not with the cause (the broken link in the markup) but with the symptom. And for the symptom provides a permanent “medication” a redirect. But nevertheless the whole experience for that page which provide the broken internal link will always be a tad slower in nature, because there’s always a redirect.

What about when intercepting the symptom (404 for unknown resource) getting back to the high level cause (to the referrer URL) and there looking for the problem (the broken link in the markup). Could this be done in a companion-plugin?

If it’s not too much to ask, I’d appreciate if you could take a look at my feature-request

There I outline the other detection-possibilities:
2) When saving a page with a slug change going to all incoming links and repairing there.
3) A manually triggered bulk operation for legacy or special occasion cleanups.
4) A regular cronjob cleanup (to catch exceptions or for performance reasons).
5) And all that accompanied with automatic redirect entries to not loose SEO juice.

If possible add a comment regarding feasability or effort-estimation. For doing this is in a fresh plugin. Or in core. And whether core or plugin would be the right place according to WordPress philosophy/system-architecture.

I’m a UX Designer, and can have some tech conversation, but am not qualified for questions on software architecture and thelike. Would highly appreciate your input!

I had a look at the feature request. I think using the existing data-id attribute to verify a link’s validity is a good idea. I’m not sure if it belongs as a core wordpress feature. I don’t think there’s any precedent for wordpress verifying the validity of anything else. If it’s a core part of wordpress then the link updating should happen at the time the slug is changed and not afterwards.

For the #2 “appreciated feature,” I think it’s a good idea too, but it does seem completely separate from idea #1.

Maybe your best bet is hiring a developer to create a plugin for you that does those things, eg. from fiverr or elsewhere. If you wait for the features to be added to the wordpress core I think you’ll be waiting a long time.

• This reply was modified 3 years, 2 months ago by Aaron.

Now that you mention it, it is possible to look at the http referrer of a 404 and see if it’s from the current site and then do something about it. I don’t know what would be a valid thing to do about it though. I guess the link could be updated using the data-id. Maybe there’s nothing wrong with that. I’ll give it some thought maybe when I have some time.

@aaron13100 thanks for the consideration!

Wouldn’t it make more sense for the plugin to update the links on other pages at the time when the slug change was done, instead of afterwards?

Or in the case of this 404 plugin the lazy way to add this feature would be to just create an automatic redirect from the old slug to the new whenever a slug change is done. Actually I think the plugin already does this.

• This reply was modified 3 years, 2 months ago by Aaron.

So after looking at the code I think the 404 solution plugin automatically creates a redirect when a page or post slug is changed. My advice therefore is as I mentioned before about hiring someone to create a separate plugin for what you want.

Thanks for looking up up in the code to confirm that your “404 solution” plugin automatically creates a redirect when a page or post slug is changed. So #5 of my criteria list is handled by it.

Wouldn’t it make more sense for the plugin to update the links on other pages at the time when the slug change was done, instead of afterwards?

Exactly! Fixing the problem at the root place (markup) and root event (saving page with slug change) should be the main strategy! Maybe you missed it, but I outlined this in:

2) When saving a page with a slug change going to all incoming links and repairing there.

But complimentary to that one would need a batch-process:
– for #3 initial cleanup
– or recurring #4 cleanup of things which “slipped through” #2 (if saving non API conform, i.e. direct DB editing).

The plugin Broken Link Checker does #3 and #4. And not only for internal links but also for external links, where a cronjob is the only possibility, as in general you have no access to creation/change events of other websites except when using Linkback technologies.

From the overview I gained meanwhile:
– The only missing part in WordPress that is neither covered by a plugin nor core is #2, cleaning incoming links when saving.
– For integration into an existing plugin it would better fit into Broken Link Checker which operates on HTML markup level rather than your 404 solution which operated on HTTP transport level.

Do you concur?