Provided by: libwiki-toolkit-perl_0.85-1_all bug


       Wiki::Toolkit - A toolkit for building Wikis.


       Helps you develop Wikis quickly by taking care of the boring bits for you.  You will still
       need to write some code - this isn't an instant Wiki.


         # Set up a wiki object with an SQLite storage backend, and an
         # inverted index/DB_File search backend.  This store/search
         # combination can be used on systems with no access to an actual
         # database server.

         my $store     = Wiki::Toolkit::Store::SQLite->new(
             dbname => "/home/wiki/store.db" );
         my $indexdb   = Search::InvertedIndex::DB::DB_File_SplitHash->new(
             -map_name  => "/home/wiki/indexes.db",
             -lock_mode => "EX" );
         my $search    = Wiki::Toolkit::Search::SII->new(
             indexdb => $indexdb );

         my $wiki      = Wiki::Toolkit->new( store     => $store,
                                             search    => $search );

         # Do all the CGI stuff.
         my $q      = CGI->new;
         my $action = $q->param("action");
         my $node   = $q->param("node");

         if ($action eq 'display') {
             my $raw    = $wiki->retrieve_node($node);
             my $cooked = $wiki->format($raw);
             print_page(node    => $node,
                        content => $cooked);
         } elsif ($action eq 'preview') {
             my $submitted_content = $q->param("content");
             my $preview_html      = $wiki->format($submitted_content);
             print_editform(node    => $node,
                            content => $submitted_content,
                            preview => $preview_html);
         } elsif ($action eq 'commit') {
             my $submitted_content = $q->param("content");
             my $cksum = $q->param("checksum");
             my $written = $wiki->write_node($node, $submitted_content, $cksum);
             if ($written) {
             } else {
                 handle_conflict($node, $submitted_content);


             # Set up store, search and formatter objects.
             my $store     = Wiki::Toolkit::Store::SQLite->new(
                 dbname => "/home/wiki/store.db" );
             my $indexdb   = Search::InvertedIndex::DB::DB_File_SplitHash->new(
                 -map_name  => "/home/wiki/indexes.db",
                 -lock_mode => "EX" );
             my $search    = Wiki::Toolkit::Search::SII->new(
                 indexdb => $indexdb );
             my $formatter = My::HomeMade::Formatter->new;

             my $wiki = Wiki::Toolkit->new(
                 store     => $store,     # mandatory
                 search    => $search,    # defaults to undef
                 formatter => $formatter  # defaults to something suitable

           "store" must be an object of type "Wiki::Toolkit::Store::*" and "search" if supplied
           must be of type "Wiki::Toolkit::Search::*" (though this isn't checked yet - FIXME). If
           "formatter" isn't supplied, it defaults to an object of class

           You can get a searchable Wiki up and running on a system without an actual database
           server by using the SQLite storage backend with the SII/DB_File search backend - cut
           and paste the lines above for a quick start, and see Wiki::Toolkit::Store::SQLite,
           Wiki::Toolkit::Search::SII, and Search::InvertedIndex::DB::DB_File_SplitHash when you
           want to learn the details.

           "formatter" can be any object that behaves in the right way; this essentially means
           that it needs to provide a "format" method which takes in raw text and returns the
           formatted version. See Wiki::Toolkit::Formatter::Default for a simple example. Note
           that you can create a suitable object from a sub very quickly by using
           Test::MockObject like so:

             my $formatter = Test::MockObject->new();
             $formatter->mock( 'format', sub { my ($self, $raw) = @_;
                                               return uc( $raw );
                                             } );

           I'm not sure whether to put this in the module or not - it'd let you just supply a sub
           instead of an object as the formatter, but it feels wrong to be using a Test::* module
           in actual code.

             my $content = $wiki->retrieve_node($node);

             # Or get additional data about the node as well.
             my %node = $wiki->retrieve_node("HomePage");
             print "Current Version: " . $node{version};

             # Maybe we stored some of our own custom metadata too.
             my $categories = $node{metadata}{category};
             print "Categories: " . join(", ", @$categories);
             print "Postcode: $node{metadata}{postcode}[0]";

             # Or get an earlier version:
             my %node = $wiki->retrieve_node( name    => "HomePage",
                                              version => 2,
             print $node{content};

           In scalar context, returns the current (raw Wiki language) contents of the specified
           node. In list context, returns a hash containing the contents of the node plus
           additional data:

           metadata - a reference to a hash containing any caller-supplied metadata sent along
           the last time the node was written

           The "node" parameter is mandatory. The "version" parameter is optional and defaults to
           the newest version. If the node hasn't been created yet, it is considered to exist but
           be empty (this behaviour might change).

           Note on metadata - each hash value is returned as an array ref, even if that type of
           metadata only has one value.

             my $ok = $wiki->moderate_node(name => $node, version => $version);

           Marks the given version of the node as moderated. If this is the highest moderated
           version, then update the node's contents to hold this version.

             my $ok = $wiki->set_node_moderation(name => $node, required => $required);

           Sets if a node requires moderation or not.  (Moderation is required when $required is

           When moderation is required, new versions of a node will sit about until they're
           tagged as moderated, when they will become the new node.

             my $ok = $wiki->rename_node(old_name => $old_name, new_name => $new_name, create_new_versions => $create_new_versions );

           Renames a node, updating any references to it as required.

           Uses the internal_links table to identify the nodes that link to this one, and re-
           writes any wiki links in these to point to the new name. If required, it can mark
           these updates to other pages as a new version.

             my $ok = $wiki->verify_checksum($node, $checksum);

           Sees whether your checksum is current for the given node. Returns true if so, false if

           NOTE: Be aware that when called directly and without locking, this might not be
           accurate, since there is a small window between the checking and the returning where
           the node might be changed, so don't rely on it for safe commits; use "write_node" for
           that. It can however be useful when previewing edits, for example.

             # List all nodes that link to the Home Page.
             my @links = $wiki->list_backlinks( node => "Home Page" );

             # List all nodes that have been linked to from other nodes but don't
             # yet exist.
             my @links = $wiki->list_dangling_links;

           Each node is returned once only, regardless of how many other nodes link to it.

             my @nodes = $wiki->list_all_nodes;

           Returns a list containing the name of every existing node.  The list won't be in any
           kind of order; do any sorting in your calling script.

             # All documentation nodes.
             my @nodes = $wiki->list_nodes_by_metadata(
                 metadata_type  => "category",
                 metadata_value => "documentation",
                 ignore_case    => 1,   # optional but recommended (see below)

             # All pubs in Hammersmith.
             my @pubs = $wiki->list_nodes_by_metadata(
                 metadata_type  => "category",
                 metadata_value => "Pub",
             my @hsm  = $wiki->list_nodes_by_metadata(
                 metadata_type  => "category",
                 metadata_value  => "Hammersmith",
             my @results = my_l33t_method_for_ANDing_arrays( \@pubs, \@hsm );

           Returns a list containing the name of every node whose caller-supplied metadata
           matches the criteria given in the parameters.

           By default, the case-sensitivity of both "metadata_type" and "metadata_value" depends
           on your database - if it will return rows with an attribute value of "Pubs" when you
           asked for "pubs", or not.  If you supply a true value to the "ignore_case" parameter,
           then you can be sure of its being case-insensitive.  This is recommended.

           If you don't supply any criteria then you'll get an empty list.

           This is a really really really simple way of finding things; if you want to be more
           complicated then you'll need to call the method multiple times and combine the results
           yourself, or write a plugin.

       list_nodes_by_missing_metadata Returns nodes where either the metadata doesn't exist, or
       is blank
           Unlike list_nodes_by_metadata(), the metadata value is optional (the metadata type is

             # All nodes missing documentation
             my @nodes = $store->list_nodes_by_missing_metadata(
                 metadata_type  => "category",
                 metadata_value => "documentation",
                 ignore_case    => 1,   # optional but recommended (see below)

             # All nodes which don't have a latitude defined
             my @nodes = $store->list_nodes_by_missing_metadata(
                 metadata_type  => "latitude"

           This is documented in Wiki::Toolkit::Store::Database; see there for parameters and
           return values.  All parameters are passed through directly to the store object, so,
           for example,

             my @nodes = $wiki->list_recent_changes( days => 7 );

           does exactly the same thing as

             my @nodes = $wiki->store->list_recent_changes( days => 7 );

             my @nodes = $wiki->list_unmoderated_nodes();
             my @nodes = $wiki->list_unmoderated_nodes(
                                                           only_where_latest => 1

             $nodes[0]->{'name'}              # The name of the node
             $nodes[0]->{'node_id'}           # The id of the node
             $nodes[0]->{'version'}           # The version in need of moderation
             $nodes[0]->{'moderated_version'} # The newest moderated version

             Fetches details of all the node versions that require moderation (id,
              name, version, and latest moderated version).

             If only_where_latest is set, then only the latest version of nodes where
              the latest version needs moderating are returned.
             Otherwise, all node versions (including old ones, and possibly multiple
              per node) are returned.

             my @versions = $wiki->list_node_all_versions("HomePage");

             my @versions = $wiki->list_node_all_versions(
                                                           name => 'HomePage',
                                                           with_content => 1,
                                                           with_metadata => 0

           Returns all the versions of a node, optionally including the content and metadata, as
           an array of hashes (newest versions first).

       list_last_version_before List the last version of every node before a given date. If no
       version existed before that date, will return undef for version. Returns a hash of id,
       name, version and date
               my @nv = $wiki->list_last_version_before('2007-01-02 10:34:11')
               foreach my $data (@nv) {


             my $ok = $wiki->node_exists( "Wombat Defenestration" );

             # or ignore case - optional but recommended
             my $ok = $wiki->node_exists(
                                          name        => "monkey brains",
                                          ignore_case => 1,

           Returns true if the node has ever been created (even if it is currently empty), and
           false otherwise.

           By default, the case-sensitivity of "node_exists" depends on your store backend.  If
           you supply a true value to the "ignore_case" parameter, then you can be sure of its
           being case-insensitive.  This is recommended.

             my $needs = $wiki->node_required_moderation( "Wombat Defenestration" );

           Returns true if the node exists and requires moderation, and false otherwise.

             $wiki->delete_node( name => "Home Page", version => 15 );

           "version" is optional.  If it is supplied then only that version of the node will be
           deleted.  Otherwise the node and all its history will be completely deleted.

           Doesn't do any locking though - to fix? You probably don't want to let anyone except
           Wiki admins call this. You may not want to use it at all.

           Croaks on error, silently does nothing if the node or version doesn't exist, returns
           true if no error.

             # Find all the nodes which contain the word 'expert'.
             my %results = $wiki->search_nodes('expert');

           Returns a (possibly empty) hash whose keys are the node names and whose values are the
           scores in some kind of relevance-scoring system I haven't entirely come up with yet.
           For OR searches, this could initially be the number of terms that appear in the node,

           Defaults to AND searches (if $and_or is not supplied, or is anything other than "OR"
           or "or").

           Searches are case-insensitive.

           Croaks if you haven't defined a search backend.

             if ( $wiki->supports_phrase_searches ) {
                 return $wiki->search_nodes( '"fox in socks"' );

           Returns true if your chosen search backend supports phrase searching, and false

             if ( $wiki->supports_fuzzy_searches ) {
                 return $wiki->fuzzy_title_match( 'Kings Cross, St Pancreas' );

           Returns true if your chosen search backend supports fuzzy title searching, and false

           NOTE: This section of the documentation assumes you are using a search engine which
           supports fuzzy matching. (See above.) The Wiki::Toolkit::Search::DBIxFTS backend in
           particular does not.

             $wiki->write_node( "King's Cross St Pancras", "A station." );
             my %matches = $wiki->fuzzy_title_match( "Kings Cross St. Pancras" );

           Returns a (possibly empty) hash whose keys are the node names and whose values are the
           scores in some kind of relevance-scoring system I haven't entirely come up with yet.

           Note that even if an exact match is found, any other similar enough matches will also
           be returned. However, any exact match is guaranteed to have the highest relevance

           The matching is done against "canonicalised" forms of the search string and the node
           titles in the database: stripping vowels, repeated letters and non-word characters,
           and lowercasing.

           Croaks if you haven't defined a search backend.

             my $plugin = Wiki::Toolkit::Plugin::Foo->new;
             $wiki->register_plugin( plugin => $plugin );

           Registers the plugin with the wiki as one that needs to be informed when we write a

           If the plugin "isa" Wiki::Toolkit::Plugin, calls the methods set up by that parent
           class to let it know about the backend store, search and formatter objects.

           Finally, calls the plugin class's "on_register" method, which should be used to check
           tables are set up etc. Note that because of the order these things are done in,
           "on_register" for Wiki::Toolkit::Plugin subclasses can use the "datastore", "indexer"
           and "formatter" methods as it needs to.

             my @plugins = $wiki->get_registered_plugins;

           Returns an array of plugin objects.

             my $written = $wiki->write_node($node, $content, $checksum, \%metadata, $requires_moderation);
             if ($written) {
             } else {

           Writes the specified content into the specified node in the backend storage; and
           indexes/reindexes the node in the search indexes (if a search is set up); calls
           "post_write" on any registered plugins.

           Note that you can blank out a node without deleting it by passing the empty string as
           $content, if you want to.

           If you expect the node to already exist, you must supply a checksum, and the node is
           write-locked until either your checksum has been proved old, or your checksum has been
           accepted and your change committed.  If no checksum is supplied, and the node is found
           to already exist and be nonempty, a conflict will be raised.

           The first two parameters are mandatory, the others optional. If you want to supply
           metadata but have no checksum (for a newly-created node), supply a checksum of

           The final parameter, $requires_moderation (which defaults to false), is ignored except
           on new nodes. For existing nodes, use $wiki->toggle_node_moderation to change the node
           moderation flag.

           Returns the version of the updated node on success, 0 on conflict, croaks on error.

           Note on the metadata hashref: Any data in here that you wish to access directly later
           must be a key-value pair in which the value is either a scalar or a reference to an
           array of scalars.  For example:

             $wiki->write_node( "Calthorpe Arms", "nice pub", $checksum,
                                { category => [ "Pubs", "Bloomsbury" ],
                                  postcode => "WC1X 8JR" } );

             # and later

             my @nodes = $wiki->list_nodes_by_metadata(
                 metadata_type  => "category",
                 metadata_value => "Pubs"             );

           For more advanced usage (passing data through to registered plugins) you may if you
           wish pass key-value pairs in which the value is a hashref or an array of hashrefs. The
           data in the hashrefs will not be stored as metadata; it will be checksummed and the
           checksum will be stored instead. Such data can only be accessed via plugins.

             my $cooked = $wiki->format($raw, $metadata);

           Passed straight through to your chosen formatter object. You do not have to supply the
           $metadata hashref, but if your formatter allows node metadata to affect the rendering
           of the node then you will want to.

             my $store  = $wiki->store;
             my $dbname = eval { $wiki->store->dbname; }
               or warn "Not a DB backend";

           Returns the storage backend object.

             my $search_obj = $wiki->search_obj;

           Returns the search backend object.

             my $formatter = $wiki->formatter;

           Returns the formatter backend object.


       For a very quick Wiki startup without any of that icky programming stuff, see Tom Insam's
       Wiki::Toolkit::Kwiki, an instant wiki based on Wiki::Toolkit.

       Or for the specialised application of a wiki about a city, see the OpenGuides

       Wiki::Toolkit allows you to use different formatting modules.  Text::WikiFormat might be
       useful for anyone wanting to write a custom formatter. Existing formatters include:

       ·   Wiki::Toolkit::Formatter::Default (in this distro)

       ·   Wiki::Toolkit::Formatter::Pod

       ·   Wiki::Toolkit::Formatter::UseMod

       There's currently a choice of three storage backends - all database-backed.

       ·   Wiki::Toolkit::Store::MySQL (in this distro)

       ·   Wiki::Toolkit::Store::Pg (in this distro)

       ·   Wiki::Toolkit::Store::SQLite (in this distro)

       ·   Wiki::Toolkit::Store::Database (parent class for the above - in this distro)

       A search backend is optional:

       ·   Wiki::Toolkit::Search::DBIxFTS (in this distro, uses DBIx::FullTextSearch)

       ·   Wiki::Toolkit::Search::SII (in this distro, uses Search::InvertedIndex)

       Standalone plugins can also be written - currently they should only read from the backend
       storage, but write access guidelines are coming soon. Plugins written so far and available
       from CPAN:

       ·   Wiki::Toolkit::Plugin::GeoCache

       ·   Wiki::Toolkit::Plugin::Categoriser

       ·   Wiki::Toolkit::Plugin::Locator::UK

       ·   Wiki::Toolkit::Plugin::RSS::ModWiki

       If writing a plugin you might want an easy way to run tests for it on all possible

       ·   Wiki::Toolkit::TestConfig::Utilities (in this distro)

       Other ways to implement Wikis in Perl include:

       ·   CGI::Kwiki (an instant wiki)

       ·   CGI::pWiki

       ·   AxKit::XSP::Wiki

       ·   Apache::MiniWiki

       ·   UseModWiki <>

       ·   Chiq Chaq <>


       Kake Pugh ( and the Wiki::Toolkit team (including Nick Burch and Dominic


       Questions should go to


            Copyright (C) 2002-2004 Kake Pugh.  All Rights Reserved.
            Copyright (C) 2006-2013 the Wiki::Toolkit team. All Rights Reserved.

       This module is free software; you can redistribute it and/or modify it under the same
       terms as Perl itself.


       The developer web site and bug tracker is at - please file bugs there as appropriate.

       You could also subscribe to the dev list at


       Versions between 0.75 and 0.79 inclusive contain a bug which prevents Recent Changes
       routines from working correctly if minor changes are excluded
       <>. You may wish to avoid upgrading to this version
       until it is fixed if this is important to you; the fix is however not trivial so noone has
       been able to step up yet.

       Other minor bugs are documented at <>


       Various types helped out with code review, encouragement, JFDI, style advice,
       code snippets, module recommendations, and so on; far too many to name individually, but
       particularly Richard Clamp, Tony Fisher, Mark Fowler, and Chris Ball.

       blair christensen sent patches and gave me some good ideas. chromatic continues to
       patiently apply my patches to Text::WikiFormat and help me get it working in just the way
       I need. Paul Makepeace helped me add support for connecting to non-local databases. Shevek
       has been prodding me a lot lately. The OpenGuides team keep me well-supplied with
       encouragement and bug reports.

       Nick Burch has been leading the way with development leading up to the release under the
       Wiki::Toolkit name.


       I'm only obsessed with Wikis because of the Open Guide to London --