1 NOTE: This file is again pretty outdated. But this time, there is no
2 way back. It is nearly impossible to correctly document ALL ewiki
3 plugins. But because most come with documentation inside (comments in
4 head area) this is not that big an issue.
6 You can still use this README part for reference. Just remember that
7 it is incomplete and does not list all plugins. Most notes are still
14 The plugins/ directory contains loads of ewiki extensions, which are
15 simply enabled by include()ing or melting them with the main ewiki
16 script. This file tries to provide an overview and explanations for
17 all the individual extensions.
21 1.2 melting / advanced plugin usage
23 2.1 built-in MySQL support
24 2.2 plugins/db/flat_files
25 2.3 plugins/db/fast_files
28 2.6 plugins/db/phpwiki13
29 2.7 plugins/db/binary_store
33 2.b plugins/db/ext_multi
34 2.c plugins/db/ext_subwiki
37 3.1 plugins/patchsaving
40 3.4 plugins/email_protect
41 3.5 plugins/spages (StaticPages)
42 3.6 plugins/pluginloader
44 3.8 plugins/feature/appendonly
45 3.9 plugins/feature/imgresize_gd
46 3.a plugins/feature/imgresize_magick
47 3.b plugins/feature/imgfile_naming
50 3.e feature/refererlog
54 4.1 plugins/action/diff
55 4.2 plugins/action/translation
56 4.3 plugins/action/like_pages
57 4.4 plugins/action/raw
60 4.7 action/translation
61 4.8 action/relatedchanges
62 5 plugins related to hypertext links
63 5.1 plugins/linking/tcn
64 5.2 plugins/linking/plural
65 5.3 plugins/linking/autolinking
66 5.4 plugins/linking/link_css
67 5.5 plugins/linking/link_icons
68 5.6 plugins/linking/link_target_blank
69 5.7 plugins/linking/linkexcerpts
70 5.8 plugins/linking/linkdatabase
71 5.9 plugins/linking/instanturls
72 5.a plugins/linking/titlefix
73 5.b plugins/interwiki/intermap
74 5.c plugins/interwiki/editable
77 6.1 plugins/appearance/listpages_br
78 6.2 plugins/appearance/listpages_ul
79 6.3 plugins/appearance/listpages_tbl
80 6.4 plugins/appearance/fancy_list_dict
81 6.5 plugins/appearance/title_calendar
83 7.1 plugins/page/powersearch
84 7.2 plugins/page/pageindex
85 7.3 plugins/page/wordindex
86 7.4 plugins/page/imagegallery
87 7.5 plugins/page/aboutplugins
88 7.6 plugins/page/orphanedpages
89 7.7 plugins/page/wantedpages
90 7.8 plugins/page/since_updates
91 7.9 plugins/page/textupload
92 7.a plugins/page/wikidump
93 7.b plugins/page/interwikimap
94 7.c plugins/page/hitcounter
95 7.d plugins/page/scandisk
96 7.e plugins/page/wikinews
97 7.f plugins/page/wikiuserlogin
98 7.10 plugins/page/randompage
99 7.11 plugins/page/fortune
100 7.12 plugins/page/ewikilog
101 7.13 plugins/page/phpinfo
102 7.14 plugins/page/README
103 7.15 plugins/page/recentchanges
105 8.1 Other WikiWares markup
106 8.2 plugins/markup/css
107 8.3 plugins/markup/css_singleat
108 8.4 plugins/markup/footnotes
109 8.5 plugins/markup/asciitbl
110 8.6 plugins/markup/complextbl
111 8.7 plugins/markup/htmltbl
112 8.8 plugins/markup/rescuehtml
113 8.9 plugins/markup/rendering_null
115 8.b markup/naturallists
116 8.c markup/fix_source_mangling
118 8.e markup/table_rowspan
120 8.10 markup/braceabbr
121 8.11 markup/definitionlinks
130 a.1 plugins/aview/backlinks
131 a.2 plugins/aview/linktree
132 a.3 plugins/aview/toc
133 a.4 plugins/aview/posts
134 a.5 plugins/aview/threads
135 a.6 plugins/aview/subpages
136 a.7 plugins/aview/downloads
137 a.8 plugins/aview/imgappend
138 a.9 plugins/aview/piclogocntrl
139 a.a plugins/aview/control2
140 a.b plugins/edit/pageimage
141 a.c plugins/edit/authorname
142 a.d plugins/edit/deletebutton.js
143 a.e plugins/edit/templates
145 a.10 plugins/edit/flags
146 a.11 plugins/edit/minor
147 a.12 plugins/edit/warn
148 a.13 plugins/edit/lock
149 a.14 plugins/edit/spellcheck/
150 a.15 edit/spam_deface
153 b.1 plugins/filter/f_fixhtml
154 b.2 plugins/filter/search_highlight
155 b.3 plugins/filter/fun_chef
156 b.4 plugins/filter/fun_upsidedown
157 b.5 plugins/filter/fun_wella
158 b.6 plugins/filter/fun_screamomatic
159 c BloatWiki extensions
160 c.1 plugins/module/calendar
161 c.2 plugins/module/downloads
162 c.3 plugins/module/tour
163 c.4 plugins/meta/meta
164 c.5 plugins/meta/builtincategories
165 c.6 plugins/meta/f_title
167 d.1 plugins/lib/cache
168 d.2 plugins/lib/speed
169 d.3 plugins/lib/mime_magic
170 d.4 plugins/lib/navbar
171 d.5 plugins/lib/protmode
172 d.6 plugins/lib/save_storevars
181 f.3 plugins/auth-liveuser/
182 10 separate "extra" tarball
183 11 Updates + How to deal with tweaked code
190 -------------------------------------------------------------------- 6 --
196 While ewiki is a rather monolithic script, it allows for extension by
197 various plugin hooks (= the internal $ewiki_plugins array). This keeps
198 the core small (just one script) and fast, but also easy to use (not too
199 cluttered user interface).
201 However for advanced needs, there is always the option to add a required
202 function very easily. Of course some plugins slow down your Wiki (for
203 example markup extensions often do), so it was unwise to enable all at
204 once. Also a few plugins can be incompatible to each other (very divorce
205 goals), and some require further configuration and setup in order to
208 You may therefore also check out the standalone 'setup.php' script, which
209 also provides a simplified and _shortened_ overview of the easier to use
210 plugins. This utility also can generate the appropriate 'config.php' for
213 The structure of the plugins/ directory is purely presentational, ewiki
214 does not depend on accessibility of that directory; none of the paths is
215 hardcoded anywhere. This is because YOU are responsible for loading plugins,
216 the core script does never load anything on itself. The only exceptions to
217 this rule are: spages, mpi, and the pluginloader.
223 The plugins/ directory is full of .php scripts (the plugins),
224 accompanied by a .meta file each. These are textual data files,
225 that explain what's in the plugin. This data is used for the
226 SetupWizard and tools/setup tool and by other so called "plugin
229 Read "doc/PluginMetaFiles" if you want to find out more. Ignore
230 those files otherwise.
235 To enable an extension, you simply load the according plugin(s)
236 using the PHP include_once() function, like you do with the core
239 include_once("plugins/email_protect.php");
240 include_once("plugins/page/textupload.php");
242 include_once("ewiki.php");
244 Usually it does not matter, if you load the plugins before or
245 after the ewiki script. If this makes a difference, the plugin
246 documentation would mention it.
248 (include_once() is recommended and standard since R1.02b)
252 melting / advanced plugin usage
253 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
254 The design of the ewiki script and the extension hooks and all
255 plugins makes it also possible to "melt" the core script with the
256 plugin files. This is useful to again have all functionality in
257 a single script, and also allows PHP to run it slightly faster
258 (because then the PHP language 'parser' gets invoked just once).
260 You would simply use the cat(1) utility (or "type" under DOS/Win)
261 to merge the plugins with the core script as follows:
263 cat plugins/email_protect.php >> ewiki.php
264 cat plugins/page/textupload.php plugins/notify.php >> ewiki.php
266 See also the paragraph on "monsterwiki building" in the main
267 [README] file. (The 'tools/mkhuge' script did previously what's
270 Nowadays you would use the "tools/setup" console script (under
271 Linux) or the SetupWizard to make a monsterwiki.
278 The ewiki.php core script contains a database request function which is
279 tailored to a MySQL database. However that function is already prepared
280 to chain to another "database abstraction" function if desired.
284 built-in MySQL support
285 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
286 The first implemented, and still most recommended way to use
287 ewiki is with a MySQL (3.21 or later) database. RDBMS work more
288 reliably and of course much faster than any other of the ewiki
291 As the core ewiki_database() inside ewiki.php already includes
292 the MySQL database calls, there is usually nothing to do, but
293 opening a database connection before ewiki.php is included()
295 Please look at the top of this README for an example.
297 As PHPs mysql_() functions don't require a db resource link to
298 be given anymore, the ewiki_database() function does not pass
299 and thus does not require it too. (If you use more than one MySQL
300 database, you should take care that ewiki always uses the one you
307 If you don't have access to a MySQL database, then just include()
308 this plugin to save your wiki pages into simple text files (editable,
309 often called "flat files") inside a dedicated subdirectory. You
310 must set EWIKI_DBFILES_DIRECTORY in the 'ewiki.php' script to the
311 correct dirname. Don't forget, that it must be given either relative
312 to where the ewiki.php script is run from (like "./pages") or
313 absolute to the servers filesystem root (for example
314 "/export/htdocs/user528742/www.example.com/ewiki/pages") but NOT
315 relative to your WebSpaces DocumentRoot!.
317 Usually "/tmp" will work, but this one is purged on every boot; and
318 therefore you should create a new sub directory (" mkdir ./pages ")
319 where all files go into. This newly created subdir must be made
320 »world-writable« using the command "chmod 777 ./pages", because the
321 WebServers user id counts when accessing it.
323 Usually you can do both from within your ftp client (the commands
324 are the same if you have a shell account):
329 -rw----r-- 1 yourname yourname 57024 01. Jan 00:00 ewiki.php
330 -rw----r-- 1 yourname yourname 512 01. Jan 00:00 index.php
331 drwx---r-x 2 yourname yourname 4096 01. Jan 00:00 init-pages
332 drwxrwxrwx 2 yourname yourname 4096 25. Feb 23:59 pages
333 drwx---r-x 2 yourname yourname 4096 01. Jan 00:00 plugins
334 -rw----r-- 1 yourname yourname 33010 01. Jan 00:00 README
337 In graphical FTP clients there is usually a menu entry to set
338 "access mode" or "access rights" (sometimes "file permissions") of
339 files and directories equally.
341 Again: don't forget to set the EWIKI_DBFILES_DIRECTORY constant to
343 If you create a subdirectory for the page files in the same directory
344 the main 'ewiki.php' script resides, you usually want to set the
345 config constant to just "./thesubdirectory" - here you could leave
346 out the "./" (not required as it only refers to the current path).
348 Btw, the slash character will work in directory names on
349 windoze systems too (mr. bill once had to introduce a
350 hierarchical filesystem in DOS 2.0, but choosed the silly
351 backslashes, so no one would notice where that idea was
354 The saved pages are in a format usually referred to as
355 "message/http" (like www service request) or "message/rfc822"
356 (internet mail). They usually look like:
357 +-----------------------------------------------
361 | author: 127.0.0.1:3054
\r
362 | created: 1046532697
\r
363 | lastmodified: 1046532697
\r
364 | refs: \nErfurtWiki\nNewestPages\n
\r
366 | !! WikiSourceContent
369 This file format can be exported by the "backup" tool, so you could
370 easily change from the MySQL database to the flat-files one, if
371 desired. Each page file exists in different versions, where the
372 version number is always appended to the saved pages` file name.
374 EWIKI_DBFILES_NLR converts newlines into the string "\n", but just
375 for the values of the metadata. So there shouldn't occur much
376 inconsistency, because the wiki content is saved binary safe in
379 Filenames will be heavily converted on Win32 (urlencoded), while on
380 state of the art UNIX/Linux systems only a few characters are
381 replaced (slashes into backslashes) to match filesystem requirements.
383 Problems: dbff WikiPageNames are currently not case-insensitive on
384 UNIX-filesystems (while the MySQL-table is).
385 Hits won't get counted; I don't think it is that essential, and it
386 would take too much effort and time (file accesses) to support this.
388 Note: You cannot do a "backup" from a Unix server to a Win box by
389 using a stupid FTP program, because many characters are allowed in
390 Unix filenames but not on Win partitions. If you really want and
391 need to do so regularily, you should then setup ewiki with
392 EWIKI_DBFILES_ENCODE enabled from the very beginning. - The better
393 aproach was to use 'ewikictl' or 't_backup' or 't_transfer' for the
400 NOTE: The db_fast_files has been merged into db_flat_files, so both
401 formats can be read now - at the same time! Updated or new pages will
402 however always be written in the file format determined by
403 EWIKI_DB_FAST_FILES (defaults to 0) - edit the "db_flat_files.php"
404 script to change that constant setting, or even add it to your
405 "config.php" so it was always present.
407 While "db_flat_files" allows you to edit the WikiPage files (using
408 any simple text editor), the "db_FAST_files" plugin saves the pages
409 in a binary&compressed format (utilizing PHP's serialize function).
411 This generally leads to a speed enhancement. Additionally this also
412 allowed the PageHit counting to be activated (which is off in plain
415 So you may wish to use this plugin in favour of the older
416 db_flat_files. And as now both methods are available at the same
417 time, you can switch whenever you want.
419 Most of the setup guide from above is true for this one, too.
421 An additional configuration constant introduced here is
422 EWIKI_DBFILES_GZLEVEL, which tells the PHP internal zlib how much
423 time to spend on compression of the saved pages. Usually the zlib
424 uses a default of 5, but for speed purposes it is set to 2 here. You
425 can also set the constant to 0 so the files will get saved
426 uncompressed (but still in 'binary' format). A value of 9 will give
427 you the smallest possible files, but this takes a little more CPU
428 cycles (a bit slower).
430 This plugin was contributed by Carsten Senf.
436 If you use a relational SQL database other than MySQL, then you
437 may want to give this plugin a try. It itself provides a wrapper
438 for the PHP database access wrapper libraries ADOdb, PEAR::DB and
440 These wrappers themselves provide unified access to various SQL
441 databases in contrast to the many highly different db access
442 functions of PHP. Each of these db access wrappers has advantages
443 and disadvantages and so none of them is really widespread and many
444 users of course only jump on one of these trains. Because ewiki now
445 tries to be 'library' it will use whatever database access wrapper
446 you already have running on your site or container CMS, and the
447 highly simplified anydb_*() now tries to make use of it.
449 The plugin is based upon the current MySQL database backend, and
450 thus may not be compatible to all proprietary SQL variants.
452 Before you can use the db_any plugin you must ensure that you
453 either already have the PHP dbx extension dll loaded or the PEAR::DB
454 or ADOdb include files loaded. db_any will like to see an opened
455 database connection inside of the global '$db' variable. If
456 yoursite.php hasn't already a connection opened when ewiki.php
457 gets included, then you should preferably choose to use the
458 anydb_connect() function to do so (it will choose from PEAR::DB,
459 ADOdb and PHP dbx interfaces).
460 The '$db' connection handle can be shared between your site and
461 ewiki as long as it is a handle for one of the mentioned database
462 access wrapper libraries.
464 Btw, "plugins/db_adodb" was obsoleted by this.
470 including() this plugin enables ewiki to store the WikiPages in the
471 Berkeley DB file given with the EWIKI_DBA constant. Your PHP binary
472 must be compiled with either the "dba" or the "dbm" extension to use
473 this (and the dba extension requires at least one other database
476 The plugin has a built-in list of preferred dba database types, but
477 it respects the filename extension of EWIKI_DBA. For example
478 "wiki.db3" would create a DB3 database file, while "wiki.gdbm"
479 resulted in a GDBM file, if that php extension was available.
481 The PHP dba extension can support the db types (if compiled for):
490 If you have the PHP "dbm" extension enabled, wrapper functions will
491 get enabled, so this works even if the "dba" extension is not there.
493 The .flatfile is often available even if you haven't compiled your
494 PHP binary for anything else than "dba". This may also often be
495 faster than one of the db_flat_files plugins.
497 If EWIKI_DBFILES_GZLEVEL is set to a value from 1 (fast) till 9
498 (very good compression, but slow), the saved pages will get
499 compressed inside the dba database. With 0 this feature gets
506 The original ewiki database table structure was compatible with the
507 one used in PhpWiki version 1.2.x, however it turned out that the
508 PhpWiki project has yet not stopped completely and choosed to
509 implement a more relational table structure with version 1.3
511 This plugin is only meant for transition __from__ PhpWiki v1.3.x to
512 ewiki, it should NOT be used to connect ewiki with PhpWiki forever.
514 Write access is disabled per default, but available. However it is
515 probably not fully compatible with the database abstraction and usage
516 of PhpWiki, so it is likely to corrupt your database if you use it
517 for a longer period of time. This warning is mainly because the
518 'latestmajor', 'latestminor and 'minor_edit' rows in the PhpWiki
519 database, because such stuff is not used by ewiki at all. ewiki also
520 tries to put some of the pages meta data into places where it could
521 eventually confuse PhpWiki.
522 Write access is however done nearly as safe as within the ewiki
523 database access layer (INSERT statement to not overwrite existing
526 Again: this plugin is in no way meant to encourage you to keep your
527 old PhpWiki database! ;>
528 Please see also "tools/ewiki_convertdb.php".
530 If you temporarily enable this plugin within the default/example
531 "config.php" or the "tools/ewiki_tools_config.php" you can also
532 utilize the very powerful 'ewikictl' cmdline utility to generate a
533 copy of your PhpWiki database in one of the backup formats suitable
534 for later use with ewiki.
540 Is a hack into the ewiki core, which will store binary/uploaded
541 files outside of the default ewiki database (as plain files in a
544 Please also see the documentation on top of the plugin file.
546 Per default ewiki can store "binary" entries beside ordinary text
547 pages in the database. If you'd like to keep uploaded files/images
548 out of the db, then this plugin/hack will help. It intercepts ewiki
549 and saves uploaded data into a plain data file, and instead creates
550 a "binary symlink" in the database for it (just the binary meta
551 data will get stored, with a hint on where to later access the plain
554 This may sometimes be a speed enhancement and reduces size of the
555 database, however it has the drawback that only the main ewiki
556 script can handle this transparently and all admin tools/ fail to
557 deal with the stored plain data files (no backup support and so on).
559 By setting the EWIKI_DB_STORE_URL constant correctly (corresponding
560 to your wiki setup and where you store the data files, compare with
561 EWIKI_DB_STORE_DIRECTORY) you can make ewiki create URLs directly
562 to where the stored plain data files reside (they do not contain
563 ewiki database meta data, and thus could be accessed directly by
564 http clients/browsers).
566 Please be sure to configure this plugin by setting _DB_STORE_DIRECTORY
567 to something more useful than "/tmp", so your uploaded files will
568 still be there after a reboot.
574 The "dzf2" database plugin provides a flat file database (no SQL),
575 which stores its files compressed (like db_fast_files), but also
576 plattform-independent and in a case-insensitive manner (which is
577 not possible with dbff on Unix filesystems). It introduces a few
578 other enhancements, that make it a bit quicker than the flat_files
580 Also, it creates a unique sub directory tree, to provide faster
581 access times (disk/directory reading).
587 This fun plugin stores files into a ZIP file. It is not
588 recommended for productive setups, and requires the commandline
589 Unix 'zip' utility to operate (DOS pkzip may also work).
595 Can access a remotely located ewiki database via PHP-RPC. Needs
596 a bit more setup (creating an interface and setting up passwords).
597 Could be used in conjunction with ext_multi to only have a few
598 pages located remotely.
604 Multiple database backends can be joined virtually into one DB for
605 ewiki using this extension. Needs a bit more setup, because you must
606 assign one of the backends as main database, where changes are
607 written to (exclusively).
613 Can automatically fragment your database into separate namespaces,
614 but must however be enabled from the beginning. You need to prepare
615 yoursite wrapper around ewiki to detect the currently accessed
616 Wiki; what however is useful to easily set up a WikiFarm.
622 Provides a compatiblity layer for database backends after the older
623 non-OO interface (which is still supported in the core script).
629 Some really cool features are put into extension plugins, and the most
630 important, recommended and most often used ones are listed in this section:
636 If two users concurrently edit a page, then only the first save
637 attempt will succeed; which the second user is told by the "This
638 page version was already saved" failure message.
640 This plugin works around this by passing the contents of the
641 concurrent versions through the 'diff' and 'patch' utilities, which
642 often merges the two different modifications in a new version that
643 can be saved into the database so there is no need for the failure
650 This plugin enables users to get notified, whenever someone changes
651 a watched page. To enable 'watching' one must just place an email
652 address into the page with following syntax:
653 [notify:mail@example.com]
655 This bracket will be invisible, when a page is viewed, so it can be
656 placed anywhere. The notifications will be sent to this address
657 as long as the tag is there.
659 If one wishes to receive notification messages in another language,
660 this just needs to be added after a comma or semicolon, like:
661 [notify:pop3@example.net,de]
662 This is often only necessary for the generic TLDs .com .org .net,
663 or where language code and TLD differ.
669 Introduces magic markup for page redirection (switching to another
670 page). Possible notations are:
675 The EWIKI_JUMP_HTTP setting tells this plugin to send a Location:
676 and redirect HTTP status when encountering a page [jump:]. Else
677 this plugin will show up the JumpDestination page without notifying
678 the browser about it.
680 It is also possible to perform InterWiki jumps, just be using the
681 common InterWikiMoniker: syntax, but generic URLs are also allowed.
683 [jump:WardsWiki:WelcomeVisitors]
684 [jump:http://www.example.org/]
690 This plugin 'ciphers' all valid email addresses inside a WikiPage
691 for protection against automated spambots. Additionally it
692 throws fake/trap email addresses to spammer databases :>
694 It ist not integrated into the core script, because some people
695 may prefer to have email addresses visible (intranet usage).
696 However it is HIGHLY RECOMMENDED to enable this plugin. Despite
697 its file size it is rather fast.
703 The "StaticPages"-plugin allows ewiki to access files in a given
704 directory. If these files are in text format, ewiki will parse them
705 as WikiPages. But if you put files with an extension .html, .htm or
706 .php into one of the specified StaticPages` directories they will
707 be returned as is from ewiki_page() - the .php files will of course
708 get executed and their output is returned.
710 The basename of the files in the directories to be used by spages
711 will make up the WikiPageName with which the files will be
714 Any given directory (see on top of plugins/spages.php) will be read
715 recursively. So files in a subdirectory will get available as a
716 page with a name like "subdir/FileName". If the name of the
717 subdirectory contains a dot at the end, then the slash will be left
718 out in favour of a dot: resulted in "subdir.FileName" for example.
720 PHP scripts in a spages directory however have some restrictions,
721 like not being able to return headers() or to access most global
722 variables without use of the $GLOBALS[] syntax. If you rely on
723 such functionality you should rather write an ordinary page plugin
724 (which in fact is often much easier).
725 From the output of .html and .php scripts only the parts between
726 <body> and </body> will be returned as page content. Any <html>
727 head area will get stripped, as it would lead to completely invalid
728 html code if it was returned as is by ewiki_page() into yoursite.
730 To let this plugin load pages from directories, you should either
731 edit the array on top of this plugin file, or define() the
732 EWIKI_SPAGES_DIR (before! including the spages.php script), which
733 then also would be read in.
734 Alternatively you could call the ewiki_init_spages() function
735 yourself to register a directory for processing (after! loading the
738 include("plugins/spages.php");
739 ewiki_init_spages("/var/www/wiki/staticpages/");
741 You could also use this plugin to inline the ewiki database tools/
744 Btw, it is very easy to make a StaticPage from a ewiki page plugin
745 and vice versa. Please also note the 'tools/mkpageplugin' which can
746 convert anything used as StaticPage into a page plugin.
752 The pluginloader plugin automatically loads ["action"] and ["page"]
753 plugins, whenever necessary. This allows to skip dozens of
754 include() statements within the config.php (which most always just
755 slow down script startup). It is configured via a static array,
756 that defines which plugins are allowed to be automatically invoked
758 Detailed explanaition is available within this script.
764 Handles database initialization using the distributed standard Wiki
765 files from './init-pages'. Unlike the ewiki-builtin function to
766 perform that task, this plugin first outputs informational notes
767 to the user, prior database initialization.
768 Once you have your SQL or ./files database initialized, you should
769 disable this plugin (it then isn't required anymore).
775 This plugin (a family of) implements the actual support for the
776 _DB_F_APPENDONLY page flag. When the flag is set, and this plugin
777 active, then ordinary users can further only append text to the
778 page, and won't be able to edit the earlier written parts of it. So
779 this implements a much softer approach than the _READONLY page
782 Also this plugin comes in three flavours, but you can often only
785 "appendonly" - Really allows just additions to be made to the page,
786 each new separated by a horizontal bar.
788 "appendwrite" - Allows to insert a page separator, which protects
789 the upper part from getting edited by ordinary
790 users. Everything below a horizontal bar (denoted
791 by at least 16 minus signs) or a double horizontal
792 bar remains editable by all users.
793 This plugin activates only if the _APPENDONLY and
794 _WRITEABLE flag is set.
796 "appendcomments" - stores page additions in an separate database
797 entry marked with _DB_F_PART, but allows this part
798 to get edited as whole (like "appendwrite" plugin).
800 The last one is probably not very useful, as it generates some
801 overhead and in fact is a collection of various workarounds to
802 accomplish the desired functionality (so it may prove little
809 Was extracted from the core during the R1.00f development releases.
810 Automatically rescales uploaded images, if they are larger than
812 As it uses the gd2 library, there must be support for this in your
813 PHP binary. There are a lot of problems on Win32 systems, and also
814 some Linux binarys (-dev ones) crash constantly if you load this
815 plugin but don't have the libgd activated or available.
819 feature/imgresize_magick
820 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
821 Rescales uploaded images via the ImageMagick utility "mogrify",
822 which is usually only available on UNIX systems. It should however
823 be fairly simple to make this plugin work with some other image
824 manipulation tool (at least with Linux).
828 feature/imgfile_naming
829 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
830 This plugin overrides the default name assignment code for uploaded
831 images, and keeps the original file name to a certain degree (unless
832 it is considered frivolously silly, like "DSC00001.jpeg" or such
835 You could now also disable the "internal://" prefix usuage, as ewiki
836 can distinguish _TEXT from _BINARY database entries now for SQL
843 Checks all known ewiki input variables to prevent some possible
844 injection / overflow problems.
850 Will automatically add links to pages, when some PingBack-enabled
851 blog (weblog) links it. Also will send out such pings to other
852 sites whenever an URL is added on any WikiPage. Verifies incoming
859 When coming from an external site, adds the Referer: URL to the
860 current page, after its validity has been verified.
866 Allows you to later install .xpi plugins by simply uploading them
867 with the "PlugInstall" page. You need to first define an
868 administrator password (EWIKI_ADMIN_PW constant). There are also
869 remote .xpi plugin directories which you can browse and allow
870 for click-and-run addition of new extensions.
872 All plugins can be disabled through the admin interface, or at
873 least can be uninstalled again (for page plugins).
875 With a loaded phpjs interpreter you can also allow your users to
876 install the safe / sandbox-executed .jpi page plugins without
883 If you don't need to install new or control old xpi plugins,
884 you can get rid of the "PlugInstall" interface by using xpi0
885 instead of the big xpi extension.
891 Action plugins are those, that can be activated ON individual pages. And
892 usually are shown as links below a page. The ewiki-builtin EditThisPage,
893 BackLinks and PageInfo are ["action"] plugins for example.
899 Enables to view the differences between two saved page versions
900 (what changes somebody has done to the page), but it is rather
901 stupid and guessworking in how it does so.
903 On a Unix system you might want to use gnu_diff instead.
909 This plugin adds a link to the GoogleLanguageTools or AltaVista
910 BabelFish, which then remotely translated the current page into
911 the users preferred language. It has support to detect the lang
912 of the current pages content, to redirect to the right service.
918 LikePages is a search feature of WardsWiki, which scans for
919 WikiPages whose name is somewhat similar to the one of the current
920 page (the pagename must be made up of the same WikiWordParts so a
927 Can be used to download the unrendered Wiki source of a page.
933 Adds an action link to every page, which allows to retrieve
934 RSS/Atom feeds for it, if the plugins/lib/feed extension was
936 Also provides a Wiki-wide feed as [RSS] page or on RecentChanges
943 Adds the "quickdiff" action to the info/ page, which allows to
944 review changes over all historic versions at once.
950 Adds a link to Babelfish/GoogleLT to translate the current page
951 into whatever the visitor has configured as most preferred lang.
955 action/relatedchanges
956 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
957 Shows when back- and fore-linked pages where changed last.
961 plugins related to hypertext links
962 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
963 The linking/ plugin group deals with how links inside the Wiki will look and
964 work. Some of them would also fall the "core enhancements" group, while
965 others are just handy or for link beatification.
971 ewiki evaluates the Accept-Language HTTP header modern browsers
972 send with each request. This plugin now automatically brings up
973 a variant of the currently requested page if it finds a match in
974 the database. To make it work, you need to create pages with
975 language suffixes in their names like:
983 Note, that there can always be one page in each name group without
984 that suffix. This page then will be assumed to be in the default
985 language (en) set by EWIKI_DEFAULT_LANG.
987 If multiple page versions are available, then a list will be
988 printed above the page title to allow users to override the
989 prefered language guess of this plugin.
995 This plugin tries to alias plural and singular page names against
996 each other. That is, "WikiPage" will be shown, whenever "WikiPages"
997 was requested (and vice versa).
1003 The autolinking plugin allows to have automatic links inside the
1004 Wiki for words which exist in the database, but are no real
1005 WikiWords. This is made possible by the companion StaticPage
1006 admin plugin "spages/Admin/PrepareAutolinking", which must be
1007 invoked from time to time to update the db cache entry, which the
1008 autolinking plugin utilizes.
1014 Adds CSS classes to the links generated by the Wiki page formatting
1015 kernel, which then allow you to colorize (or to otherwise change
1016 appearance of links) via a style sheet.
1022 The link_icons plugin prepends icon <img>s before registered link
1023 types, like the link_css plugin adds class="..." attributes to the
1024 html formatted links in every page.
1028 linking/link_target_blank
1029 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1030 Adds 'target="blank"' to link tags <a>, which will result in most
1031 browsers opening pages in a new window. Note: this is never
1036 linking/linkexcerpts
1037 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1038 Adds a short preview text (with <a title="...">) to every link of
1039 a page. This however requires multiple additonal database accesses
1040 (slower) and could enlarge delivered .html page sizes dramatically.
1044 linking/linkdatabase
1045 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1046 Is a page plugin, which provides a nearly compliant implementation
1047 of the page and link structure export function known from the UseMod
1048 WikiWare and MeatBall:LinkDatabase. This is useful for contributing
1049 to the upcoming InterWikiBatabase and BorgWiki.
1055 Allows to specify URL abbreviations on one or more summary pages.
1056 This can be done using a table or a definition list to assign
1057 each URL a title, which then can be used on other pages as square
1060 The 'instanturl_find' plugin in addition allows to use the [find:]
1061 moniker to perform partial searches in the list of URL
1062 abbreviations, but also in the list of interwiki monikers. As
1063 fallback it searches for matching page names or redirects to
1070 Allows to swap [title|PageName] in square brackets [Page|title],
1071 because that can easily be detected, if the page already exists.
1077 This plugin (in fact only a general include) extends the list of
1078 known InterWiki: prefixes with a more complete set created from
1079 the MeatBall interwiki.map.
1085 Provides automatic read-in of the special page "EditableIntermap",
1086 so users can provide shortcuts for commonly referenced sites in a
1087 table or definition list.
1093 Adds pseudo-monikers for the "XHTML Friends Network". You can
1094 simply mix the well-known prefixes like an InterWiki moniker
1095 before any page name.
1096 [met:friend:neighbor:parent:UserName]
1098 This will translate into the typical
1099 <a href="?id=UserName" rel="met friend ..."> then.
1105 There are various plugin hooks within ewiki, which allow to mangle text
1106 strings and data immediately before it would be returned as output.
1110 appearance/listpages_br
1111 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1112 This plugin will produce <br> separated lists (for SearchPages,
1113 PageIndex, MostVisitedPages, and so on).
1117 appearance/listpages_ul
1118 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1119 Creates real <ul> lists (WordIndex, CreatedPages, ...) instead of
1120 the · ones, ewiki core would usually return.
1124 appearance/listpages_tbl
1125 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1126 The listpages_tbl plugin outputs a table instead of the ordinary
1127 page lists (PageIndex, UpdatedPages, ...). You need to edit its
1128 source to set colours to fit your site layout.
1132 appearance/fancy_list_dict
1133 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1134 The WordIndex and PageIndex plugins (unlike the other page list
1135 returning ones like SearchPages and UpdatedPages) can utlize this
1136 plugin to output a pretty dictionary like listing of pages.
1140 appearance/title_calendar
1141 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1142 Changes the titles of calendar plugin entries in the database into
1143 a more readable format for page lists (PageIndex, PowerSearch,
1144 UpdatedPages, and so on).
1150 The page plugins provide additional "generated/internal" pages, which have
1151 a standard WikiWordPageName and can thus be referenced easily from within
1152 ordingary WikiPages. But they are of course uneditable (because their
1153 content is 'hardcoded' as PHP code) and most action/ plugins cannot perform
1154 any function on them.
1156 With the rise of the StaticPages plugin, the page plugins are almost
1157 outdated, because all their code could now be extracted into a StaticPage
1158 file, so their code had to be loaded only on request (instead of including()
1159 them regardless if they're needed or not, how it currently is done).
1165 This plugins provides a (probably) better search function
1166 with the default page name "PowerSearch". It tries to guess
1167 a value, which tells something about how good a page matches
1168 the searched words and orders the found pages list by this
1169 (possibly not very useful) value. It prints the top 10 results
1176 Lists all pages found in the database alphabetically.
1182 Lists the word parts of all wiki pages, but requires the
1183 powersearch plugin to be present, because the result is redirected
1184 to there as usually many of the listed words belong to multiple
1191 Outputs a page containing all cached/uploaded images. The
1192 images are currently not rescaled to fit on the page; this
1193 work is left to the browser.
1200 Lists all registered plugins (mpi, page, action, task/core). The
1201 name refers to the "about:plugins" page present in recent browsers.
1207 Shows up a list of pages, that exist, but are not linked from any
1208 other pages. These is often also called dead pages.
1210 Note that this plugin does not take into account, if any page
1211 can be reached from the frontpage - such a hypertext tree test
1212 would require much more work than realized in here.
1218 Returns a list of pages to which QuestionMarkLinks? currently
1225 Provides a list of pages with actualization times.
1231 The virtual TextUpload plugin allows to insert new WikiPages by
1232 uploading text files. It can convert from various formats into Wiki
1233 content, including some proprietary Office file formats, if one of
1234 the possibile filters is avaiable (Unix style file piping).
1235 It also can extract multiple files from a Tarball or ZIP archive
1236 if the according utilities are available (even on DOS/Win systems).
1242 Allows to download a gzipped tarball containing all readily
1243 rendered pages as .html files and also images.
1249 Shows up the currently in use InterWikiMap.
1255 Sums up the individual {hits} count of all pages and returns the
1262 Presents an unserious statistic.
1268 Returns the most recently added pages in an overview, that
1269 incorporates a small fragment from the content of those newly added
1276 Allows to set a free-form username, which then would be stored into
1277 the database whenever a page was edited. It gets meanwhile saved in
1278 the http client as cookie, but can afterwards be evaluated as
1279 $ewiki_author, so the according field in the database entries
1280 contains a bit more than just the IP address when a changed page
1282 Note: this does not do any sort of real authentication or
1288 Shows up a randomly choosen page from the database.
1294 Calls the Unix /usr/games/fortune program and prints out returned
1301 Allows to review the content of the 'ewiki.log' file.
1307 Shows the settings of your PHP interpreter.
1313 Can parse the distributed README file and make a hypertext
1314 presentation from it, for easier reading of the Wiki documentation.
1315 It is printed in <pre> text, but with WikiLinking enabled (which
1316 however is rarely used in the README file). It additionally
1317 presents the README.de and README.auth files.
1323 Provides a fancy RecentChanges page (like the built-in "UpdatedPages")
1324 in either UseMod or MoinMoin style. The appearance can be configured
1325 by changing the plugin registration at the top of this script.
1326 Both variants take the {meta} log entry into account, which users can
1327 set if the aview/aedit_log plugin is loaded also.
1333 The ewiki rendering core is rather fast and consolidated, that was the goal.
1334 However if you ever happen to need more functionality, this can be added
1335 easily by the use of plugins.
1337 Several are already available to emulate the WikiMarkup of other commonly
1342 Other WikiWares markup
1343 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1344 The WikiWorld still lacks a unified markup (and thus also the
1345 interchangeablity that made html THE standard it is today), and
1346 while ewiki usues nearly MeatBall:WikiMarkupStandard, you may want
1347 to reuse existing pages from another Wiki.
1349 Currently we provide emulation for:
1353 * bbcode (BulletinBoard, not a Wiki)
1355 But please see the individual files on which (additional) markup
1358 These plugins on occasion only register their markup within
1359 $ewiki_config["wm_*"] settings, but often just perform
1360 pre-conversion of foreign markup by utilizing the ["format_src"]
1361 plugin hook (they then pre-convert page content to use ewiki
1362 markup rules before the ewiki_format() kernel performs
1369 CSS markup allows you to assign visual styles (or semantic CSS
1370 class names) to a block of text (paragraph) or to pieces of text.
1371 @@ is used to start a styled area. The @@ must be immediately
1372 followed by either a CSS class name (without the dot) or with
1373 CSS instructions without any whitespaces.
1374 The following text (after the @@, the class name and a space) will
1375 then be assigned the class until a (possible) next @@ without
1376 attached classname or style definition.
1378 If the @@ occurs at the start of a paragraph it will enclose it
1379 in a <div> with the according style assignment, otherwise (in the
1380 text) a @@ will become a <span>.
1382 See also the explanation and examples in this plugins` comments.
1388 This plugin allows you (like the markup_css plugin) to attach CSS
1389 classes to a paragraph of text with just a single @ character:
1391 @JAVADOCLIKE paragraphs text...
1392 ... ... ... .... ... ... ... ...
1398 Introduces the ability to generate footnotes by placing an
1399 explanation into double curly brackets {{footnote text}}.
1401 You should activate this only if you really need it. Sometimes this
1402 may be useful, but it is rather bad wiki style; because if someone
1403 would like to explain something in more detail he should create a
1404 WikiLink to a new page. So this should be used for very short
1405 explanations, say incomplete sentences or a book reference and
1406 other things where it really seems bloat to create a new page.
1408 USE THIS RARELY or better not at all!
1409 (this is a feature copied from MS` EvilWiki)
1415 Allows to use ASCII-Art tables as outputed by lynx and other
1416 console programs inside of WikiPages, which eases life, when
1417 dealing with multiline table cell content.
1423 ewiki allows you to use tables with the || | characters in the wiki
1424 page source. However the html code for the table layout is
1425 hardcoded and cannot be changed on a per-page basis.
1426 This plugin intercepts the wiki source formation process to allow
1427 you to specify html tag attributes inside a table definition like:
1429 |{ border=0 cellspacing=10} here is | the table | content |
1430 | 2nd line | 2nd line |{ rowspan=2} fills two table rows |
1431 |{ colspan=2} 3rd line |
1433 Note, the opening "{" must follow the "|" character immediately.
1435 This code was provided by Hans B Pufal.
1437 It may be a security risk to include it per default, as this allows
1438 to add SomethingScript references as well.
1444 Provides a block escape to use the standard html <table> code
1445 instead of the limited pipe syntax provided by ewiki. It will parse
1446 for <tr> and <td> tags and strip any not registered attributes to
1447 defend against harm that could be caused by EvilScript additions.
1449 The common html <table> syntax then allows easily to include
1450 multiline table cell content, which is nearly impossible (to edit)
1451 for the "|...|..|" table syntax.
1457 Allows to use some 'safe' HTML tags within the WikiPage. This
1458 plugin replaces the previous EWIKI_RESCUE_HTML constant.
1460 Note that those 'safe' HTML tags may also lead to some confusion,
1461 especially if you have a wiki about HTML, because then you cannot
1462 write text about the <STRONG> tag because it will actually always
1463 be interpolated as itself and not as the text string "<STRONG>".
1467 markup/rendering_null
1468 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1469 If someone would like to use ewiki for a personal homepage, but
1470 prefers HTML over WikiSyntax, then this rendering core replacement
1471 may suit his needs. It allows HTML to be used, but still renders
1472 WikiWords into valid hyperlinks (a few other features from the
1473 original ewiki_format function are also supported, but you can
1480 Adds the /italic/, *bold* and _underlined_ markup codes, which
1481 sometimes can heavily garbage pages (because ewiki provides no
1482 general markup escape sequence, but the per-default disabled
1483 <verbatim>, or respectively <nowiki>).
1489 Allows to start enumerated pages in the source with simple
1490 numbers followed by a dot, as it would naturally be written.
1491 Those lists are of course re-converted into real enumerated html
1496 markup/fix_source_mangling
1497 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1498 Speeds up ewiki page rendering, in that all older page source
1499 oriented markup plugins are run together onto ["core"] page content
1500 blocks only. This also fixes a few problems, which some plugins may
1501 issue with the renewed formatting kernel.
1507 Evaluates the pages [Acronyms] and [Abbreviations] to read a
1508 definition list or table from them, whose entries will later be
1509 replaced in the whole wiki. Then all occourences of those
1510 abbreviations or acronyms will be replaced by the accoring entitled
1511 html tags (<abbr> and <acronym>), providing a lot user-visible meta
1514 You could style thouse occourences via CSS as usual.
1518 markup/table_rowspan
1519 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1520 Merges multiple table cells automatically (to the left one) for all
1521 occourences of || two or more dashes.
1527 Introduces the &now markup which gets replaced with the current
1528 time/date string AT EDIT TIME.
1534 Allows you to create in-page abbreviation tags by simply
1535 writing something in all-uppercase and placing the definition
1536 into round braces behind it, like: WIKI (a WikiWikiWeb).
1540 markup/definitionlinks
1541 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1542 Automatically creates anchors for all entries in a definition list
1543 and links occourences of these words in the rest of the current
1550 The so called "mpi" plugins can be embedded into pages, and produce their
1551 output there. They are loaded on demand (only if it appears that they should
1552 be invoked), but it is possible to include() the individual files regardless
1553 if they would be used or not.
1555 In order to have the mpi plugins available, you must however first load the
1557 include("plugins/mpi/mpi.php");
1558 Which then takes care of the markup and loading of the requested plugins.
1560 The syntax for calling a mpi plugin is (write this inside of a WikiPage,
1563 <?plugin PluginName arg="..." arg2=DDD ?>
1565 Where args are often optional or could even be written without the 'argname='
1566 if only one was required. The name of the mpi plugin is case-insensitive
1569 Some plugins take longer text-only arguments, where you just put some more
1570 paragraphs of text or some pseudo-programming code before the closing ?>
1571 like for the TableEditor:
1573 <?plugin TableEditor
1579 Just see the distributed [MpiPlugins] page for an overview of available
1580 plugins of this type.
1582 It is often possible to invoke mpi plugins like ["page"] plugins, if you
1583 create a link inside of the page using the syntax <?plugin-link PluginName ?>
1589 Prints a list of BackLinks to the current page (the same as when
1590 clicking on the title of a page or on the BackLinks action link).
1591 <?plugin BackLinks ?>
1592 <?plugin BackLinks page=ForThatPage ?>
1598 Allows to <embed> multimedia files into a page.
1604 Embeds remote RSS feeds (abbrv. for "ReallySimpleSyndication" or
1605 "RichSiteSummary") into the current page. It caches the fetched
1606 data for quite some time in a pre-parsed _BINARY database entry.
1612 Allows to insert another readily rendered WikiPage into the current
1613 one, usually inside of a <table border="1">.
1619 Is a mix of BackLinks and LinkTree features, and prints the tree of
1620 pages backreferencing to the current one.
1626 Brings up a list of all links that were removed throughout the page
1632 The hook following plugins utilize is called "append-view". It allows to put
1633 content below a pages contents (after the action links).
1639 Adds the list of BackLinks (references from others to the current
1640 page) to the current page below it (this list is also available,
1641 when a user clicks on the title of a page).
1647 Prints the possible (shortest) paths to the FrontPage (determined
1648 by the EWIKI_PAGE_INDEX constant) starting from the current one
1649 below. Calculations and database access required by this plugin
1650 often means a slowdown up to 2 seconds before the page is readily
1657 Analyzes a pages headlines and generates a "table of contents" box
1658 from it, which is inserted as float box on top of it then. Use the
1659 following CSS selector to style it:
1669 Allows to add separate comment pages, which will then always be
1670 displayed below the current one, but remain editable as standalone
1671 pages. (So the page they are appended to could be marked as
1678 Allows to group the pages created using the "posts" plugin into
1685 Adds the list of pages, which appear to be SubPages of the current
1692 Shows the uploaded files, which appear to belong to the current
1693 page (individual pages can be treated as upload sections).
1699 Prints an image uploading box below every page, which allows to
1700 append an image without prior clicking EditThisPage (the image
1701 will be automatically appended to the bottom of the page).
1707 This plugin allows users to select a logo graphic which will be
1708 made available for use in the site template as
1709 $ewiki_config["page_logo"]. Configureable through the internal
1716 Shows examplarily how to replace the standard "action-links" box,
1717 and adds it on top of the page (including the page title).
1723 This plugin allows users to select a page image graphic, and is a
1724 mix of the aview/piclogocntrl and page/imagegallery plugins.
1730 Adds a text <input> field below the edit/ box, which allows to
1731 set the AuthorName which then will get stored, when the page is
1732 saved. This name is then also stored client-side as cookie for
1733 at least 45 minutes.
1735 Before using this plugin, you must consider, that it eventually
1736 allows to override the correct username that ProtectedMode plugins
1737 already provided. And there is no way to prevent users from using
1738 faked names (because this plugin cannot check if a username was
1739 already 'registered' and thus can't initiate a password query).
1743 edit/deletebutton.js
1744 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1745 Adds a JavsScript snippet to allow users to quickly mark a page
1746 for deleterequest, by inserting the link to "DeleteMe" into the
1747 contents, when editing it.
1753 Brings up a <select> element on top of the edit/ page for empty
1754 (to be created) pages, that lists all pages which names end in
1755 "Template". One of the templates can then be loaded into the edit
1756 box as base for the new page.
1762 Adds an input box to the edit/ page, where users can put a summary
1763 of the cahnges they made. This ChangeLog can later be displayed on
1764 the RecentChanges page. ("UpdatedPages" currently does not use
1766 While this additional field is a bit more time consuming, users
1767 often fill it out, to advocate the changes they've contributed to
1774 Allows your users to set certain flags, when editing a page. You
1775 must first enable the one you deem non-harmful enough to get changed
1782 Is a variant of the flags setting extension, which only provides
1783 the _MINOR edit checkbox to hide a page edit from RecentChanges.
1789 Shows an informational warning notice, when two people appear to
1790 be editing the same page.
1796 Prints a stronger warning message (can be unlocked however), when it
1797 detects that someone wants to edit a page someone else is already
1803 There are now three plugins which can turn the [preview] button
1804 below every page edit box into a spellcheck function.
1806 Wether you have a working 'aspell' or 'ispell' on your system, or
1807 the PHP internal aspell functions, you must load the according
1814 Scrambles added URLs to a page (through zero_pagerank wrapper or
1815 Google jump url) when it partially matches any fragment listed
1816 on the special "BannedLinks" page.
1822 Rejects edit, if a newly added URL matches with a text snippet
1823 from the "BlockedLinks" page.
1829 A few plugin hooks exist to completely rework generate page output. These
1830 are often used to insert content into the otherwise readily rendered .html
1831 pages (some of the above aview plugins do so, too).
1837 Is a minimal tag balancer (a highly simplified HTML tidy) and can
1838 work around various html code problems that the ewiki_format()
1839 html rendering function has. It is for example specialized to
1840 correct broken html that resulted from WikiMarkupAbuse as for
1841 example nesting text style attributes like this: __''text__''
1845 filter/search_highlight
1846 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1847 Evaluates the Referer header sent by many browsers to detect if
1848 a visitor came from a search engine (even the internal PowerSearch
1849 or SearchPages ones) and highlights the searched words in the
1850 current pages body (using CSS).
1860 filter/fun_upsidedown
1861 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1862 Transforms a pages content using letter transformation to make
1863 them readibly from upside down with certain fonts. This however
1864 is a bit tricky for html pages and thus will always wrongly
1865 intermix sentence order.
1871 Adds a little CSS to make text swirrling on both sides.
1875 filter/fun_screamomatic
1876 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1877 Detects if someone entered a FULL LINE OF YELLING into a page
1878 when editing it, and then sets a persistent cookie. That cookie
1879 will result in all pages contents to be converted into uppercase
1884 BloatWiki extensions
1885 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1886 ewiki slowly evolves into a well-bloated portal software, and some plugins
1887 already extend it far beyond the scope of an ordinary Wiki.
1893 The calendar plugin enables you to add an editable calendar to
1894 every WikiPage. It is not a fully integral part of ewiki, and needs
1895 additional calls from yoursite.php to integrate nicely into your
1898 You even don't need to allow a calendar to be added to every page,
1899 you can just include the plugin file and use the _one_ page called
1900 "Calendar" or "YearCalendar", where everybody can make additions.
1902 The coolest about this plugin is, that it nicely integrates into
1903 the common WikiNameSpace.
1905 Just include("plugins/calendar.php"); so it gets available.
1906 In yoursite.php integrate it as follows:
1911 echo ewiki_page(); // print current pages content, as usual
1915 if ( calendar_exists() )
1918 echo calendar(); // print calendar for current page
1921 ... // else only a link to the cal. page
1922 echo "<a href=\"?id=calendar/$ewiki_id\">ShowCalendar</a>";
1927 The calendar() function call emits the html for the calendar of the
1928 currently viewed page (see ewiki_page() call).
1930 The function calendar_exists() only checks for already existing
1931 event entries in the calendar, so the calendar won't show up, if
1932 there isn't yet anything inside (so only the "ShowCalendar" link at
1933 the bottom of the page will link to the still empty calendar). You
1934 can of course leave out this function call or alternatively call
1935 it with calendar_exists($always=true) if you want the calendar to
1936 appear most of the time / or for all pages.
1938 Please note the "fragments/calendar.css" file, which illustrates
1939 how to tweak layout and look of the generated calendars.
1941 This plugin was contributed by Carsten Senf (originally
1942 implemented for good old PhpWiki).
1948 From the very beginning the ewiki core supported uploading image
1949 files into the database. As time and discussions went on, there
1950 came the idea to allow arbitrary binary files to be inserted too.
1952 The old EWIKI_ALLOW_BINARY way should now be avoided, because the
1953 download plugin adds more functionality and more features, and is
1954 easier and more intuitive to use.
1956 It adds the virtual page FileUpload to insert a file into the
1957 database, and the page FileDownload, which lists all available and
1958 uploaded binary files from the db.
1960 Please note, that due to the use of the database interface, the
1961 file sizes are usually limited to 1-2M (depending on PHP and MySQL
1962 settings), so there may still be some need to reimplement this,
1963 using the antique world-writable incoming/ directory method.
1965 The mime_magic plugin should be used together with this one, and
1966 you should change the icon file names (use the ones from the Apache
1967 distribution for example).
1969 (It may also be a good idea to run a secondary database if you
1970 use it. Have a look at fragments/binary.php, and set up a
1971 secondary ewiki database using it and the db_flat_files plugin.
1972 This is useful, because you then can more easily delete uploaded
1973 files as they don't get saved into a SQL database.)
1975 Different download sections can be defined. The "*" merges all
1976 allowed sections into one list again, and the "**" section even
1977 lists the files attached to pages.
1979 The page attachment link (to append download functionality to each
1980 page) can be revoked by unsetting the $ewiki_plugins["action"]
1981 line in the downloads.php file; so only the default sections are
1982 accepted (and page names rejected).
1984 The plugins/downloads_view.php brings up the list of uploaded
1985 attachments below each page (if existing). It works rather fast
1986 due to an improved database search call, and should therefore be
1987 activated whenever you use the per-page attachments feature.
1989 See also plugins/binary_store.php to keep your SQL database small,
1990 but note its limitations.
1996 Provides a shortened view of the current page and all linked ones
1997 (even the backlinked ones). This eases navigation and page content
1998 "scanning" (getting a quick overview).
2004 Adds the general page meta data support, and a small input box
2005 below every page, which allows users to add arbitrary invisible
2006 infos about the current page. The data will be stored into the
2007 page hash as $data["meta"]["meta"] entry (four levels deep
2009 All that meta data information must however be evaluated by other
2010 specialized plugins later to make sense:
2014 meta/builtincategories
2015 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
2016 Contains a list of category names (you first must edit it!), which
2017 will later be displayed in/below pages to make users choose from
2018 one. The category name is written back into a pages {meta}{meta}
2025 Uses a "title:" entry in the {meta} block to override the shown
2026 page title (which otherwise and usually would be the same as the
2027 database internal real page name).
2029 (Note: The mpi plugin SetTitle does basically the same.)
2035 The plugins/lib/ directory contains code and functionality, which often is
2036 required by some of the other plugins (they depend on it then), but which
2037 was too specialized to get part of the ewiki.php core script.
2039 Other extensions in the lib/ subdir didn't match in any of the other plugin
2046 This plugin stores readily rendered Wiki page content (already in
2047 html format) either into a dedicated directory, or into specially
2048 named _BINARY wiki database entries. This then allows to satisfy
2049 further requests to a page with the saved content.
2051 You should set EWIKI_CACHE_DIR to a useful value (a so called
2052 "chmod 777" directory, so your webserver process can write into it),
2053 or alternatively unset this constant and instead define
2054 EWIKI_CACHE_DB so cache entries get stored into the ewiki database.
2055 The _CACHE_DB constant is just prepended to the name of the current
2056 page to get the name for the database entry for the cache data.
2062 Evaluates the "conditional HTTP request headers" to tell a client
2063 if it could reuse its existing cache entry for a requested page.
2064 This is believed to reduce traffic and also speed up some
2065 applications. However it is still rather untested and could anyhow
2066 lead to some problems (never updating pages for some broken
2067 browsers). The evaluated headers include "If-Unmodified-Since:"
2068 which corresponds to the "Last-Modified:" answer header ewiki
2071 However this will only work, if you disable EWIKI_NOCACHE - but
2072 then some browsers will never see updated pages, if they were
2073 misconfigured to not refetch pages, once they got into the internal
2074 browser cache. (But on the other hand, that is users fault ;)
2080 Implements the mime_magic feature absent from some (older and
2081 misconfigured current) PHP interpreter versions.
2083 This is recommended in conjunction with the downloads plugin to
2084 store correct mime type data, for proper use of icons beside
2085 download links. Also the correct Content-Type header should always
2086 be available, when binary content is delivered.
2092 Provides a configureable menu for the contents of your Wiki for
2093 inclusion in your site template, which changes depending on which
2094 site area you're currently inside (determined partially by
2095 the linktree plugin).
2101 Is an extension package (currently in development) with various
2102 helper functions for ProtectedMode plugins. Especailly useful in
2103 conjunction with the auth-liveuser framework.
2109 An example script on how to store additional vars into page entries
2110 of the ewiki database (session like).
2116 Adds support for emitting RSS and Atom-feeds. Use in conjunction
2117 with plugins/action/rss.
2123 Collects plugins for ewiki / database administration. Often these depend
2124 upon $ewiki_ring==0 (superuser authentication level in EWIKI_PROTECTED_MODE),
2125 otherwise refuse to work for security reasons (some functions are however
2126 available to moderators too, ring level 1).
2128 Some of these plugins may be reimplementation of stuff from the tools/
2129 directory (integrated database tools).
2135 Allows changing per-page settings, and adds a easily accessible
2136 "page control" action link below every page.
2138 You can use this to immediately change per-page flags (_READONLY,
2139 _HTML, _DISABLED and so on). Or you can delete a unwanted page as
2140 soon as you discover it.
2141 It also enables you to edit any entries in the {meta} field of
2142 database entries (which sometimes contain HTTP headers, or page
2144 And the fourth possible action is to easily rename the page (with
2145 letting ewiki adjust all links to it without further intervention).
2151 Is a powerful text/content replacement tool. It features regular
2152 expression matching, but can also be used as any other simple string
2159 This tool is intended to create 'shadow pages' (or 'ghost pages')
2160 for ewiki internal/generated pages (the ["page"] plugins), which
2161 usually weren't found by the PageSearch and PowerSearch. This
2162 admin plugin just innovocates those page plugins and puts their
2163 html output into the database (which then can is found by the
2164 search functions, but is never displayed, because the page plugins
2165 still have precedence over that faked database content).
2171 These plugins actually implement some stuff, one usually should do inside
2172 of the yoursite.php ewiki wrapper script.
2178 Eventually contains debug plugins.
2184 Contains various (example and ready to use) plugins for the
2185 ewiki_auth() interfaces. This directory contains its own
2186 README.auth, which describes the _PROTECTED_MODE, the _auth API and
2187 available sample plugins in detail.
2191 plugins/auth-liveuser/
2192 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
2193 Contains the more advanced authentication and permission plugin
2194 bundle for chaining ewiki with the PEAR LiveUser authentication
2195 framework. There is detailed documentation within the README in
2200 separate "extra" tarball
2201 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
2202 There are a few plugins and extensions, which are not packaged into the
2203 distributed ewiki tarball for size reasons. You can obtain it from your
2204 favourite dealer, or from our downloads/ directory as "extra-CVS-*"
2206 http://erfurtwiki.sourceforge.net/downloads/
2208 The package currently just contains a minimal spam filter (which after all
2209 isn't very useful for a Wiki site), but in the future will also provide
2210 additional example/ layouts and some image/graphics/icons for layout
2211 beatification purposes.
2215 Updates + How to deal with tweaked code
2216 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
2217 If you ever happen to recode parts of a plugin, WHICH WE STRONGLY ENCOURAGE
2218 TO DO (to match it better to your needs) - then there is always the risk of
2219 losing your changes as soon as you upgrade and overwrite everything inside
2221 Therefore it is recommended to create a subdirectory like "local/" where
2222 you copy changed plugins into, then include() them from there instead of
2223 the distributed default from plugins/. So you won't lose your changes and
2224 enhancements if you upgrade to a newer version. You of course should then
2225 check (after updates) if the newer version of a plugin contained
2226 enhancements you'd like to merge with your cutomized version of the earlier
2229 For the main "ewiki.php" script, things are of course more difficult, as
2230 you will probably always overwrite it when you update your installation.
2231 Best approach is to keep a NOTES file, where you store your patches for
2232 later reinclusion with newer releases, or even to keep always a second
2233 copy of your tweaked "ewiki.php". Much better was of course to send your
2234 changes to the ewiki -dev people so they could merge them into the CVS,
2235 so everybody could enjoy your ideas.
projects / atutor.git / blob