[wp-testers] Upload and use of Images

[Andy Staines]

Thanks Owen - this was a very helpful addition.
I rather suspected CACHE_PATH was incorrect. Didn't need a CS degree  
for that one :)

I love WordPress - it does what I need and it does it, on the whole,  
well - but there used to be tendency to assume all users were  
literate and knowledgeable (which was erroneous and bad) and it is  
starting to look like this is swinging to the other extreme as in -  
'let's take as many decisions as possible out of the users hands'. As  
in the comment in this thread - 'All options are evil'. This other  
extreme is just as bad and frustrating to end users.

Your comments below were useful and helpful. Thanks again. Looks to  
me like there are too many bugs and, having worked with a very big  
Ajax development, I'd say the technologies - especially browsers -  
have still not matured enough to make this foolproof. So - let;s take  
a look at the plugins... :)

Andy



On 02:46  PM |  Mon 5 Dec 05, at 02:46  PM |  5 Dec 05, Owen Winkler  
wrote:

> 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
>
>
> _______________________________________________
> wp-testers mailing list
> wp-testers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-testers