[atutor.git] / mods / wiki / doc / README

ErfurtWiki - a fast, user-friendly, highly configurable Wiki engine in PHP
==========================================================================


README
¯¯¯¯¯¯
This is the main documentation for ewiki. It tries to describes the basics,
and how to set it up. More detailed explanations on other issues are
separated out into the [README.config], [README.plugins], [README.fragments]
and [INTERNALS] files, and into the doc/ directory.
(Once you have the Wiki running, you could also read this file in hypertext
format.)

        1 What is this?
      1.1 Why "ErfurtWiki"?
    1.1.1 Unique Features
    1.1.2 WikiAlternatives
      1.2 Project Pages
    1.2.1 Obtaining Support
    1.2.2 License
    1.2.3 Authors

        2 HowTo
      2.1 Integration with yoursite.php
    2.1.1 What to do if images don't work
      2.2 Creating a "config.php"
      2.3 flat file database
      2.4 tarball directoy structure

        3 other/advanced integration issues
      3.1 Generation of a "monsterwiki.php" script
      3.2 Supplying the WikiPageName
    3.2.1 mod_rewrite or PATH_INFO
    3.2.2 use with the 404 trick
      3.3 Security considerations
    3.3.1 PHP settings (register_globals)
    3.3.2 The two modes of operation (_protected_mode and _flat_real_mode)
      3.4 simple usage restrictions via wrappers (a locked PersonalWiki)
      3.5 PhpWiki compatibility
    3.5.1 Transition from another WikiWare
      3.6 Idea Collection
    3.6.1 Multiple Wikis / InterWiki feature abuse

        4 Tweaking (your own wiki markup and CSS)
      4.1 Customizing ewiki_format()
      4.2 Customization using CSS
      4.3 user style classes in pages
      4.4 rendered page content
      4.5 pages enclosed in style classes
      4.6 plugin output styling

        5 Explanations
      5.1 Binary and Text content
    5.1.1 Image Uploading
    5.1.2 Images Caching
    5.1.3 Image WikiMarkup
    5.1.4 binary_store, direct access
    5.1.5 Arbitrary Binary Content
      5.2 $action and $id
    5.2.1 ewiki URLs

        6 Appendix
      6.1 Apache config
      6.2 PHP config
      6.3 error numbers






  -------------------------------------------------------------------- 1 --



What is this?
¯¯¯¯¯¯¯¯¯¯¯¯¯
This is a WikiWikiWeb engine implemented in the PHP web scripting
language. A WikiWiki is a web site which can be edited by everybody
who visits it (most commonly without requiring that user to register
before).

It should allow easy integration into an existing web site (portal
or homepage / CMS-like software), as it is more a library and does
not output a full .html page - but instead just the formatted wiki
text for inclusion in your pages` body/content area.

Many extension plugins are available and can easily be hooked in
(construction set principle). Try the "tools/setup" script.



Why "ErfurtWiki"?
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
The project name comes from the home town of the author (Erfurt is next
to Weimar.de); and our internal project name is in fact just "ewiki".



        Unique Features
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        ewiki is not just another Wiki engine, it has some features that
        clearly separate it from other implementations:

        - contained within a single file (see the notes on "monsterwiki")
        - does not impose a pre-defined layout, because it integrates
          nicely into yoursite
        - it is rather fast - uses regexs too, but the formatting kernel
          uses the simple and quick string functions
        - it is extremely featureful
        - ewiki is not GPLed like 98% of all other Wiki implementations
        - provides case-insensitive Wiki links, multiple database backends,
          and all extended features are optional (a very exhaustive plugin
          interface, and over 200 ready to use plugins)
        - highlights: WikiCommander, OpenSearch, WikiSync, PHP-RPC database,
          PingBack, TextUpload, click-and-run .xpi plugins, image upload,
          GaGaLinks, XFN, CSS markup, WikiScript (not yet), TCN, and
          in-page-macros: TableEditor, WebDAV, ...



        WikiAlternatives
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        If you don't like ewiki, then try at least one of these:

        - PhpWiki has a more complete approach than this WikiWare,
          get it from http://freshmeat.net/projects/phpwiki,
          it has support for different database types, features localization
          and comes with an integrated admin area and also lots of plugins
          made by its gigantic user base and development group. It initially
          inspired the ewiki project, but also was the reason for starting
          it.
        - TikiWiki is a portal system centering around a powerful Wiki
          implementation. Thousands of plugins and developers, many cool
          extensions. http://tikiwiki.org/ and the http://tikipro.org/ fork
        - Pie is a lean and unbloated Wiki implementation using a file based
          database and storing pages as HTML. <http://pie.ekkaia.org/>
        - WakkaWiki by Hendrik Mans is also a very powerful PHP implementation,
          see http://www.wakkawiki.com/
        - Miki is another nice (small) implementation in PHP from Jukka
          Zitting.  Get it from http://miki.sourceforge.net/
        - coWiki - completely OOP and the source code layout is great; looks
          very featureful, but is more a CMS than a Wiki (authentication
          bloat) and has also a little weird markup, but better check it out
          yourself on http://cowiki.org/
        - PmWiki is one of the more mature Wiki implementations for PHP,
          it has been around for some time, has a large user base and is
          still in active development. http://pmwiki.org/
        - MediaWiki drives the well-known WikiPedia project. It is very
          powerful, but like Pmwiki comes with features that initially
          are somehwat overkill for many users. The developer base is
          huge, and features get added hourly. http://www.mediawiki.org/
        - PWiki2 was once the rising star in the world of PHP based Wikis,
          but seems to have frozen in development. http://www.pwiki2.org/

        The BEST PLACE to look for evil concurrent implementations is:
        http://c2.com/cgi/wiki?WikiEngines

        And there is a new WikiEngine comparison table coming up, which
        tries to sort them by supported features:
        http://wikifeatures.wiki.taoriver.net/moin.cgi/WikiEngine

        Why do we recommend "concurrent" projects?  Simple answer: ewiki is
        not a commercial project, we do not depend upon having thousands of
        "customers" or users; and it makes especially no sense to persuade
        people to use it. While ewiki is very flexible, it is not believed
        to met everybodys needs (that would be silly, wouldn't it?).
        Choices are good, and the free software community offers a lot here,
        so please just check them out, and make YOUR choice.

        Also have a visit at http://www.cmsmatrix.org/ if you've got time.



Project Pages
¯¯¯¯¯¯¯¯¯¯¯¯¯
official freshmeat project page: 
- http://freshmeat.net/projects/ewiki

demo site:
- http://erfurtwiki.sourceforge.net/

newest versions (unstable development releases):
- http://erfurtwiki.sourceforge.net/downloads/

mailing list archive
- http://www.freelists.org/archives/ewiki/

secondary site, WebInstaller:
- http://ewiki.berlios.de/



        Obtaining Support
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        Getting support for problems with ewiki is possible, but please read
        this README first. The authors are thankful for BugReports, and of
        course would like to know where this documentation is not detailed
        enough and fails to explain things clearly.  However, before you
        send requests to anyone, please visit following site (this is
        necessary to get FREE support):

        http://www.catb.org/~esr/faqs/smart-questions.html

        Then please feel free to contact the author or leave notes on the
        BugReports or UserSuggestion pages on our project site.
        - http://erfurtwiki.sourceforge.net/BugReports
        - http://erfurtwiki.sourceforge.net/SupportForum

        Joining our http://erfurtwiki.sourceforge.net/MailingList would
        allow you to reach a larger audience for your questions. However
        you need to sign up first, and it's not much faster than the forum.
        Keep in mind, that answers may come in slowly, and visiting back
        first after 2 or 3 days is best practice.

        But after all: DON'T BE SHY TO ASK QUESTIONS - only because we
        have a README here doesn't mean we don't want to give you real
        support.



        License
        ¯¯¯¯¯¯¯
        ErfurtWiki is PublicDomain, which means that you can do with it
        whatever you want (that actually means it is free of copyright and
        any restrictions).  So it is free as in beer, and you can fork it,
        rename it, commercialize it, or publish a derived version under the
        GNU GPL, BSD, MPL, CC* licenses or even Microsofts' EULA.

        ADDITIONAL NOTE: a few plugins in the plugins/lib/ directory may not
        be PD (to date all are, but that could change).  Also the LiveUser
        auth plugins (plugins/auth-liveuser/) are distributed under the GNU
        LGPL. Everything that was a GNU GPL extension module was separated
        out into our "extra"-tarball.



        Authors
        ¯¯¯¯¯¯¯
        Mario Salzer <mario*erphesfurt·de> icq95596825 (+Yahoo,Jabber)
        Andy Fundinger <andy*burgiss·com> from http://burgiss.com/

        For the complete list of authors and contributors please see the
        CREDITS file.

        This project is rather mature and well tested now, but to improve it
        further we need to know what doesn't work or what could be enhanced.
        Every mail is a contribution (yep, that is not measured in lines of
        source code).





  -------------------------------------------------------------------- 2 --




HowTo
¯¯¯¯¯
ewiki is very easy to set up, you only need a web server with PHP (4.1
or later) support. It even runs without a SQL database, but that requires
additional configuration (see for "db/flat_files" in [README.plugins]).
If you unpacked the tarball you can often simply point your browser to
there [http://localhost/ewiki/], to get it running.

The following paragraphs are assuming you want to integrate the Wiki
engine into an existing web site / template. Otherwise you would simply
go with one of the supplied examples/, which are often ready to use.

If you don't want to set it up yourself, you could check out our cool
new remote web install service:
http://ewiki.berlios.de/installer/



Integration with yoursite.php
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
For the next few paragraphs the "yoursite.php" refers to whatever
files and/or scripts belong to your already existing website. This
hypothetical script should at least output the <html><body> tags
around the output from ewiki. The most simple script to accomplish
this could look like this (see also example-2.php):
 
    <?php
       mysql_connect("localhost", "DB-USER-NAME", "PASSWORD");     #[1]
       mysql_query("use DATABASE-NAME-HERE");

       define("EWIKI_SCRIPT", "yoursite.php?page=");               #[2]
       include_once("ewiki.php");                                  #[3]
    ?>
    <HTML>
     <head>...</head>
    <BODY>
    <?php
       echo  ewiki_page();                                         #[4]
    ?>
    </BODY>
    </HTML>
   
[1]  The first two commands open a connection to your MySQL database.
Usually one saves the result of mysql_connect() in a variable named
$db or so, but that was not used in "ewiki.php" at all (because PHP
does not depend on it if there is only a single db connection).

[2]  The define line tells ewiki about the <a href= hyperlinks it
shall create for wiki pages.

[3]  The include_once("ewiki.php") finally loads the ewiki "library" and
sets any EWIKI_ constants that have not already been defined here. Instead
of "include" we use the safer "include_once" since version R1.02b

[4]  The final call to the ewiki_page() function returns the wiki page
which was requested by the browser as <html> string. The "echo" command
lets PHP print it out.



        What to do if images don't work
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        If you don't start the yoursite template with a <?php code part as
        shown in the initial example but have some <HTML> tags before the
        initial inclusion of the "ewiki.php" script, then ewiki cannot
        handle binary content (like uploaded images).

        You must ensure, that yoursite.php script starts with <?php and has
        the include_once("ewiki.php") or include_once("config.php") there:

            <?php
               mysql_connect(":/var/run/mysqld/mysqld.sock", "USER", "PW");
               mysql_query("use DBNAME");

               define("EWIKI_SCRIPT", "yoursite.php?page=);
               error_reporting(0);

               include_once("ewiki.php");

               $content = ewiki_page();
            ?>
            <HTML>
            <HEAD>
              <TITLE><?php  echo $ewiki_title;  ?>
            </HEAD>
            <BODY>
            <?php
               echo $content;
            ?>
            </BODY>
            </HTML>

        Please again, note the initial <?php part before the very first plain
        HTML output - yoursite.php must really start with it, or else binary
        content (uploaded images) won't work!

        You could, of course use a "binary.php" besides "yoursite.php", to
        get around this problem; please see fragments/ for an example.



Creating a "config.php"
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Instead of including the plain "ewiki.php" script as shown in the
example above, many people may find it more useful to include_once()
a "config.php", which then itself loads the ewiki script.

Customization of ewiki takes place, by pre-defining() some of the
EWIKI_ configuration settings and loading extension plugins (see
[README.config] and [README.plugins] for a complete overview). To
not move that work and code into yoursite it is recommended to
create some sort of "config.php" script, which then contained the
various define() and include_once() commands.

It is sometimes even senseful to establish the database connection
(if you use SQL and not the flat_files backend) inside of such a
config script, if it wasn't already established in yoursite.

So such a config.php script could contain:
 - multiple define() commands, setting ewiki behaviour constants
 - include_once() commands to load extension plugins
 - evtl. some include_once() and define() for the db_flat_files plugin
   (if you don't have a SQL database)
 - and last but not least - an include_once("ewiki.php");

If you then include_once() such a config.php, you get a fully functional
and preconfigured Wiki to include into yoursite. By using this
approach, you still could override some of the EWIKI_ settings with
additional define() constants right before the include_once("config.php").

  <?php
     define("EWIKI_whatever", "...");
     include_once("includes/ewiki/myconfig.php");
  ?>
  <HTML>
  <BODY>
  <?php
     echo  ewiki_page();
  ?>
  </BODY>
  </HTML>

Note: All path names here are just examples, they will differ for
your setup!

But again, creating a "config.php" script is optional; it is
supplied in the ewiki tarball for convinience, not for reference.
You may however want to create one of your own, by simply using
the "SetupWizard" script. Just point your web browser to
[http://localhost/ewiki/tools/t_setup.php] and chose the options and
extensions you want. Beware that while it provides a simplified
overview, it is not really short.

IMPORTANT: Please use "include_once()" instead of the "include()"
feature. This is to prevent accidential double loading of plugins.
We do this since R1.02b, and this is how the generated config scripts
will work.



flat file database
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
If you don't have a MySQL database, then you must configure ewiki to
store pages in a dedicated directory. You need to include_once() the
'plugins/db/flat_files.php' plugin prior to 'ewiki.php'. You must
also set the constant EWIKI_DBFILES_DIRECTORY to a location which
is world-writable ("chmod 4777 dirname" in FTP/shell). Usually this
would look like (in yoursite or a config.php):

   define("EWIKI_DBFILES_DIRECTORY", "./pages/");
   include_once("plugins/db/fast_files.php");
   ...
   include_once("ewiki.php");

See [README.plugins] for more information on "db/flat_files". You can
also use the newer "db/dzf2" which creates a deep directory structure,
and seems to be a bit faster on some systems - moreover that one also
provided case-insensitive WikiPageLinking under Unix.



tarball directoy structure
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
You get following directories and files, when you unpack the tarball:

README.*       main documentation
doc/           detailed doc on certain subjects
ewiki.php      the core script, contains the minimum wiki
config.php     example configuration script
example-1.php  example yoursite wiki wrapper
examples/      more sample layout wrapper scripts
plugins/       large directory with extension scripts
local/         empty, use for your own/modified plugins
fragments/     code snippets, separate files, often not very ewiki specific
init-pages/    holds default wiki pages, automatically transfered into DB
spages/        "StaticPages" are dynamic/page plugins
tools/         database + administration tools, including SetupWizard
wiki.css       description of CSS classes used in the core and plugins
z.php          interface for Wiki-RPC, WebDAV, ?binary=, OpenSearch, sync, ...

Feel free to explore especially plugins/ and fragments/ somewhat deeper
with your favourite file browser. Every file should carry a little amount
of documentation on top. The [README.plugins] file is always somewhat
outdated and not meant to describe everything anyhow.





  -------------------------------------------------------------------- 3 ---



other/advanced integration issues
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Once you mastered the basic steps to integrate the wiki into yoursite, you
may choose to fine tune the generated URLs, behaviour and appearance.

The following paragraphs are a selection of common issues and solutions,
like using mod_rewrite, setting up simple authentication schemes or changing
from another Wiki.



Generation of a "monsterwiki.php" script
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
ewiki over the time grow larger, and nowadays isn't anymore the
SINGLE SCRIPT it once was. The distribution ships with over hundred
extension plugins. But nevertheless it is still possible to build
a single script from it all.

That being said, the "ewiki.php" script still implements a fully
functional Wiki (and just only lacks the advanced features supplied
by the plugins). - You could still just include_once() the "ewiki.php"
script into yoursite and delete everything else the ewiki tarball
contained.

However, it is also possible to MERGE all wanted plugins and the
core script together to built a customized (feature enhanced) Wiki
script from it. All you needed to do was:

  /unix/$   cat  ewiki.php plugins/*.*  >  monsterwiki.php
or
  C:\win\   type  ewiki.php plugins/*.*  >  monsterwiki.php

This way you'd get the "monsterwiki.php" file, which contained the
ewiki core script plus all plugins - but of course, you should only
copy the ones in, you really need and want (and not all "*.*" as
shown in the example above)!

The UNIX shell script "tools/mkhuge" will do exactly that for you;
it accepts a parameter from 0 to 3, which will merge a custom set
of useful plugins into the then generated "monsterwiki.php" script.
In newer versions, you may want to use the "tools/setup" console
tool instead (for Linux), which makes this far easier.

If you have built a "monsterwiki.php" script, you can include() this
instead of the minimal "ewiki.php" into yoursite to integrate a Wiki.

Eventually you'd also want to merge some configuration settings into
this monsterwiki script, so you wouldn't have to put the define(...)
commands into yoursite.php before you include("monsterwiki.php");
The define() commands however need to be the very first part merged
into that monsterwiki script, so it's best to edit the monsterscript
after generation and insert the appropriate settings then at the
very beginning.
    You could also merge a (reduced!) "config.php" into the script,
    using the above "cat" (or "type" for DOS/Win) method.  But
    beware, that this "config.php" then does not contain any
    include() command; because else the resulting "monsterwiki.php"
    script would fail trying to load the "ewiki.php" core script and
    plugins which were probably already merged in. (The newer and
    recommended "include_once()" won't help here.)  Even if you merge
    such a minimal config script at the start of this monsterwiki
    script, you still could override some settings (at least
    establishing the database connection) from within yoursite, if
    you think it's useful.

Additional note: You could still include() plugins, if you included()
such a monsterwiki script into yoursite, provided that the plugin
you try to include() wasn't already merged into that monsterwiki.php
script before (else it would crash the PHP interpreter, because
loading it twice is once too much => error + crash).

StaticPages (read about "spages" plugin) can also be included, if
you first convert them into ordinary ["page"] plugins using the 
'mkpageplugin' commandline tool.



Supplying the WikiPageName
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
If you just call ewiki_page() as shown in the first example, it will
try to get the name of the requested WikiPage either from the
$_SERVER["PATH_INFO"] variable or from one of the GET-variables '?id='
or '?name=' or '?page=' or '?file=' (available as $_REQUEST["name"]). 
If yoursite.php however uses another way or another varname to receive
the WikiPageName you can just give it as first parameter:

  ewiki_page( $id = "WikiPageName" );

example-4.php shows how this can be used to list a second WikiPage
(the list of newest pages) somewhere else on yoursite.php.



        mod_rewrite or PATH_INFO
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        If you dedicate a complete directory for your wiki, you should keep
        in mind, that some of the generated URLs contain slashes (for
        example "edit/WikiPage"), and will look like subdirectories and thus
        confuse browsers.

        So you should either set EWIKI_SCRIPT to the absolute directory
        containing your wiki wrapper script: define(EWIKI_SCRIPT,
        "http://myserver/wiki/"); or else put a <BASE HREF="..."> into the
        generated pages. Take this precaution because some of the generated
        links contain additional slashes (like "edit/ThisPage") and thus may
        make browsers believe in a changed subdirectory.

        This applies to mod_rewrite usage and if you call your wiki wrapper
        with the page name as PATH_INFO (like "/wiki/index.php/WikiPage").

        Do not forget to enable EWIKI_USE_PATH_INFO, as it is per default
        disabled for Apache servers! Also check, if EWIKI_URLENCODE and
        _URLDECODE suit your needs, else you will find it useful that all URL
        generation is encapsulated in our ewiki_script() function (so you can
        easily adjust it).



        use with the 404 trick
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        Once I've implemented a way to run a web server below another one
        (actually Nanoweb below Apache, for more details see
        http://nanoweb.si.kz/), because the Apache on one of my providers
        servers was heavily misconfigured - so I handed work over to a
        secondary WebServer.

        This trick also works without mod_rewrite support, and is therefore
        also well suited for cheap WebSpace. Put following into the
        .htaccess of the dedicated wiki directory:

          #-- handle "not found" pages by ewiki
          ErrorDocument 404 /wiki/index.php
          DirectoryIndex 404 index.php

        This will allow the "yoursite.php/ewiki.php" script to catch all
        missed files, which would usually trigger a 404 error. Inside your
        ewiki wrapper script, you must then however decode the originally
        requested URL:

          $url = $_SERVER["REQUEST_URL"];               # Apache often uses this one
          $url = preg_replace("#^/wiki#", "", $url);    # strip wiki subdir name
          $_SERVER["PATH_INFO"] = $url;                 # make ewiki see it

        The second step is very important, it strips the name of the
        dedicated subdirectory from the URL, which cannot be done inside
        ewiki.php.

           The $url from the above example could also be used as $id
           parameter to ewiki_page().           

        It should be noted, that some Apache implementations are garbaging
        POST requests in case of a triggered 404 error - but you can simply
        test this by saving a changed WikiPage.

        See also the "fragments/404finder.php" example on this.

        Do not forget to enable EWIKI_USE_PATH_INFO, as it is per default
        disabled for Apache servers!



Security considerations
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
ewiki was developed using a PHP5 interpreter, but with limitations of PHP4.3
in mind. There are huge differences (a rather instable, bug-prone and still
unfinished language) across the 4.x versions of PHP. The 4.0 series is not
enough to run ewiki, you'll need at least a PHP 4.1 (4.07) to make it work
reliable.

One must also know, that there are also differences between the settings of
providers. Some for example enforce users to run their scripts in so called
"safe mode" (crippled mode) in place of real server security guidelines.
Other still use pre-4.3 settings for the PHP interpreter (the Win4 php.ini
still is outdated). So take care, and adjust settings using .htaccess`
php_option for Apache servers if you can.
 


        PHP settings (register_globals)
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        Because ewiki was developed on later PHP versions (at least 4.3), it
        heavily uses the $_REQUEST array and assumes a deactivated
        "register_globals" setting in php.ini
        If this is not the case for your setup / WebServer or with your
        provider the ewiki.php script may expose some security leaks
        (because of uninitialized variables).

        ewiki in general does only use a few global variables, but especially
        the $ewiki_ring variable (which is used for PROTECTED_MODE) can lead
        to problems, if you use it without an existing authentication
        concept.  The $ewiki_plugins is also a very complex task, and I
        cannot safely state that it won't be able to produce exploits, if
        the variable is tweaked externally (pushed into by a client).

        So the best thing you could do is to disable register_globals (this
        can be done from inside a directories .htaccess file by inserting
        the line "php_option register_globals off").

        A fragments/ include will be added to strike against variables which
        got set from outside (this is rather easy for variables used by
        ewiki, because their names all start with "$ewiki_").



        The two modes of operation (_protected_mode and _flat_real_mode)
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        While this wiki was originally developed as a real wiki, many people
        use it for different things now, like private HomePages, easy CMS on
        commercial web sites.

        This fact lead to the support of a restricted operation mode, now
        known as the _PROTECTED_MODE. It is often used to require people to
        log in before they can edit pages or upload things. It is completely
        optional, and doesn't have much impact on speed when left disabled.

                                  Btw, the standard ewiki operation mode is
                                        now known as the _FLAT_REAL_MODE ;)

        If you'd like to use authentication, you'll probably want to chain
        some plugins which enable you to use the user database from
        yoursite.php, so you do not need a separate .htaccess or an
        additional relational database for passwords. Please see the section
        on auth plugins.

        See also the EWIKI_PROTECTED_MODE configuration constant and the
        separate [plugins/auth/README.auth] file for further and more
        detailed informations on this feature.



simple usage restrictions via wrappers (a locked PersonalWiki)
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
The easiest way to cripple a Wiki setup to be browseable-only for the larger
public, and to allow only a small subset of users to edit pages is to write
two wrapper scripts around the ewiki.php library.

One of the wrapper scripts should include and use ewiki as described in the
"Integration with yoursite.php" paragraph. You may want to move this wrapper
script into a password protected subdirectory (say "/wikiadmin/index.php")
or just include("fragments/funcs/auth.php").

Another wrapper script should then be provided for the users that are only
allowed to view pages. To disallow editing you'll just have to enrich it
with commands like:

 unset($ewiki_plugins["action"]["edit"]);       # disables editing
 unset($ewiki_plugins["action"]["info"]);       # no info/ action
 unset($ewiki_plugins["page"]["SearchPages"]);  # no search function

This code must occur after you have 'included("ewiki.php");' the library,
but before you call the 'ewiki_page();' function, so the unwanted actions
and pages really do not get activated.

So far the basic approach. If you however have real user authentication
code behind the scenes you probably don't want to maintain two different
wrapper scripts. You'll then just put the functionality stripping code
from above into an if-clause in "yoursite.php" like:

 if (! $user_is_logged_in) {
   unset($ewiki_plugins["action"]);   # (you should do it less destructive ;)
 }

Note: this is again an example. DO NOT copy&paste examples and assume
they'll work for you!



PhpWiki compatibility
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
The MySQL database table is partially compatible to PhpWiki versions 1.2.x,
but not with the current PhpWiki 1.3.x versions. There is however now a
db/phpwiki13 plugin which allows to access those too (rw).



        Transition from another WikiWare
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        If you choosed ewiki to replace an already existing wiki script on
        your site, you should first think about, that the syntax/WikiMarkup
        isn't equal across all Wikis. There are a few markup extension
        plugins, that may help you around this, but beware that transition
        with a larger collection of WikiPages won't be very easy.

        The best way to import the old WikiPages to ewiki, is to first
        export it using the tools of the previous WikiWare. You can then
        just put the produced text/plain PageSource into "init-pages/",
        because all files found therein (note, that there shouldn't be any
        file name extension like .txt) are feed directly into the ewiki
        database, when ewiki is run for the very first time (when the
        EWIKI_PAGE_INDEX is not found in the db).

        There is a "plugins/db/phpwiki13.php" which may be useful in first
        trying ewiki, but it is not recommended to use it for daily work. 
        Speaking of PhpWiki you could also use the "tools/t_convertdb.php"
        to import (and markup convert) all pages from PhpWiki to the ewiki
        database format.



Idea Collection
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Here we'll note some tricks, on how to do this and that. Some of the
following paragraphs also explain workarounds for currently lacking
features.



        Multiple Wikis / InterWiki feature abuse
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        Other WikiWare provides means to have multiple namespaces in a wiki,
        what if fact is contrary to the original Wiki idea suggesting a
        single flat namespace. ewiki does not support SubWikis or alike, to
        get multiple Wikis using one ewiki installation you'll need multiple
        layout and config wrappers (each with its own absolute URL and
        differen EWIKI_DB_TABLE_NAME or EWIKI_DBFILES_DIRECTORY constants).

        This way you'd get two independent Wikis (with two different SQL
        database tables, or flat_files directories), and of course links
        between those two need a special syntax. And the best approach here
        was to use the InterWiki linking feature.

        To do so, invent to InterWikiAbbreviations for each of your separate
        Wikis and add it to $ewiki_config["interwiki"] as follows:

          $ewiki_config["interwiki"]["main"] = "/wiki/main/?id=";
          $ewiki_config["interwiki"]["office"] = "/wiki/office/?id=";
          $ewiki_config["interwiki"]["tech"] = "http://tech.company.com/?id=";
          $ewiki_config["interwiki"]["our-www"] = "http://www.company.com/";
        
        The last one is an example, on how to use the InterWiki feature to
        generate references to arbitrary web documents, with a simple syntax
        like "[our-www:/customers/pub/rules.html]" - it's somehow standard to
        use "company-url:" or "company-www:" as InterWikiAbbreviation for this
        purpose.





  -------------------------------------------------------------------- 4 --





Tweaking (your own wiki markup and CSS)
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
(this part of the README is also just a collection of random notes)




Customizing ewiki_format()
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
There are various markup extension plugins available for ewiki, which
allow you to use BBCode or the syntax of another WikiWare. But if you
have a closer look at $ewiki_config (the defaults are in 'ewiki.php'
around line 200), you'll notice, that you can configure the WikiMarkup
that is to be used.
Various "wm_..." entries map our obscure markup to html <tags> (or at
least fragments of them). So in order to add a feature you could insert
an own rule there. (But keep in mind, that every new WikiMarkup slows
down the transformation function.)

Often you want to append an entry to "wm_style", for example:

   $ewiki_config["wm_style"]["==="] = array("<h1>", "</h1>");

Would allow you to write "===SomeText===" in a WikiPage, which then would
display as an far-too-large headline.

You can also add markup with different 'start' and 'end' characters, using
the "wm_start_end" entry in $ewiki_config. For example the following would
render "... ((((some text)))) ..." in a page using the html <kbd> tag:

   $ewiki_config["wm_start_end"][] = array(
       "((((", "))))",   "<kbd>", "</kbd>",
   );

Please see the section on "ewiki_format() internals" on how to write a
["format_..."] or markup plugin, see [README.programming].



Customization using CSS
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
There are now some interesting ways to style ewiki output, just read on.

Please note, that it in your stylesheets you just write ".wiki" and
REALLY NOT ".ewiki" this time.

Also important is, that we discourage use of the underscore in CSS class
names, because it is simply forbidden there, even if current browsers do
not complain as loudly as the w3c does. (That's just why you'll now see
lots of class names with minus dashes instead of underscores.)



pages enclosed in generic style classes
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
The most powerful way to style the content ewiki includes into your site
is to use the generic style class names which enclose every page that comes
from ewiki:

   <div class="wiki view PageName">
      ...
   </div>

This <div> is always the outermost tag around the html content that returns
from ewiki_page(). It will always contain the class "wiki", after this
the current page action/ and PageName (the action is usually "view", but
can be also "edit", "info", "links" or something similar).

If you haven't seen that before, this is in fact valid CSS. It means that
this <div> is part of three classes. You can then use either ".wiki" or
".view" or ".PageName" or any compound of the three like ".wiki.view.PageNm"
as selectors in your stylesheet.

   Note: Non-word characters in page names are converted into '-' dashes
   usually (including dots and spaces, underscores, and so on), consecutive
   dashes are collapsed. If a page name originally started with a number,
   then "page" will be prepended to it.
   So for example "99BottlesOfBeer.en" became "page99BottlesOfBeer-en" in
   the stylesheet.

Keeping this in mind you can easily style all, a few or even just a single
page from ewiki in your stylesheet. (We'll explain it here, because the word
of multiple class names and the cascading way of using CSS is not very
widespread.)

.wiki  {                       // this affects every page ewiki returns
   background-color: #ccccff;
   font-family: "WikiFont";
   ...
}

.wiki.view  { ... }            // only applies to pages that are "view"ed
.wiki.links  { ... }           // BackLinks
.wiki.edit  { ... }            // when a page gets edited

.wiki.PageIndex  {             // this rule affects only a __single__ page
   ...                         // regardless what the "action/" is now;
}                              // useful for "PowerSearch" or "PageIndex"

.wiki.edit.ThisVerySpecialPage {   // this css section applies to just one
   ...                             // page again, and this time only when
}                                  // it gets edited



page style class fragmentation
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Moreover inside that generic <div> the page is fragmented further into
its individual parts to make styling it only partially really simple:

   <div class="wiki view PageName">

      <div class="text-head">
        <h2 class="text-title"> <a>PageName</a> </h2>
      </div>

      <div class="text-body">
        here comes the
        actual page content
        ...
      </div>

      <div class="wiki-plugins">

         <div class="action-links">
            <br/>  <hr/>
            <a>edit</a>  <a>info</a>  <a>links</a>
         </div>

      </div>
   </div>

So the .wiki class itself is divided into three parts, where .text-head
typically only contains the headline (.text-title) and the actual page
content comes encapsulated in .text-body

The part following as .wiki-plugins contains the individually named output
blocks from the so called aview-plugins, one of it is the .control-links
block containing the EditThisPage, BackLinks, ... actions and control links.
But there may be more of it inside of the .wiki-plugins block. See also
the paragraph on "plugin output styling".

Likewise the .text-head block could contain more, but currently no plugin
throws other output above the page content or title.

This further separation allows you for example to give headlines or page
content different borders or margins than the action links, so that it
matches better into your layout. You however don't need to use that classes
at all and could simply apply all styles onto the complete .wiki selector
as usual.



rendered page content
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
If you are not interested in walking around the "ewiki.php" script
when you want to tune how the output looks, you should try to
utilize the (few) CSS classes ewiki defines (it does not include
even one color setting or <font> tag):

<style type="text/css">

   p     { font: ... }          // almost every part of the generated
                                // wiki pages is inside a <p>...</p>

   em    { ... }                // you could encolour this, if the browsers
   strong { ... }               // usual italic is not emphasized enough

   .indent                      // to specify a different space-indentation

</style>   



user style classes in pages
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
The plugins/markup/css allows you to use CSS classes and style definitions
in WikiPages. With the double at "@@" followed by a css classname or command
you start styling a paragraph or parts of the text.

  @@classname at the start of a paragraph will
  enclose it into a <div class="classname">
  completely

  But inside of some text, the @@styledef only
  affects the part until the next  @@ - everything
  that comes later won't be enclosed in a <span>

While the css style classes must be defined in your sites` global stylesheet
to take effect, you could also use direct CSS style commands instead. These
also must follow the @@ immediately and may not contain spaces. So something
like @@color:#ff0000; will work, while specifying font names may not always.



plugin output styling
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
There often appear special 'pieces' within a rendered page that ewiki
returns, because not everything in the returned html code belongs to the
requested pages` content.

For example the current pages` title needs its own css class, like does
the block of action links ("EditThisPage, PageInfo, ...") below every page,
so it can be distinguished from the pages` text.

Also note again the use of the '.wiki' selector within the following
stylesheet guide and ewiki CSS class overview:


.wiki  h2.page.title  {         // all titles now have it, while many
   ...                          // of them include links as well
}

.wiki.view  .action-links  {    // "EditThisPage, PageInfo, ..." links
   ...                          // are inside such a block, like are two
}                               // <hr>'s

.wiki.info  .chunked-result {   // some generated pages (like the history
   ...                          // info/ ones) may need to split their
}                               // results; this matches those links

  //-- the edit/ pages are separated into
  //   following blocks:
.wiki.edit  .edit-box   { ... }
.wiki.edit  .image-upload   { ... }
.wiki.edit  .preview  { ... }

  //-- info/ pages contain a history of page versions, each enclosed in
  //   a <table class="version-info">, the <tr>s inside can be selected
  //   separately:
.wiki.info  table.version-info  { ... }
.wiki.info  .version-info  .action-links  { ... }
.wiki.info  .version-info  .page-author  { ... }
.wiki.info  .page-refs  { ... }
.wiki.info  .page-flags  { ... }


The class naming across most of the extension plugins is not unified, so you
may often need to look it up here - or inside of the plugins source code.
This is at least necessary for calendar and navbar, which follow a very
different naming scheme.

.wiki  .download-entry  { ... }
.wiki  .download-form  { ... }
.wiki  .upload-form  { ... }

.wiki  .image-append  { ... }







  -------------------------------------------------------------------- 5 --




Explanations
¯¯¯¯¯¯¯¯¯¯¯¯
The next few paragraphs shall enlight more detailed how some things are
handled in ewiki (and why it is that way).



Binary and Text content
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Because I'd like to keep it small (see also the "Everything in one
script" paragraph) ewiki also creates just one database table.
Differently from other Wikis this one has the 'flags' setting for
each saved page. And as I successfully used this bad trick in earlier
projects many times to integrate support for hundreds of different
functions (CMS, links, boards/forums, ...) into a single table; I
thought it could be funny to have something like this in ewiki too.

While the image thingi seemed senseful to me, other binary data
cannot be feed into database without helper plugins, because this is
a Wiki script and not an almighty portal software!

Uploading and caching of images requires the EWIKI_SCRIPT_BINARY
constant to be set correctly (no output may be made before "ewiki.php"
is included == "binary safe").
The ewiki_binary() function handles almost all of this, and gets
activated automagically (whenever required) as soon as ewiki.php is
included().

I believe these functions to be rather safe, as there are many sanity checks
throughout the code to separate between _DB_F_BINARY and _DB_F_TEXT content.



        Image Uploading
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        The currently most important use for the BINARY flag and image
        functions is to upload images with the small form below every page
        edit box.

        The upload/caching functions can be disabled fully if
        EWIKI_SCRIPT_BINARY and EWIKI_CACHE_IMAGES are set empty (or zero).

        URLs starting with "internal://" represent the uploaded files. The
        string is just a md5() sum generated from the contents of the
        uploaded file. This way files won't get saved another time if they
        are uploaded twice.  For uploading a JavaScript-capable browser is
        recommended. It will work without, but then requires the user to
        copy the [internal://...] text (from one window to another).

        The color of the temporary upload info screen can only be changed
        inside the ewiki_binary() function, currently.

        Beware that images usually get downscaled if they are larger than
        specified with EWIKI_IMAGE_MAXSIZE (per default 64K).



        Images Caching
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        Images are usually redirected through EWIKI_SCRIPT_BINARY, and ewiki
        tries to save them inside the database as with uploaded images. So
        most of the facts from the previous paragraph apply to this function
        too.

        You must enable this feature with EWIKI_IMAGE_CACHING, it is shipped
        disabled currently.
        Adding a ?nocache to the image URL disables this feature for just one
        specific image, if _IMAGE_CACHING was otherwise enabled.

        Images are downscaled to fit the maximum defined size in
        EWIKI_IMAGE_MAXSIZE (bytes) if the PHP libgd extension is available
        (else dropped and then always redirecting clients which request
        those image).



        Image WikiMarkup
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        Usually one writes image references using square brackets around the
        url of an image: [http://www.example.com/pics/image.png] or:
        [internal://md5md5md5md5md5md5md5md5md5md5md5md5.png]

        This will include (inline) the image into the page, when rendered
        and viewed.  Using the standard square bracket link entitling syntax
        also image references can be named (non-graphics / alternative
        text):
        [http://www.example.com/pics/image.png | This is an example image]
        [http://.../image.pic "or entitle it using double quotes"]

        Images can also be "aligned" to either side of the screen, thus the
        remaining text will flow around it. To achieve this include spaces
        to the left or the right of the image URL:

        * picture to the LEFT:   [http://www.example.com/pics/image.png  ]
        * picture to the RIGHT:  [  http://www.example.com/pics/image.png]
        * CENTRED picture:     [  http://www.example.com/pics/image.png  ]

        Note that you must use __two__ spaces, currently!

        Image rescaling is possible by appending x=... and y=... as query
        string parameters behind the image URL:
          [http://www.example.com/pics/image.png?x=160&y=120]
        The query string parameters "width" and "height" are also accepted.

        If you have an image URL, but you do not want to get that image
        inlined into the current page, then just leave out the square
        brackets around.



        binary_store, direct access
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        While storing the binary data together with text pages in the same
        database is most often a good thing and suits most sites, there
        exists also a workaround/hack to keep this binary data in plain
        files. The advantage is a smaller database and possibly a little
        speed enhancement (with a large collection of binary things in the
        db). However the drawback is, that use of plugins/binary_store is
        only transparent to the main ewiki script, but all admin tools/
        won't be aware of it.

        If you choose to use the binary_store.php plugin, you can also let
        ewiki generate URLs directly to the then stored data files if you
        just set the EWIKI_DB_STORE_URL constant.

        Please see the paragraph on this plugin for more informations on
        this.



        Arbitrary Binary Content
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
        Set the EWIKI_ACCEPT_BINARY constant, if you'd like to allow any
        binary file to be uploaded and saved in the database using the image
        upload function.  Uploaded files will show up as ordinary (except
        that "internal://" href prefix) links.

        Please also note the "plugins/download.php", which does a much
        better job than this constant.



$action and $id
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Inside of ewiki.php you'll see many occurrences of variables named $id and
$action. The $id refers to the current page, which usually is a string like
ThisPage, ThatPage, OrAnotherPage.

Because just having pages wasn't believed to be sufficient enough, there
is also a way to do something with them. That is what the $action tells.
The most often used $action is "view" and is automatically assumed when
no other $action was specified in the current ewiki URL. For non-existent
pages alternatively the "edit" $action may get used instead.

So the $action now delegates control about a requested page to a subfunc
or plugin of ewiki, so the stored data of the page can be used for
something (viewing being again the most common thing to do with it).

"action/ForTheCurrentPage" is how both often looks in conjunction (again:
if there is no "$action/" then "view/" will be assumed). Here the $action
appears in front of the page name separated by a slash. A pagename now can
contain slashes too, because ewiki can figure out, that "view/That/Page"
separates into the $action being "view" and $id is "That/Page" in this
example (the "view" gets mandatory in such cases).



        ewiki URLs
        ¯¯¯¯¯¯¯¯¯¯
        "$action/$id" is most commonly appended as "GET parameter" to an
        ewiki URL, after a string like "?id=" or "?page=" - you've already
        noticed that!

        There are of course other ways to design the URLs ewiki produces
        and uses, the PATH_INFO being one of the most favoured alternatives.
        (we had a paragraph on this earlier, see on top of this README)

        Other Wikis use different URLs too, but you can tweak ewiki easily
        to a different behaviour, because you have the chance to pass your
        $action and $id to ewiki_page() from different sources. And because
        URL generation is encapsulated into the function ewiki_script()
        you could easily change just a few lines to make them look like you
        desire.

        The $action can be passed as "?action=" parameter already (this is
        core support), so URLs could for example look like
        ".../my/wiki.php?id=ThisPage&action=view" ... or something alike.





  -------------------------------------------------------------------- 6 --



Appendix
¯¯¯¯¯¯¯¯
This sections lists things, that in fact have little to do with ewiki.



Apache config
¯¯¯¯¯¯¯¯¯¯¯¯¯
You must of course configure your Apache (or any other Webserver) to
feed .php scripts through the PHP interpreter, either libphp (Apache)
or the standalone CGI PHP interpreter.

If your Webserver supports mod_rewrite (Apache, Nanoweb), you may wish
to use it for URL beatification as described in "fragments/htaccess".




PHP config
¯¯¯¯¯¯¯¯¯¯
ewiki relies upon various settings of the PHP interpreter, which either
can be changed with entries in the php.ini or via option settings from
within .htaccess (only if you have Apache with libphp running).

A .htaccess option setting looks like:

  php_option register_globals off

while in the "php.ini" you would just write:

  register_globals = off



The recommended settings are:

  magic_slashes_gpc = off       ; This was enabled for old PHP versions
                                ; to help newbies writing more secure
         ; scripts in regards to database access (makes you wonder, which
         ; newbie actually could deal with databases). Nowadays this setting
         ; is still enabled by some providers, which try to keep their buggy
         ; site running.
         ; As a workaround (SlowSlowSlow, and not WikiWiki!) you can use
         ; fragments/strip_wonderful_slashes.php

  magic_quotes_runtime = off    ; This is even more awful than the above,
                                ; and if you cannot disable it, then you
         ; should not run ewiki on your Webserver. It is not believed to
         ; work correctly with that setting.

  register_globals = off        ; This setting is a security risk, if kept
                                ; enabled, because ewiki was written on a
         ; system where it is disabled (like with all newer PHP versions).
         ; It once was a very convinient setting, but the PHP language has
         ; long lost its sinmplicity and ease.

  register_argc_argv = on       ; is important for 'ewikictl' & Co.

  safe_mode = off               ; The so called 'Safe Mode' was introduced
                                ; for mass hosters, which didn't want to
         ; deal with security guidelines and needed an easy way to "secure"
         ; their servers. This setting cripples various PHP functions, and
         ; thus will disallow to use multiple ewiki extensions. The Safe
         ; Mode renders it completely useless and stupid to run a webserver
         ; on the Unix/Linux plattform, because its strenght was to invoke
         ; the various fast utilities and filters through pipes. And the
         ; lack of this opportunity then disables many ewiki extensions.

  allow_url_fopen = on          ; You will need these, if you want ewiki
  file_uploads = on             ; to deal with image caching and file
                                ; uploads (of course).

  error_reporting = ...         ; You should preferrably have this disabled,
                                ; even if ewiki.php already carries an
         ; error_reporting() call to do exactly that.
         ; The ewiki code is clean, but no longer cares about PHP "Notices"
         ; and sometimes also "Warnings" that much.

  cgi.force_redirect = 0        ; This is a stupid PHP option, that is only
                                ; there to fix a "/cgi-bin/ install" of PHP.

  cgi.fix_pathinfo = 0          ; PHP scrambles the PATH_INFO if you keep
                                ; this enabled. However Apache 1.3 often
         ; returns a broken value, so this may not matter to you anyhow.

  cgi.rfc2616_headers = ...     ; If you don't have Apache 1.3 running
                                ; (any earlier versions would do, and laters
         ; will be fixed again), then you should enable this; though ewiki
         ; does not rely on it.

  short_open_tag = ...          ; ewiki does NOT care

  output_buffering = ...        ; ewiki does NOT care



error numbers
¯¯¯¯¯¯¯¯¯¯¯¯¯
A few ewiki error messages are kept uninformative to prevent abuse of
security (misconfiguration) leaks through visitors. Usually you will find
an error number besides (in the tradition of OS/2 ;-), which you can then
lookup here:


ERROR #0257: is triggered by fragments/strike_register_globals to signalise
   that your PHP interpreter is still configured with register_globals
   enabled. The whole purpose of fragments/strike_... is to prevent variable
   injection from outside. Suddenly this is what happened if you've seen this
   message - but if you've discovered it yourself, then the reason for this
   security problem is a bogus extension plugin, which simply tried to
   reinsert values from one innovocation to another in a non-standard (too
   direct) way.
   Simply disable register_globals and unload the fragments/strike_...
   script to get rid of this error.