project
project summary freshmeat entry development infos mailing list WebInstaller database tools ChangeLog
page plugins
ProtectedEmail PowerSearch README README.config README.plugins README.fragments ProtectedMode INTERNALS WordIndex AboutPlugins PhpInfo OrphanedPages ListOfPluginHooks RSS RecentChanges PageIndex NewestPages SearchPages MostVisitedPages MostOftenChangedPages UpdatedPages
usage hint
Hint: There is a SetupWizard if you don't want to go through all the docs and plugin directories to chose the extensions you want.
While the code produced by this wiki engine is rather good and senseful it is not 100% valid. It works in most browsers, but
- w3c tidy doesn't like the <p> and </p> tags which enclose paragraphes, however I think it is correct that way
- the dillo webbrowser has problems with the </p> behind headlines and thus closes opened tables (while it works quite well with other gtkhtml derived browsers)
- finally the sublists should get enclosed in <li> ... </li> too, but until anybody complains this won't be changed
It would be useful to include 'wrap=soft' in the textarea definition used for the editing box.
It looks as desired in:
- all Mozilla variants (including Netscape 6/7)
- Opera 5, 6 and 7
- amaya - the reference browser implementation from http://w3c.org/
- Netscape 4
- w3m
- links
- Konqueror
- Windows Netscape 2.01 and Netscape 1.1 (W32s)
- M$IE 4+
Compatibility to PhpWiki
The database table structure of ErfurtWiki is compatible to the one used by PhpWiki; however, whether you can reuse them is untested. In particular changing back from ErfurtWiki to PhpWiki might not be possible.
Compatibility regarding WikiMarkup
- ErfurtWiki only implements parts of the new style markup
- older markup (tabs to the left) will not work and it won't get implemented
- the uploaded images are represented using internal:// references which are obviously invalid protocol identifiers, therefor you should strip them off if you reuse your wiki pages with another wiki software
Sourcecode Layout
Jonnay: It would be handy to split out the main ewiki.php file into various sub-files (perhapse according to function), so that it would be easier to put under source control, and apply patches/bugfixes.
Andy: It would make code merges a lot easier, perhaps the "ENGINE," "BINARY," defines, and ewiki_page sections could be broken into new 4 separate files. ewiki.php would have the defines and include the others.
milky: I know that 60K is a lot, but as I still like to keep the 'library feel' of ewiki.php, that split would mean too much effort if one wishes to just include("a wiki engine") into a site. The CVS, btw, deals very well with it (or still?).
Btw, I think it's time to add a "patches/" subdirectory to the distrib. tarball - we collect it on PatchesAndWorkarounds.
Jonnay: Oh, I certainly was not going to suggest futzing with the library style single include. I agree that one should be able to include a single file, its the beauty of ErfurtWiki. But perhaps the master file does alot of inclusions itself? Or perhaps you use a tool like the C Preprocessor to statically include the pieces when you're done? On the otherhand, if everything works just fine for you now, and you don't have problems with conflics, and change tracking, then don't change a thing. ;)