Anwiki CMS

Yes, files uploading is something which absolutely needs to be added to Anwiki.
A new attribute type "file" will be supported for contentclasses (with options to restrict size/filename), so that you won't have to copy/paste the image data in base64 format.
It would also give better performances to not store the file data directly into the "anw_page" table - even if cached, it's weird to store image data into structured XML :-)
It may also slow down the AutoSync algorithm when updating the field value...
We may store the file data into a dedicated blobs table + cache system, or maybe directly on the filesystem...
The import/export script will be updated to generate an archive for including these files. Also for the translation screen, which should allow uploading "translated" files - when file attribute is translatable.

Anyway thanks for your contentclass suggestion, it's a nice workaround for managing translations of images - at least a temporarily solution!
Have a look to attached file - I added a parameter to only output image data when giving parameter "?rawimg=1" (had to implement AnwCachedOutputKeyDynamic on the contentclass for caching issues). That way, action_view is not broken - this action also doesn't need anymore to be overriden.

It looks also a bit weird to manually hack the "src" attribute for linking the image by URL, and getting it analyzed with $asREGEXP_LINKS.
Maybe an abstraction "tag" such as <anwimg name="myimage"/>, which would automatically resolve appropriate image translation by its name and link with the ?rawimg=1 parameter, would be more appropriated.
You an "easily" implement this with a plugin based on vhook_outputhtml_clean_body_html (for transforming content value before caching, so that transformation doesn't affect attribute value, and only affects its rendering). Have a look to the plugin_smilies or plugin_commontags... don't hesitate for any question!

I can't give ETA for file upload attribute, as it will have various impacts (import/export, translation form, file or database structure...).
I also think we need a more flexible solution for quickly "attaching" files directly to a specific content, without leaving the edition form of the main content. So I'd prefer to be sure of an optimal solution before implementing it. Suggestions are welcome!

Oops, I forgot a debug trace on line 36... (print "!")

Ah, the 2 plugins I mentionned are "unofficial" and not released. They can be found on SVN:
http://svnweb.tuxfamily.org/listing.php?repname=anwiki%2Fanwiki&path=%2Ftrunk%2Fanwiki-addons%2F&#path_trunk_anwiki-addons_

I'm less worried about performance because I don't plan to run PHP for users who aren't logged in - the current version of the site uses a "cache" built of static files already, same will be done here. This is also one reason why I prefer having images display with undecorated URLs.

As to <anwimg> tag, I have been also thinking about doing something like that - to have the alt attribute generated automatically from image title. Ideally, width and height attributes would also be generated automatically. Using vhook_outputhtml_run_body will be necessary then because the image can change independently of the page (as I said, I'm not very worried about performance). But my current work-around will do for now.

Attaching current version of my add-on, it no longer relies on hacking Anwiki source code. The raw output is produced by the new "show" action. The "view" action on the other hand still shows the menu, this makes things easier. In addition to the attached files I use the following code in vhook_outputhtml_run_body to bind image tags and add ?a=show automatically:

// Bind images to the correct target
$sHtml = preg_replace_callback('/(<img\b[^<>]*\ssrc=")([^"]+)(")/', array(&$this, 'bindImage'), $sHtml);

[...]

private function bindImage($matches)
{
$sLink = $matches[2];
if (strstr($sLink, '://') || substr($sLink,0,1) == '#' || substr($sLink,0,1) == '/' || !AnwPage::isValidPageName($sLink))
{
return $matches[0];
}

$oPageTarget = AnwPageByName::getByNameOrSecondChance($sLink);
if (!$oPageTarget)
{
return $matches[0];
}

$sPreferedLang = $this->oPage->getLang();
$oPageTarget = $oPageTarget->getPageGroup()->getPreferedPage($sPreferedLang);

$sLinkTarget = AnwUtils::link($oPageTarget->getName(), "show");
return $matches[1] . $sLinkTarget . $matches[3];
}

The way the action connects to the content class could be improved of course. Translators still see raw base64-encoded string - I would like to eventually use the File API (https://developer.mozilla.org/en/Using_files_from_web_applications) and btoa() to encode a file on the client side if browsers that support it.