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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED], http://xmouse.ithium.net
_______________________________________________
wp-testers mailing list

_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers

Reply via email to