Replacing file with new name only updates 1 link

Please try new version 3.1

Regret, no change. To be clear with an example.

My site is mainly static pages with a few posts.
Say I have an item ‘abc.pdf’ in the media library, and I have included that via a link on ‘page1’ and also on ‘page2’. In the media library, ‘abc.pdf’ is shown as linked on ‘page1’ but I think it’s a WordPress standard not to list other pages where the media is also linked.
I use media replace to replace ‘abc.pdf’ in the library with a new file called ‘def.pdf’ and ask for the name change with change of links.
‘page1’ now brings up ‘def.pdf’ on its link as expected. ‘page2’ still has the link to ‘abc.pdf’ so it brings up a 404 report becaue ‘abc.pdf’ doesn’t exist any more.
I use media replace to replace ‘def.pdf’ with ‘abc.pdf’ changing the name and links ie, restoring the original content. Both ‘page1’ and ‘page2’ now work fine.

So, media replace with a name change replaces the link on the page cited in the media library, and does not change any link on another page.

It should indeed replace all links. Are you sure your pages are not cached?

Quite sure.
This issue has been reported over a considerable time and by more than one person (see other relevant threads).

I simply can’t replicate this bug. The updating of links is done through an SQL query, which I’ve gone over several times. I’ll need more help to identify why this would happen, as I don’t see it in my own 10+ installations.

Actually @mbsharp, I take that back. It seems I can indeed replicate the bug. I’ll take a look at it right away.

@mbsharp could you please take a look at _how_ the links are made in the pages/posts where they are _not_ updated?

Is it possible that the links that are _not_ updated are not inserted with full domain name and path? EMR is looking for the WordPress standard linking, such as:

<a href="https://www.example.com/wordpress/wp-content/2017/07/myfile.pdf" />

Not:

<a href="/wp-content/2017/07/myfile.pdf" />

or similar variants.

I want to believe this bug is fixed now in 3.1.1. Please update and try!

Thank you for looking at this in more detail.

re link text format.
The format for the links, which appears both in the page text editor and also directly in the MySQL database are all in absolute format starting https://
However, note that there is the additional level of ‘/uploads’ following ‘/wp-content’.
Example: https://’domain’/wp-content/uploads/’yyyy’/’mm’/file.pdf

I also have a separate site which does not use the year & month directory levels ie, all media are in the uploads directory. This doesn’t seem to make a difference.

Having looked at the MySQL format descriptions, I see that a media item does only have one parent post/page declared, although it can be linked from others.

The anchor tags also have a rel=”…” term inserted by the page editor. Taking that out manually has no effect.

• This reply was modified 7 years, 4 months ago by mbsharp.

Well, now I really don’t understand what is going on. I have updated to the latest version 3.1.1

I have one site where the replace with new name works just fine. On that basis I would have to say that the plugin is OK. This site was a clean install in its current location. The wordpress folder is down a level from the domain at ‘domain/wp/’. The media are stored without use of month/year folders at ‘domain’/wp/wp-content/uploads/

I have a second site where the replace with new name only updates the one parent link of the media. This site has been migrated a couple of times from its original development location, but as far as I know that should be OK. The wordpress folder is at the domain level and media are stored using month/year folders at ‘domain’/wp-content/uploads/’yyyy’/’mm’/. I can see in the plugin code where the set of update locations are selected from the database posts table. I don’t know what would happen if there is an execution failure in the subsequent database update. The echo of the number of updates is commented out.

• This reply was modified 7 years, 4 months ago by mbsharp.

I’ve commented out the number of updates, I’ll hopefully use it in a later version of the plugin.

The most likely way the replace of links would fail is if the site has been moved (as you say) and the basename of the file location in the database no longer matches the links that were inserted in an earlier version of the site.

Like, possibly your attachment data in database states that files are located at domain/wordpress/wp-content/uploads/yyyy/mm but in your links they are at domain/wp-content…etc.

I agree. On the site which I said still had the problem, nearly all the pages are pre-migration. Choosing a very recent page which had a new media item (so the page is the media’s parent), and then creating a new test page and adding that same media item (so the test page is not the media’s parent), then replace with new name works on both those pages, but not on another pre-migration page with the same link.

To explain this for other readers.

Your site would commonly contain media links to your own media library, and these would be internal links (although the link is expressed in full with your domain name). Your site may also contain media links to other sites, and these would be external links having a different domain. It is possible that both an internal media and an external media have the same file name (say ‘xyz.pdf’). It is therefore important that media replacement with a name change only changes internal media links and the change action is therefore limited by reference to your own domain name.

A problem arises if you have migrated your site from one domain to another, or even to a different folder level within one domain. Your pre-migration content may be indexed to the former domain even if the link text within your pages/posts now points to your current domain. In this case, media replacement with a name change will bypass the pre-migration content and the link text will not be revised to the new filename.

It will be appreciated that this is an essential safety feature for a media name change. For those affected, the only solution would be a database cleanup to reassign all index values from the old domain to the new one.

Not sure if this thread is being watched still. I have had the same issue with two of my client’s websites. The Just Replace option works fine but Replace Name and Update Link does not actually replace the links.

Both client sites have dev, staging and production environments. Production (live site) is never copied from staging or dev. Changes are simply re-done on production. Production, however, is copied with some interval to staging and dev. So, content on production should not have to factor in migration issues.

Staging and dev go through a full database re-pointing of the domain after each migration by searching/replacing all text entries.

We have 3.1.1 version of the plugin. When we use the Replace Name and Update Link, it does not seem to replace any of the links.

Please let me know what other info I can provide to help detect the issue.

I know I gave what I thought was an adequate explanation above to cover the possibility of migrated sites, but I am not sure the plugin does update links regardless of what I said.
I did a lot of work on my sites checking the database content and cleaning it up, but I still do not think links are updated for all content. In theory, the plugin is doing a text search and replace on all active content in the whole database. In practice I don’t know if it is not finding links, or is being crashed out while searching. There is no log of changes made or faults encountered.
Note, we are talking about links to documents here. Links for images are a completely different issue because of the filename variations for multiple sized copies of each image.

I hear you. I am somewhat familiar with searching and replacing WP DB content and the massive load and possibility of faults it may encounter.

Do you think it is possible to add an option (setting) to allow clients to hide the second option (Replace name and Update Links) and only show the Just Replace option?

In that case, we don’t have to keep explaining this to non-technical users.