NOTE: This file is again pretty outdated. But this time, there is no way back. It is nearly impossible to correctly document ALL ewiki plugins. But because most come with documentation inside (comments in head area) this is not that big an issue. You can still use this README part for reference. Just remember that it is incomplete and does not list all plugins. Most notes are still accurate however. ewiki plugins ============= The plugins/ directory contains loads of ewiki extensions, which are simply enabled by include()ing or melting them with the main ewiki script. This file tries to provide an overview and explanations for all the individual extensions. 1 plugin culture 1.1 plugin loading 1.2 melting / advanced plugin usage 2 database plugins 2.1 built-in MySQL support 2.2 plugins/db/flat_files 2.3 plugins/db/fast_files 2.4 plugins/db/any 2.5 plugins/db/dba 2.6 plugins/db/phpwiki13 2.7 plugins/db/binary_store 2.8 plugins/db/dzf2 2.9 plugins/db/zip 2.a plugins/db/rpc 2.b plugins/db/ext_multi 2.c plugins/db/ext_subwiki 2.d db/oldapi 3 core enhancements 3.1 plugins/patchsaving 3.2 plugins/notify 3.3 plugins/jump 3.4 plugins/email_protect 3.5 plugins/spages (StaticPages) 3.6 plugins/pluginloader 3.7 plugins/init 3.8 plugins/feature/appendonly 3.9 plugins/feature/imgresize_gd 3.a plugins/feature/imgresize_magick 3.b plugins/feature/imgfile_naming 3.c input_trimming 3.d feature/pingback 3.e feature/refererlog 3.f feature/xpi 3.10 feature/xpi0 4 action/ plugins 4.1 plugins/action/diff 4.2 plugins/action/translation 4.3 plugins/action/like_pages 4.4 plugins/action/raw 4.5 rss 4.6 action/info_qdiff 4.7 action/translation 4.8 action/relatedchanges 5 plugins related to hypertext links 5.1 plugins/linking/tcn 5.2 plugins/linking/plural 5.3 plugins/linking/autolinking 5.4 plugins/linking/link_css 5.5 plugins/linking/link_icons 5.6 plugins/linking/link_target_blank 5.7 plugins/linking/linkexcerpts 5.8 plugins/linking/linkdatabase 5.9 plugins/linking/instanturls 5.a plugins/linking/titlefix 5.b plugins/interwiki/intermap 5.c plugins/interwiki/editable 5.d linking/xfn 6 appearance/ tweaks 6.1 plugins/appearance/listpages_br 6.2 plugins/appearance/listpages_ul 6.3 plugins/appearance/listpages_tbl 6.4 plugins/appearance/fancy_list_dict 6.5 plugins/appearance/title_calendar 7 page plugins 7.1 plugins/page/powersearch 7.2 plugins/page/pageindex 7.3 plugins/page/wordindex 7.4 plugins/page/imagegallery 7.5 plugins/page/aboutplugins 7.6 plugins/page/orphanedpages 7.7 plugins/page/wantedpages 7.8 plugins/page/since_updates 7.9 plugins/page/textupload 7.a plugins/page/wikidump 7.b plugins/page/interwikimap 7.c plugins/page/hitcounter 7.d plugins/page/scandisk 7.e plugins/page/wikinews 7.f plugins/page/wikiuserlogin 7.10 plugins/page/randompage 7.11 plugins/page/fortune 7.12 plugins/page/ewikilog 7.13 plugins/page/phpinfo 7.14 plugins/page/README 7.15 plugins/page/recentchanges 8 markup plugins 8.1 Other WikiWares markup 8.2 plugins/markup/css 8.3 plugins/markup/css_singleat 8.4 plugins/markup/footnotes 8.5 plugins/markup/asciitbl 8.6 plugins/markup/complextbl 8.7 plugins/markup/htmltbl 8.8 plugins/markup/rescuehtml 8.9 plugins/markup/rendering_null 8.a markup/1emphasis 8.b markup/naturallists 8.c markup/fix_source_mangling 8.d markup/abbr 8.e markup/table_rowspan 8.f markup/timestamp 8.10 markup/braceabbr 8.11 markup/definitionlinks 9 mpi 9.1 mpi/backlinks 9.2 mpi/multimedia 9.3 mpi/syndicate 9.4 mpi/insert 9.5 mpi/localsitemap 9.6 mpi/removedlinks a visual extensions a.1 plugins/aview/backlinks a.2 plugins/aview/linktree a.3 plugins/aview/toc a.4 plugins/aview/posts a.5 plugins/aview/threads a.6 plugins/aview/subpages a.7 plugins/aview/downloads a.8 plugins/aview/imgappend a.9 plugins/aview/piclogocntrl a.a plugins/aview/control2 a.b plugins/edit/pageimage a.c plugins/edit/authorname a.d plugins/edit/deletebutton.js a.e plugins/edit/templates a.f plugins/edit/log a.10 plugins/edit/flags a.11 plugins/edit/minor a.12 plugins/edit/warn a.13 plugins/edit/lock a.14 plugins/edit/spellcheck/ a.15 edit/spam_deface a.16 edit/spam_block b page filters b.1 plugins/filter/f_fixhtml b.2 plugins/filter/search_highlight b.3 plugins/filter/fun_chef b.4 plugins/filter/fun_upsidedown b.5 plugins/filter/fun_wella b.6 plugins/filter/fun_screamomatic c BloatWiki extensions c.1 plugins/module/calendar c.2 plugins/module/downloads c.3 plugins/module/tour c.4 plugins/meta/meta c.5 plugins/meta/builtincategories c.6 plugins/meta/f_title d utility code d.1 plugins/lib/cache d.2 plugins/lib/speed d.3 plugins/lib/mime_magic d.4 plugins/lib/navbar d.5 plugins/lib/protmode d.6 plugins/lib/save_storevars d.7 plugins/lib/feed e admin/ plugins e.1 control e.2 SearchAndReplace e.3 SearchCache f other plugins f.1 plugins/debug/ f.2 plugins/auth/ f.3 plugins/auth-liveuser/ 10 separate "extra" tarball 11 Updates + How to deal with tweaked code -------------------------------------------------------------------- 6 -- plugin culture ŻŻŻŻŻŻŻŻŻŻŻŻŻŻ While ewiki is a rather monolithic script, it allows for extension by various plugin hooks (= the internal $ewiki_plugins array). This keeps the core small (just one script) and fast, but also easy to use (not too cluttered user interface). However for advanced needs, there is always the option to add a required function very easily. Of course some plugins slow down your Wiki (for example markup extensions often do), so it was unwise to enable all at once. Also a few plugins can be incompatible to each other (very divorce goals), and some require further configuration and setup in order to be useful at all. You may therefore also check out the standalone 'setup.php' script, which also provides a simplified and _shortened_ overview of the easier to use plugins. This utility also can generate the appropriate 'config.php' for you. The structure of the plugins/ directory is purely presentational, ewiki does not depend on accessibility of that directory; none of the paths is hardcoded anywhere. This is because YOU are responsible for loading plugins, the core script does never load anything on itself. The only exceptions to this rule are: spages, mpi, and the pluginloader. .meta files ŻŻŻŻŻŻŻŻŻŻŻ The plugins/ directory is full of .php scripts (the plugins), accompanied by a .meta file each. These are textual data files, that explain what's in the plugin. This data is used for the SetupWizard and tools/setup tool and by other so called "plugin managers". Read "doc/PluginMetaFiles" if you want to find out more. Ignore those files otherwise. plugin loading ŻŻŻŻŻŻŻŻŻŻŻŻŻŻ To enable an extension, you simply load the according plugin(s) using the PHP include_once() function, like you do with the core ewiki.php script: include_once("plugins/email_protect.php"); include_once("plugins/page/textupload.php"); ... include_once("ewiki.php"); Usually it does not matter, if you load the plugins before or after the ewiki script. If this makes a difference, the plugin documentation would mention it. (include_once() is recommended and standard since R1.02b) melting / advanced plugin usage ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ The design of the ewiki script and the extension hooks and all plugins makes it also possible to "melt" the core script with the plugin files. This is useful to again have all functionality in a single script, and also allows PHP to run it slightly faster (because then the PHP language 'parser' gets invoked just once). You would simply use the cat(1) utility (or "type" under DOS/Win) to merge the plugins with the core script as follows: cat plugins/email_protect.php >> ewiki.php cat plugins/page/textupload.php plugins/notify.php >> ewiki.php See also the paragraph on "monsterwiki building" in the main [README] file. (The 'tools/mkhuge' script did previously what's described here.) Nowadays you would use the "tools/setup" console script (under Linux) or the SetupWizard to make a monsterwiki. database plugins ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ The ewiki.php core script contains a database request function which is tailored to a MySQL database. However that function is already prepared to chain to another "database abstraction" function if desired. built-in MySQL support ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ The first implemented, and still most recommended way to use ewiki is with a MySQL (3.21 or later) database. RDBMS work more reliably and of course much faster than any other of the ewiki database backends. As the core ewiki_database() inside ewiki.php already includes the MySQL database calls, there is usually nothing to do, but opening a database connection before ewiki.php is included() from yoursite.php Please look at the top of this README for an example. As PHPs mysql_() functions don't require a db resource link to be given anymore, the ewiki_database() function does not pass and thus does not require it too. (If you use more than one MySQL database, you should take care that ewiki always uses the one you accessed least.) 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 | ... 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. db/fast_files ŻŻŻŻŻŻŻŻŻŻŻŻŻ NOTE: The db_fast_files has been merged into db_flat_files, so both formats can be read now - at the same time! Updated or new pages will however always be written in the file format determined by EWIKI_DB_FAST_FILES (defaults to 0) - edit the "db_flat_files.php" script to change that constant setting, or even add it to your "config.php" so it was always present. While "db_flat_files" allows you to edit the WikiPage files (using any simple text editor), the "db_FAST_files" plugin saves the pages in a binary&compressed format (utilizing PHP's serialize function). This generally leads to a speed enhancement. Additionally this also allowed the PageHit counting to be activated (which is off in plain flat files). So you may wish to use this plugin in favour of the older db_flat_files. And as now both methods are available at the same time, you can switch whenever you want. Most of the setup guide from above is true for this one, too. An additional configuration constant introduced here is EWIKI_DBFILES_GZLEVEL, which tells the PHP internal zlib how much time to spend on compression of the saved pages. Usually the zlib uses a default of 5, but for speed purposes it is set to 2 here. You can also set the constant to 0 so the files will get saved uncompressed (but still in 'binary' format). A value of 9 will give you the smallest possible files, but this takes a little more CPU cycles (a bit slower). This plugin was contributed by Carsten Senf. db/any ŻŻŻŻŻŻ If you use a relational SQL database other than MySQL, then you may want to give this plugin a try. It itself provides a wrapper for the PHP database access wrapper libraries ADOdb, PEAR::DB and dbx(). These wrappers themselves provide unified access to various SQL databases in contrast to the many highly different db access functions of PHP. Each of these db access wrappers has advantages and disadvantages and so none of them is really widespread and many users of course only jump on one of these trains. Because ewiki now tries to be 'library' it will use whatever database access wrapper you already have running on your site or container CMS, and the highly simplified anydb_*() now tries to make use of it. The plugin is based upon the current MySQL database backend, and thus may not be compatible to all proprietary SQL variants. Before you can use the db_any plugin you must ensure that you either already have the PHP dbx extension dll loaded or the PEAR::DB or ADOdb include files loaded. db_any will like to see an opened database connection inside of the global '$db' variable. If yoursite.php hasn't already a connection opened when ewiki.php gets included, then you should preferably choose to use the anydb_connect() function to do so (it will choose from PEAR::DB, ADOdb and PHP dbx interfaces). The '$db' connection handle can be shared between your site and ewiki as long as it is a handle for one of the mentioned database access wrapper libraries. Btw, "plugins/db_adodb" was obsoleted by this. db/dba ŻŻŻŻŻŻ including() this plugin enables ewiki to store the WikiPages in the Berkeley DB file given with the EWIKI_DBA constant. Your PHP binary must be compiled with either the "dba" or the "dbm" extension to use this (and the dba extension requires at least one other database type to be enabled). The plugin has a built-in list of preferred dba database types, but it respects the filename extension of EWIKI_DBA. For example "wiki.db3" would create a DB3 database file, while "wiki.gdbm" resulted in a GDBM file, if that php extension was available. The PHP dba extension can support the db types (if compiled for): .db3 .gdbm .db2 .flatfile .ndbm .dbm .db4 If you have the PHP "dbm" extension enabled, wrapper functions will get enabled, so this works even if the "dba" extension is not there. The .flatfile is often available even if you haven't compiled your PHP binary for anything else than "dba". This may also often be faster than one of the db_flat_files plugins. If EWIKI_DBFILES_GZLEVEL is set to a value from 1 (fast) till 9 (very good compression, but slow), the saved pages will get compressed inside the dba database. With 0 this feature gets disabled. db/phpwiki13 ŻŻŻŻŻŻŻŻŻŻŻŻ The original ewiki database table structure was compatible with the one used in PhpWiki version 1.2.x, however it turned out that the PhpWiki project has yet not stopped completely and choosed to implement a more relational table structure with version 1.3 This plugin is only meant for transition __from__ PhpWiki v1.3.x to ewiki, it should NOT be used to connect ewiki with PhpWiki forever. Write access is disabled per default, but available. However it is probably not fully compatible with the database abstraction and usage of PhpWiki, so it is likely to corrupt your database if you use it for a longer period of time. This warning is mainly because the 'latestmajor', 'latestminor and 'minor_edit' rows in the PhpWiki database, because such stuff is not used by ewiki at all. ewiki also tries to put some of the pages meta data into places where it could eventually confuse PhpWiki. Write access is however done nearly as safe as within the ewiki database access layer (INSERT statement to not overwrite existing entries). Again: this plugin is in no way meant to encourage you to keep your old PhpWiki database! ;> Please see also "tools/ewiki_convertdb.php". If you temporarily enable this plugin within the default/example "config.php" or the "tools/ewiki_tools_config.php" you can also utilize the very powerful 'ewikictl' cmdline utility to generate a copy of your PhpWiki database in one of the backup formats suitable for later use with ewiki. db/binary_store ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Is a hack into the ewiki core, which will store binary/uploaded files outside of the default ewiki database (as plain files in a data directory). Please also see the documentation on top of the plugin file. Per default ewiki can store "binary" entries beside ordinary text pages in the database. If you'd like to keep uploaded files/images out of the db, then this plugin/hack will help. It intercepts ewiki and saves uploaded data into a plain data file, and instead creates a "binary symlink" in the database for it (just the binary meta data will get stored, with a hint on where to later access the plain data file). This may sometimes be a speed enhancement and reduces size of the database, however it has the drawback that only the main ewiki script can handle this transparently and all admin tools/ fail to deal with the stored plain data files (no backup support and so on). By setting the EWIKI_DB_STORE_URL constant correctly (corresponding to your wiki setup and where you store the data files, compare with EWIKI_DB_STORE_DIRECTORY) you can make ewiki create URLs directly to where the stored plain data files reside (they do not contain ewiki database meta data, and thus could be accessed directly by http clients/browsers). Please be sure to configure this plugin by setting _DB_STORE_DIRECTORY to something more useful than "/tmp", so your uploaded files will still be there after a reboot. db/dzf2 ŻŻŻŻŻŻŻ The "dzf2" database plugin provides a flat file database (no SQL), which stores its files compressed (like db_fast_files), but also plattform-independent and in a case-insensitive manner (which is not possible with dbff on Unix filesystems). It introduces a few other enhancements, that make it a bit quicker than the flat_files backend. Also, it creates a unique sub directory tree, to provide faster access times (disk/directory reading). db/zip ŻŻŻŻŻŻ This fun plugin stores files into a ZIP file. It is not recommended for productive setups, and requires the commandline Unix 'zip' utility to operate (DOS pkzip may also work). db/rpc ŻŻŻŻŻŻ Can access a remotely located ewiki database via PHP-RPC. Needs a bit more setup (creating an interface and setting up passwords). Could be used in conjunction with ext_multi to only have a few pages located remotely. db/ext_multi ŻŻŻŻŻŻŻŻŻŻŻŻ Multiple database backends can be joined virtually into one DB for ewiki using this extension. Needs a bit more setup, because you must assign one of the backends as main database, where changes are written to (exclusively). db/ext_subwiki ŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Can automatically fragment your database into separate namespaces, but must however be enabled from the beginning. You need to prepare yoursite wrapper around ewiki to detect the currently accessed Wiki; what however is useful to easily set up a WikiFarm. db/oldapi ŻŻŻŻŻŻŻŻŻ Provides a compatiblity layer for database backends after the older non-OO interface (which is still supported in the core script). core enhancements ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Some really cool features are put into extension plugins, and the most important, recommended and most often used ones are listed in this section: patchsaving ŻŻŻŻŻŻŻŻŻŻŻ If two users concurrently edit a page, then only the first save attempt will succeed; which the second user is told by the "This page version was already saved" failure message. This plugin works around this by passing the contents of the concurrent versions through the 'diff' and 'patch' utilities, which often merges the two different modifications in a new version that can be saved into the database so there is no need for the failure message. notify ŻŻŻŻŻŻ This plugin enables users to get notified, whenever someone changes a watched page. To enable 'watching' one must just place an email address into the page with following syntax: [notify:mail@example.com] This bracket will be invisible, when a page is viewed, so it can be placed anywhere. The notifications will be sent to this address as long as the tag is there. If one wishes to receive notification messages in another language, this just needs to be added after a comma or semicolon, like: [notify:pop3@example.net,de] This is often only necessary for the generic TLDs .com .org .net, or where language code and TLD differ. jump ŻŻŻŻ Introduces magic markup for page redirection (switching to another page). Possible notations are: [jump:OtherPage] [goto:SwitchToThere] The EWIKI_JUMP_HTTP setting tells this plugin to send a Location: and redirect HTTP status when encountering a page [jump:]. Else this plugin will show up the JumpDestination page without notifying the browser about it. It is also possible to perform InterWiki jumps, just be using the common InterWikiMoniker: syntax, but generic URLs are also allowed. [jump:WardsWiki:WelcomeVisitors] [jump:http://www.example.org/] email_protect ŻŻŻŻŻŻŻŻŻŻŻŻŻ This plugin 'ciphers' all valid email addresses inside a WikiPage for protection against automated spambots. Additionally it throws fake/trap email addresses to spammer databases :> It ist not integrated into the core script, because some people may prefer to have email addresses visible (intranet usage). However it is HIGHLY RECOMMENDED to enable this plugin. Despite its file size it is rather fast. spages (StaticPages) ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ The "StaticPages"-plugin allows ewiki to access files in a given directory. If these files are in text format, ewiki will parse them as WikiPages. But if you put files with an extension .html, .htm or .php into one of the specified StaticPages` directories they will be returned as is from ewiki_page() - the .php files will of course get executed and their output is returned. The basename of the files in the directories to be used by spages will make up the WikiPageName with which the files will be accessible. Any given directory (see on top of plugins/spages.php) will be read recursively. So files in a subdirectory will get available as a page with a name like "subdir/FileName". If the name of the subdirectory contains a dot at the end, then the slash will be left out in favour of a dot: resulted in "subdir.FileName" for example. PHP scripts in a spages directory however have some restrictions, like not being able to return headers() or to access most global variables without use of the $GLOBALS[] syntax. If you rely on such functionality you should rather write an ordinary page plugin (which in fact is often much easier). From the output of .html and .php scripts only the parts between and will be returned as page content. Any head area will get stripped, as it would lead to completely invalid html code if it was returned as is by ewiki_page() into yoursite. To let this plugin load pages from directories, you should either edit the array on top of this plugin file, or define() the EWIKI_SPAGES_DIR (before! including the spages.php script), which then also would be read in. Alternatively you could call the ewiki_init_spages() function yourself to register a directory for processing (after! loading the spages plugin): include("plugins/spages.php"); ewiki_init_spages("/var/www/wiki/staticpages/"); You could also use this plugin to inline the ewiki database tools/ as virtual pages. Btw, it is very easy to make a StaticPage from a ewiki page plugin and vice versa. Please also note the 'tools/mkpageplugin' which can convert anything used as StaticPage into a page plugin. pluginloader ŻŻŻŻŻŻŻŻŻŻŻŻ The pluginloader plugin automatically loads ["action"] and ["page"] plugins, whenever necessary. This allows to skip dozens of include() statements within the config.php (which most always just slow down script startup). It is configured via a static array, that defines which plugins are allowed to be automatically invoked on request. Detailed explanaition is available within this script. init ŻŻŻŻ Handles database initialization using the distributed standard Wiki files from './init-pages'. Unlike the ewiki-builtin function to perform that task, this plugin first outputs informational notes to the user, prior database initialization. Once you have your SQL or ./files database initialized, you should disable this plugin (it then isn't required anymore). feature/appendonly ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ This plugin (a family of) implements the actual support for the _DB_F_APPENDONLY page flag. When the flag is set, and this plugin active, then ordinary users can further only append text to the page, and won't be able to edit the earlier written parts of it. So this implements a much softer approach than the _READONLY page flag. Also this plugin comes in three flavours, but you can often only load one of them: "appendonly" - Really allows just additions to be made to the page, each new separated by a horizontal bar. "appendwrite" - Allows to insert a page separator, which protects the upper part from getting edited by ordinary users. Everything below a horizontal bar (denoted by at least 16 minus signs) or a double horizontal bar remains editable by all users. This plugin activates only if the _APPENDONLY and _WRITEABLE flag is set. "appendcomments" - stores page additions in an separate database entry marked with _DB_F_PART, but allows this part to get edited as whole (like "appendwrite" plugin). The last one is probably not very useful, as it generates some overhead and in fact is a collection of various workarounds to accomplish the desired functionality (so it may prove little lifetime). feature/imgresize_gd ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Was extracted from the core during the R1.00f development releases. Automatically rescales uploaded images, if they are larger than EWIKI_IMAGE_MAXSIZE. As it uses the gd2 library, there must be support for this in your PHP binary. There are a lot of problems on Win32 systems, and also some Linux binarys (-dev ones) crash constantly if you load this plugin but don't have the libgd activated or available. feature/imgresize_magick ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Rescales uploaded images via the ImageMagick utility "mogrify", which is usually only available on UNIX systems. It should however be fairly simple to make this plugin work with some other image manipulation tool (at least with Linux). feature/imgfile_naming ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ This plugin overrides the default name assignment code for uploaded images, and keeps the original file name to a certain degree (unless it is considered frivolously silly, like "DSC00001.jpeg" or such things). You could now also disable the "internal://" prefix usuage, as ewiki can distinguish _TEXT from _BINARY database entries now for SQL backends. input_trimming ŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Checks all known ewiki input variables to prevent some possible injection / overflow problems. feature/pingback ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Will automatically add links to pages, when some PingBack-enabled blog (weblog) links it. Also will send out such pings to other sites whenever an URL is added on any WikiPage. Verifies incoming hyperlinks. feature/refererlog ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ When coming from an external site, adds the Referer: URL to the current page, after its validity has been verified. feature/xpi ŻŻŻŻŻŻŻŻŻŻŻ Allows you to later install .xpi plugins by simply uploading them with the "PlugInstall" page. You need to first define an administrator password (EWIKI_ADMIN_PW constant). There are also remote .xpi plugin directories which you can browse and allow for click-and-run addition of new extensions. All plugins can be disabled through the admin interface, or at least can be uninstalled again (for page plugins). With a loaded phpjs interpreter you can also allow your users to install the safe / sandbox-executed .jpi page plugins without password. feature/xpi0 ŻŻŻŻŻŻŻŻŻŻŻŻ If you don't need to install new or control old xpi plugins, you can get rid of the "PlugInstall" interface by using xpi0 instead of the big xpi extension. action/ plugins ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Action plugins are those, that can be activated ON individual pages. And usually are shown as links below a page. The ewiki-builtin EditThisPage, BackLinks and PageInfo are ["action"] plugins for example. action/diff ŻŻŻŻŻŻŻŻŻŻŻ Enables to view the differences between two saved page versions (what changes somebody has done to the page), but it is rather stupid and guessworking in how it does so. On a Unix system you might want to use gnu_diff instead. action/translation ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ This plugin adds a link to the GoogleLanguageTools or AltaVista BabelFish, which then remotely translated the current page into the users preferred language. It has support to detect the lang of the current pages content, to redirect to the right service. action/like_pages ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ LikePages is a search feature of WardsWiki, which scans for WikiPages whose name is somewhat similar to the one of the current page (the pagename must be made up of the same WikiWordParts so a page gets listed). action/raw ŻŻŻŻŻŻŻŻŻŻ Can be used to download the unrendered Wiki source of a page. rss ŻŻŻ Adds an action link to every page, which allows to retrieve RSS/Atom feeds for it, if the plugins/lib/feed extension was loaded. Also provides a Wiki-wide feed as [RSS] page or on RecentChanges and UpdatedPages. action/info_qdiff ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Adds the "quickdiff" action to the info/ page, which allows to review changes over all historic versions at once. action/translation ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Adds a link to Babelfish/GoogleLT to translate the current page into whatever the visitor has configured as most preferred lang. action/relatedchanges ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Shows when back- and fore-linked pages where changed last. plugins related to hypertext links ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ The linking/ plugin group deals with how links inside the Wiki will look and work. Some of them would also fall the "core enhancements" group, while others are just handy or for link beatification. linking/tcn ŻŻŻŻŻŻŻŻŻŻŻ ewiki evaluates the Accept-Language HTTP header modern browsers send with each request. This plugin now automatically brings up a variant of the currently requested page if it finds a match in the database. To make it work, you need to create pages with language suffixes in their names like: ThisPage.es ThisPage ThisPage.de or OtherPage OtherPage*nl Note, that there can always be one page in each name group without that suffix. This page then will be assumed to be in the default language (en) set by EWIKI_DEFAULT_LANG. If multiple page versions are available, then a list will be printed above the page title to allow users to override the prefered language guess of this plugin. linking/plural ŻŻŻŻŻŻŻŻŻŻŻŻŻŻ This plugin tries to alias plural and singular page names against each other. That is, "WikiPage" will be shown, whenever "WikiPages" was requested (and vice versa). linking/autolinking ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ The autolinking plugin allows to have automatic links inside the Wiki for words which exist in the database, but are no real WikiWords. This is made possible by the companion StaticPage admin plugin "spages/Admin/PrepareAutolinking", which must be invoked from time to time to update the db cache entry, which the autolinking plugin utilizes. linking/link_css ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Adds CSS classes to the links generated by the Wiki page formatting kernel, which then allow you to colorize (or to otherwise change appearance of links) via a style sheet. linking/link_icons ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ The link_icons plugin prepends icon s before registered link types, like the link_css plugin adds class="..." attributes to the html formatted links in every page. linking/link_target_blank ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Adds 'target="blank"' to link tags , which will result in most browsers opening pages in a new window. Note: this is never user-friendly. linking/linkexcerpts ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Adds a short preview text (with ) to every link of a page. This however requires multiple additonal database accesses (slower) and could enlarge delivered .html page sizes dramatically. linking/linkdatabase ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Is a page plugin, which provides a nearly compliant implementation of the page and link structure export function known from the UseMod WikiWare and MeatBall:LinkDatabase. This is useful for contributing to the upcoming InterWikiBatabase and BorgWiki. linking/instanturls ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Allows to specify URL abbreviations on one or more summary pages. This can be done using a table or a definition list to assign each URL a title, which then can be used on other pages as square bracket reference. The 'instanturl_find' plugin in addition allows to use the [find:] moniker to perform partial searches in the list of URL abbreviations, but also in the list of interwiki monikers. As fallback it searches for matching page names or redirects to Google. linking/titlefix ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Allows to swap [title|PageName] in square brackets [Page|title], because that can easily be detected, if the page already exists. interwiki/intermap ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ This plugin (in fact only a general include) extends the list of known InterWiki: prefixes with a more complete set created from the MeatBall interwiki.map. interwiki/editable ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Provides automatic read-in of the special page "EditableIntermap", so users can provide shortcuts for commonly referenced sites in a table or definition list. linking/xfn ŻŻŻŻŻŻŻŻŻŻŻ Adds pseudo-monikers for the "XHTML Friends Network". You can simply mix the well-known prefixes like an InterWiki moniker before any page name. [met:friend:neighbor:parent:UserName] This will translate into the typical then. appearance/ tweaks ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ There are various plugin hooks within ewiki, which allow to mangle text strings and data immediately before it would be returned as output. appearance/listpages_br ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ This plugin will produce
separated lists (for SearchPages, PageIndex, MostVisitedPages, and so on). appearance/listpages_ul ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Creates real