[wp-testers] Upload and use of Images

Owen Winkler ringmaster at midnightcircus.com
Mon Dec 5 14:46:05 GMT 2005


Andy Staines wrote:
> [ANDY] I can stick (define('CACHE_PATH', ABSPATH.'/wp-content/my-new- 
> cache-location');) in my wp-config? Is this right? 'CACHE_PATH'  defines 
> where images are stored? Can you confirm that please? I can  cover this 
> with a plug-in I guess. It's just that I suspected this  was more to do 
> with the cache rather than images....?

The define you want is not CACHE_PATH, it's UPLOADS:

define('UPLOADS', ABSPATH.'/wp-content/upload-location');

> So - if I define the location am I still going to get the folder  
> hierarchy or can I control that as well?

You're going to get the folder hierarchy every time anyplace in 
WordPress wonders where the upload directory is by calling 
wp_upload_dir().  That's where the date-based directories are created, 
and it seems to be the function to call if you want to know where 
uploads should go.

I suspect that your problem is not whether you can change the root 
upload directory, but whether you can turn on/off the date-based 
directory creation.

As David points out, it's not a good idea to dump everything in a flat 
directory.  However, there are people who have been organizing their 
images in ways other than the method that is now enforced by WordPress, 
and these date-based directories are more of an inconvenience than a help.

For example, I organize images into directories like 
/images/2005/December, which are only slightly yet annoyingly different 
from the method WordPress uses.  But when I have a large group of 
related photos, I like to put them in directories like 
/images/2005/PalmSprings, which is something that the current system 
doesn't allow.  One of the things that leaves me scratching my head 
about this is that while there's an almost obsessive-compulsive need to 
keep things out of my server's web root directory, there's very little 
concern for organization of the stuff I actually give a damn about.  Oh, 
well.

Another interesting thought is that I have an 8 Megapixel camera. 
Uploading just one image via HTTP is a pain.  Uploading a trip's worth 
of images via HTTP sucks royally.  Support for selecting images that 
were uploaded using alternate methods than HTTP would have been nice.

Unfortunately, if you use the built-in image upload functionality, you 
are stuck with what you get.  Reminiscing about the old Upload page and 
how good it was also doesn't get you anywhere, since it didn't support 
multiple directories either.

If you want to override the date-based directory creation behavior, 
you're going to need a plugin.  It will likely need to circumvent the 
checking of the core-defined upload directory entirely if it is not to 
create the date-based directories.  This includes writing all-new 
uploading, thumbnail, and naming routines, and I suspect it will affect 
a few bits that install images as subposts.

Start coding - the core isn't likely to change to accommodate this need.

>> 3. That's still a bug, and is still intending to be fixed. The way to
>> fix this would be to file a bug on trac.
> 
> [ANDY] Tried it again - Confirm I can replicate.

I have serious doubts about how complete this functionality will be at 
2.0's launch.  A lot of it is out of our hands.  There are many browser- 
and OS-dependent issues, along with whether the WYSI IDE is in use. 
With all due deference to the valiant effort Andy is putting forth, and 
through no fault of his, I foresee ugliness in this area upon release.

>> 4. Again, I guess if someone has selected 'Use Original', then we
>> shouldn't create a thumbnail. File a second ticket.
> 
> 
> [ANDY] When you click on the 'Upload' button, two files are created  so 
> there is no choice on whether I want the thumbnail or not. Whether  this 
> is a bug or by design I don't know.
> I'll try and put these on Trac. Last time I tried filing a bug I  
> couldn't log into it but I'll have another try.

Thumbnails are created at upload time to facilitate displaying the 
images in the image browser.  Unless you want to display 5 * 5 Megapixel 
images every time the Write page loads, this is necessary.

There are other things I find I don't like about the thumbnails, more 
than the need to have them:

* Can't set the size.
* Can't store them in a subdirectory.
* Can't customize their names.
* Can't create thumbnails (even placeholders) for non-image mime types.
* Can't use alternate routines for thumbnail creation (Imagemagick, et al).

Someone should throw a hook in there to let plugins override that function.

The bottom line is, I know I don't like the WordPress image handling. 
But I'm picky, and I admit that.  At this point, it's a matter of 
tweaking the functions that are there to get done the job that they set 
out to do.  At the same time, leave enough of the system open so that 
plugin replacements can be coded.

After the first pass at this, the features that people don't use will 
shake out, and then we'll certainly hear about the ones that people 
really want.

Owen




More information about the wp-testers mailing list