[ewiki] Re: not-so-relevant bug

Hey,

> Sorry to have bothered you w/ my question yesterday. I knew that there was 
> somehthing like /fragments/patches/uploadfilenames, but I didn't find it, 
> though I looked carefully.

That filenames patch still yields ugly internal://-filenames, and the
upcoming plugin will hopefully do much better in that area.


> define("EWIKI_DB_STORE_DIRECTORY", 'data/');
> define("EWIKI_DB_STORE_URL", '/cms/'.EWIKI_DB_STORE_DIRECTORY);
> include("plugins/binary_store.php");
>
> uploading works, binaries are in directory, but linking doesn't work, since 
> links are <a href="/cms/data/internal%3A%2F%2F567.., i.e. the '://' of 
> 'internal://' is escaped, but for apache not to transform it back the '%' 
> themselves need to be escaped to '%25'. 

I find it unnatural, that Apache decodes the values for plain ASCII chars,
but a good fix then was to encode the string twice.
In ewiki.php you would change (around line 850) the "$url = ..." line
and wrap another "urlencode()" function call around the "rawurlencode(...)",
so the "%" itself encodes to "%25" then.

>
> * workaround by setting 
>       define("EWIKI_IDF_INTERNAL", "file_");
>   i.e. binaries start out now w/ 'file_' instead of 'internal://' (don't know 
> whether that works so easiliy)

If you ever change EWIKI_IDF_INTERNAL, you must add it to the list of
protocols in the $ewiki["idf"]["url"] array. It won't however be linked
automatically, and must still be enclosed in square brackets then.

(Eventually I should add _IDF_INTERNAL to this list per default, so
changing it resulted in less trouble.)

mario

Other related posts: