Make WordPress Core

Opened 15 years ago

Closed 3 months ago

#10390 closed enhancement (maybelater)

attachments should store the WP uploads path that was configured when they were uploaded

Reported by: denis-de-bernardy's profile Denis-de-Bernardy Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8.1
Component: Media Keywords: dev-feedback
Focuses: Cc:

Description

When you upload an image, currently, the uploads path (defaults to wp-content/uploads) is not stored.

If you change this later on to something else, previously inserted galleries no longer work, among multitudes of other problems.

Change History (17)

#1 follow-up: @azaozz
15 years ago

You mean change the uploads directory without moving the previously uploaded files so there are two different upload directories?

It seems the more common user case is to move the uploads directory to a new location. In that case galleries continue to work properly (as long as the sub-dirs are kept intact) but the inserted images in older posts need to be corrected.

#2 in reply to: ↑ 1 @Denis-de-Bernardy
15 years ago

Replying to azaozz:

You mean change the uploads directory without moving the previously uploaded files so there are two different upload directories?

Pretty much so, yeah. Site is currently using wp-content/uploads, and I was looking into changing that to media. So one old upload directory, and a new one. If we store the "current" uploads directory (e.g. wp-content/uploads) as a meta, we fix this.

It seems the more common user case is to move the uploads directory to a new location. In that case galleries continue to work properly (as long as the sub-dirs are kept intact) but the inserted images in older posts need to be corrected.

Right. Hence the suggestion, which would kill two birds in one stone.

#3 @dd32
15 years ago

-1 to the ability to have 2 upload directories..

+1 (Like another ticket somewhere in WP) to change the url's in posts retroactively

#4 @Denis-de-Bernardy
15 years ago

I think everyone is totally agreeing on that. :-)

#5 follow-up: @Denis-de-Bernardy
15 years ago

Or rather, what needs to be done is, we store the current value of get_option(upload_dir) or whatever the useful function is, over in post_meta for that particular attachment.

That way, if the folder is changed later on, we still have the correct url -- through wp_get_attachment_url() or whatever it is, which would then use the meta instead of the generic function.

#6 in reply to: ↑ 5 @azaozz
15 years ago

Replying to dd32:

+1 (Like another ticket somewhere in WP) to change the url's in posts retroactively

To do that properly at the moment a db backup has to be made, URLs replaced, then some old posts tested to confirm success and eventually the db restored on failure. Think that's best left for a plugin or for the user to do manually as it would be needed in relatively few cases.

Replying to Denis-de-Bernardy:

Or rather, what needs to be done is, we store the current value of get_option(upload_dir) ... That way, if the folder is changed later on, we still have the correct url

But that will return the wrong URL when the folder has been moved or renamed which seem to be the most common cases.

Perhaps we need a good "canonical" plugin that can handle the different cases when moving, copying, renaming, etc. the uploads directory.

#7 @azaozz
15 years ago

  • Milestone changed from 2.9 to 3.0

No patch.

#8 @miqrogroove
15 years ago

  • Milestone changed from 3.0 to Future Release

#9 @johnbillion
15 years ago

  • Cc johnbillion@… added

#10 follow-up: @ericlewis
11 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

This sounds like plugin (or WordPress systems administrator) territory. As this hasn't been a whisper on this in five years, I'm closing this out.

#11 in reply to: ↑ 10 ; follow-up: @Denis-de-Bernardy
11 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to ericlewis:

Reopening because:

It seems the more common user case is to move the uploads directory to a new location. In that case galleries continue to work properly (as long as the sub-dirs are kept intact) but the inserted images in older posts need to be corrected.

Right. Hence the suggestion, which would kill two birds in one stone.

#12 in reply to: ↑ 11 @ericlewis
11 years ago

So the proposed solution is retroactive URL replacements of the old uploads directory to the new uploads directory?

Right now, we don't store the upload dir path in the database at all (unless you manually set the upload_path option, the UPLOADS constant, or utilize the upload_dir filter. So we would need to set that somewhere, like _upload_path, which would need a comparison on every load to trigger the content migration.

Something like

<?php
add_action( 'init', 'check_if_uploads_folder_moved' );
function check_if_uploads_folder_moved() {
        if ( wp_upload_dir() !=  get_option( '_upload_dir' ) ) {
                /* ... migrate post content ... */
                update_option( '_upload_dir', wp_upload_dir() );
        }
}

#13 @azaozz
11 years ago

Thinking this is best resolved with a rewrite rule rather than changes in the DB. In theory we can go through all existing posts and replace URLs to the old uploads directory. However that leaves out post_meta, options, etc. where plugins may have stored such URLs.

This ticket was mentioned in IRC in #wordpress-dev by ericandrewlewis. View the logs.


11 years ago

#15 @ericlewis
11 years ago

  • Keywords 2nd-opinion dev-feedback added

#16 @chriscct7
9 years ago

  • Keywords needs-patch added; 2nd-opinion removed

This seems toward plugin territory in terms of migration, but it could be trivially handled with a rewrite rule like @azaozz suggested instead of separate meta for each media item

#17 @desrosj
3 months ago

  • Keywords needs-patch removed
  • Resolution set to maybelater
  • Status changed from reopened to closed

In the 10 years since this was last discussed here, I think it's safe to say that migration plugins and various WordPress services have solved this issue. I'm going to close this one out, but discussion can always continue on closed tickets and it can be reopened any time.

Note: See TracTickets for help on using tickets.