Make WordPress Core

Opened 8 years ago

Last modified 7 years ago

#36034 new enhancement

Change post name permalinks to use ID when inserting links

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


When using the visual editor, and your permalink setting is postname, the default behavior when adding an internal link is that the href attribute points to the slug. For example, if I add a link to a page with the permalink/slug of "my-page" the HTML link will be created as <a href=">my page</a>.

This is fine until the slug of the target page (my-page) changes. Since WordPress doesn't do any checking when a slug is changed to see if there are any links pointing to it, the link is now dead. I propose that when adding links in the visual editor, that they be added based on the ID of the target, not the slug. This would prevent links from breaking whenever a slug was changed, and not affect the use of the post name in the URL. Even following ID-based links return the prettier post name version in the URL.

The code change is already available as a plugin or addition to functions.php from

function wp_link_query_mod ( $results ){
    if( count( $results ) ){
        for( $i=0; $i<count($results); $i++ ){
            $results[$i]['permalink'] = wp_get_shortlink( $results[$i]['ID'] );
    return $results;
add_filter('wp_link_query', 'wp_link_query_mod');

Change History (5)

#1 @chriscct7
8 years ago

  • Version trunk deleted

#2 @akibjorklund
8 years ago

  • Keywords close added

While the issue is valid, it only applies to hierarchical post types (pages). Posts do store old slugs and in case there are links pointing to those, a redirect is automatically issued. For hierarchical post types #4328 is still open.

By using shortlinks we would lose a big part of why post names in URLs are so useful: You can get an idea what the link target page is about by just looking at the URL. Also, it would be a hit to performance, since every internal link click would end up hitting PHP twice. Third, the snippet would only solve the use case where the target page is selected from the UI but not the case when the user just copy pastes the URL of the target page manually – a far more common use case I would assume. Or when the link is external and thus outside of the control of WordPress. Because of all these reasons I propose this ticket to be closed.

#3 @catchmyfame
8 years ago

I think the bigger issue then is simply that a basic search and replace needs to be done, most likely on the SQL side, whenever a slug is changed. The other ticket you pointed to ( has been open for 9+ years and for something so basic and essential to a fully functioning CMS to still be lacking is disconcerting. It shouldn't be so easily to break all links to a page simply by changing the slug.

#4 @catchmyfame
7 years ago

  • Keywords close removed

This ticket was mentioned in Slack in #core-editor by swissspidy. View the logs.

7 years ago

Note: See TracTickets for help on using tickets.