[wp-testers] Upload and use of Images

[Andy Staines]

David, Owen or Matt

OK - so I put the define into wp-config as:

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

and received this error when trying to upload:

Unable to create directory /Library/WebServer/Documents//Library/ 
WebServer/Documents//wp-content/images. Is its parent directory  
writable by the server?

(Note this is a local installation on my Mac).
ABSPATH got in there twice with double slashes... My fault somehow?  
Or not as straightforward as it looked please?

Thanks
Andy




On 07:50  PM |  Mon 5 Dec 05, at 07:50  PM |  5 Dec 05, David House  
wrote:

> On 05/12/05, Owen Winkler <ringmaster at midnightcircus.com> wrote:
>> The define you want is not CACHE_PATH, it's UPLOADS:
>>
>> define('UPLOADS', ABSPATH.'/wp-content/upload-location');
>
> Erm... Oops :) How on earth did I manage to come up with CACHE_PATH?
>
>> 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.
>
> I think a plugin would suit this role well.
>
>> 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.
>
> It shouldn't involve writing too much code. In reality, we should
> anticipate this as a fairly common need, and just pass the upload
> location through apply_filters, or perhaps extract the code that
> determines this location into a pluggable function.
>
>> I have serious doubts about how complete this functionality will  
>> be at
>> 2.0's launch.
>
> I think that applies to a lot of 2.0, to be honest. We need real
> rigorous testing of:
>
> * Image uploading
> * TinyMCE
> * Cache
> * Roles system
>
> All the big bits of new code. Although they're not as buggy as they
> have been, there are still a lot of bugs floating around here.
>
>> * 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).
>
> The first seems like a candidate for a core option, the second, third
> and fifth candidates for a plugin, and the last one should come when
> the uploading supports more mime types.
>
> --
> -David House, dmhouse at gmail.com, http://xmouse.ithium.net
> _______________________________________________
> wp-testers mailing list
> wp-testers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-testers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://comox.textdrive.com/pipermail/wp-testers/attachments/20051206/53d81c32/attachment.htm