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