db/flat_files

If you don't have access to a MySQL database, then just include()
this plugin to save your wiki pages into simple text files (editable,
often called "flat files") inside a dedicated subdirectory. You
must set EWIKI_DBFILES_DIRECTORY+ in the 'ewiki.php' script to the
correct dirname. Don't forget, that it must be given either relative
to where the ewiki.php script is run from (like "./pages") or
absolute to the servers filesystem root (for example
"/export/htdocs/user528742/www.example.com/ewiki/pages") but NOT
relative to your WebSpaces+ DocumentRoot+!.

Usually "/tmp" will work, but this one is purged on every boot; and
therefore you should create a new sub directory (" mkdir ./pages ")
where all files go into. This newly created subdir must be made
»world-writable« using the command "chmod 777 ./pages", because the
WebServers+ user id counts when accessing it.

Usually you can do both from within your ftp client (the commands
are the same if you have a shell account):
ftp> cd .../ewiki
ftp> mkdir pages
ftp> chmod 777 pages
ftp> ls
-rw----r--    1 yourname yourname    57024 01. Jan 00:00 ewiki.php
-rw----r--    1 yourname yourname      512 01. Jan 00:00 index.php
drwx---r-x    2 yourname yourname     4096 01. Jan 00:00 init-pages
drwxrwxrwx    2 yourname yourname     4096 25. Feb 23:59 pages
drwx---r-x    2 yourname yourname     4096 01. Jan 00:00 plugins
-rw----r--    1 yourname yourname    33010 01. Jan 00:00 README
ftp> quit

In graphical FTP clients there is usually a menu entry to set
"access mode" or "access rights" (sometimes "file permissions") of
files and directories equally.

Again: don't forget to set the EWIKI_DBFILES_DIRECTORY+ constant to
the correct value!
If you create a subdirectory for the page files in the same directory
the main 'ewiki.php' script resides, you usually want to set the
config constant to just "./thesubdirectory" - here you could leave
out the "./" (not required as it only refers to the current path).

       Btw, the slash character will work in directory names on
       windoze systems too (mr. bill once had to introduce a
       hierarchical filesystem in DOS 2.0, but choosed the silly
       backslashes, so no one would notice where that idea was
       borought from ;)

The saved pages are in a format usually referred to as
"message/http" (like www service request) or "message/rfc822"
(internet mail).  They usually look like:
  +-----------------------------------------------
  | id: WikiPageName+
  | version: 1
  | flags: 1
  | author: 127.0.0.1:3054
  | created: 1046532697
  | lastmodified: 1046532697
  | refs: \nErfurtWiki\nNewestPages\n
  | 
  | !! WikiSourceContent+
  | <more-text>...

This file format can be exported by the "backup" tool, so you could
easily change from the MySQL database to the flat-files one, if
desired. Each page file exists in different versions, where the
version number is always appended to the saved pages` file name.

EWIKI_DBFILES_NLR+ converts newlines into the string "\n", but just
for the values of the metadata. So there shouldn't occur much
inconsistency, because the wiki content is saved binary safe in
those "flat files".

Filenames will be heavily converted on Win32 (urlencoded), while on
state of the art UNIX/Linux systems only a few characters are
replaced (slashes into backslashes) to match filesystem requirements.

Problems: dbff WikiPageNames+ are currently not case-insensitive on
UNIX-filesystems (while the MySQL-table is).
Hits won't get counted; I don't think it is that essential, and it
would take too much effort and time (file accesses) to support this.

Note: You cannot do a "backup" from a Unix server to a Win box by
using a stupid FTP program, because many characters are allowed in
Unix filenames but not on Win partitions. If you really want and
need to do so regularily, you should then setup ewiki with
EWIKI_DBFILES_ENCODE+ enabled from the very beginning. - The better
aproach was to use 'ewikictl' or 't_backup' or 't_transfer' for the
backup task.

prev << "db/flat_files"
next >> "db/fast_files"

---

You cannot modify the README.plugins file, but anyhow any ideas or suggestion should as usually get filed on BugReports, UserSuggestions or even better the README.plugins.Discussion.