[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