[ewiki] Re: How do I save uploads under their name and not internal://md5md5md5.bin?

Hey,

> An option I am still missing (either I don't find it or it doesn't exist yet) 
> is the ability to link uploaded binaries (be it images or other) my their 
> name in the text, like [image.jpg] or [internal://image.jpg] (if that makes 
> it easier for the parser).

Work is underway, it does not yet exist (there is a code snippet in
fragments/patches/ though).

The problem with simply using the submitted filename is, that you
often will receive uploaded images with a name of "image.jpg" or
"test.gif" or even "DSC00012.jpg".  These things must be filtered
or else people will give up frustrated, because filenames are 
as meaningless as before and prevent uploading of images, because
of mutliple name clashes.

A workaround was to occassionally let ewiki invent filenames like
"PageName.1.jpeg" then.

For leaving out the "internal://" prefix I'm not sure. This may be
possible with a bunch of workarounds, but the pseudo-protocol
prefix has the advantage of making images at least distinguishable
from ordinary pages.
(binary content in Wikis is generally considered an evil thing ;)


Another recent discussion (#ewiki IRC channel, *laugh*) was about
changing the image uploading form to not use JavaScript (and its
window popup), but to transmit text + image at once (as the
[internal://image] link is anyhow only appended at the bottom of
the text box). This means using a [ImageUpload+SaveText] button
instead.


> If I understand correctly  ewiki_script_binary() is not used, so I looked at 
> the downloads-plugin. Could I use the vars  EWIKI_UP_UPLOAD or (if set) 
> UPL_NEWNAM in function ewiki_page_fileupload(), where they are passed to (but 
> where is that)?

I'm not sure, but the _NEWNAM (?) only works for the uploads/downloads
plugin, because it pre-filters any upload calls (it does allow uploading
directly with the ?binary=... hook, yes).
The suggested filename plugin workaround is however simpler.

if ($you_enjoy_crazy_ideas) {
  Also we can rediscuss the ?binary= machanism at large. Andy previously
  had the idea of tighter coupling ?binary= and ordinary ?id= page
  requests. I'm not sure if this won't add more complexity, but it
  could ease some things in this case and standardize call conventions
  also (get away from _SCRIPT_BINARY and its automatic binary init and
  start code).
}

Other related posts: