Make WordPress Core

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#11276 closed defect (bug) (fixed)

Wrong default upload directory

Reported by: pavelevap's profile pavelevap Owned by: ryan's profile ryan
Milestone: 2.9 Priority: normal
Severity: normal Version: 2.8.5
Component: Upload Keywords: has-patch
Focuses: Cc:

Description

After fresh install there is problem with default upload directory.

Settings - Miscellaneous - Store uploads in this folder - there is only wp-content fulfilled, but there should be wp-content/uploads to work properly. Also next to this field is message "Default is wp-content/uploads".

But when I upload any file, its URL path is set to http://test.cz/wp-content/uploads/something.doc. When I look to FTP account, file is only in wp-content directory. So when I upload picture, there is no thumbnail in Media Library visible because of this problem (thumbnail is not in wp-content/uploads directory).

This problem appears on several different installations of WordPress. Many users ask me for help with this problem, because they are not familiar with these settings (upload directory) to change... When I manually change wp-content to wp-content/uploads then everything works...

Attachments (2)

11276.diff (1.5 KB) - added by Denis-de-Bernardy 15 years ago.
11276.2.diff (2.7 KB) - added by ryan 15 years ago.
Untested

Download all attachments as: .zip

Change History (24)

#1 @pavelevap
15 years ago

  • Cc pavelevap@… added

#2 @Denis-de-Bernardy
15 years ago

  • Milestone 2.9 deleted
  • Resolution set to invalid
  • Status changed from new to closed

it's set to wp-content when safe mode is detected.

#3 @pavelevap
15 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Yes, I understand it, but why there are wrong links to wp-content/uploads when I upload any picture? When there is only wp-content directory fulfilled, pictures are uploaded to wp-content directory. It is OK. But in Media library there are all URL links with wp-content/uploads directory and so there are no thumbnails visible a pictures are inserted into posts with wrong URL address.

#4 @Denis-de-Bernardy
15 years ago

  • Milestone set to 2.9

dunno. but that one sounds like a very valid bug...

#5 @Denis-de-Bernardy
15 years ago

can't confirm in trunk...

#6 @pavelevap
15 years ago

OK, I will try to test latest trunk on my webhosting server and let you know...

#7 @dd32
15 years ago

My understanding is that it occurs under trunk when writing to the wp-content directory fails.. or rather, that creating the uploads folder would fail.

I'm not 100% sure on the upload path being set incorrectly though, That should work as its the upload_path option which its based off.

#8 @pavelevap
15 years ago

Tested with latest trunk (automatic upgrade with plugin Beta Testers). Database deleted and fresh install in English. No change. Problem persists. Please look at it here: http://test.avonita.cz, login: admin, pass: test. You can try to upload picture and you will see that there will be URL with uploads directory which is not set in Options.

#9 @dd32
15 years ago

automatic upgrade with plugin Beta Testers

Did you blow away your database? Once its setup once, those details remain even after upgrading.

#11 @dd32
15 years ago

oddly, the stuff over under Media is correct:

It wasnt when i logged in :)

I just "fixed" it.. I hit save on the Misc. Settings page and now the Upload path for URL's is set properly.

#12 @dd32
15 years ago

Visually, It looks the same, I've go no idea what the options were before/after hitting save.

#13 @pavelevap
15 years ago

Yes, saving button make probably the trick. I will blow away my database once againg and make database backup.

#14 @pavelevap
15 years ago

Here you are. There is new fresh install (with persisting bug). I only changed password to test and install DB Backup plugin (you can find it in Tools - Backup where you can make and download complete database backup).

#15 @dd32
15 years ago

The upload_path option is defaulting to /var/www/web5/avonita.cz/test.avonita.cz/wp-content, a absolute path, upload_path should always be relative to ABSPATH.

I'm not sure why the misc. page does not show the full path in the field..

Denis: Do you feel like diving into that initial option setting code to try to work it out?:)

#16 @Denis-de-Bernardy
15 years ago

Will do, yeah. I'm able to reproduce a similar bug on Dreamhost.

the installer sets it to:

/home/.ngu/user/domain/wp-content/uploads

instead of:

/home/user/domain/wp-content/uploads

I get occasional end-user requests related to the above. So we can probably kill three stones in one go:

  • fix pavelevap's issue and my own
  • fix all sites that have the issue when they upgrade to 2.9

#17 @Denis-de-Bernardy
15 years ago

  • Keywords has-patch added

The attached patch certainly shouldn't hurt... or am I missing use-cases where an absolute path is actually needed?

@ryan
15 years ago

Untested

#18 @ryan
15 years ago

upload_url_path is not adjusted to accommodate safe mode the way upload_path is. Since safe_mode breaking mkdir() doesn't seem to be particularly true, let's just drop that check and always default upload_path and upload_url_path to blank.

#19 @markjaquith
15 years ago

  • Owner set to ryan
  • Status changed from reopened to assigned

#20 @Denis-de-Bernardy
15 years ago

11276.2.diff isn't breaking uploads or media on my localhost install, with the settings stored as wp-content/uploads or as an absolute dir.

It reveals the true dir when viewing settings / misc. I suppose it's the desired behavior if it can lead users with the problem to a faster resolution in forums.

Nonetheless, I doubt it'll hurt much if we automatically fix absolute paths during the WP 2.9 upgrade: it's a pain to resolve those things when one changes hosts.

#21 @automattor
15 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [12405]) Fix upload dir defaults. Props Denis-de-Bernardy. fixes #11276

#22 @ryan
15 years ago

Proposing we upgrade old paths in 3.0. I'm nervous about this patch as it is.

Note: See TracTickets for help on using tickets.