[wp-testers] Upload and use of Images
Andy Staines
andy at yellowswordfish.com
Tue Dec 6 00:53:08 GMT 2005
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
More information about the wp-testers
mailing list