NAME
CGI::Wiki - A toolkit for building Wikis.
DESCRIPTION
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.
SYNOPSIS
# 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 = CGI::Wiki::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 = CGI::Wiki::Search::SII->new(
indexdb => $indexdb );
my $wiki = CGI::Wiki->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) {
print_success($node);
} else {
handle_conflict($node, $submitted_content);
}
}
METHODS
- new
-
# Set up store, search and formatter objects. my $store = CGI::Wiki::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 = CGI::Wiki::Search::SII->new( indexdb => $indexdb ); my $formatter = My::HomeMade::Formatter->new; my $wiki = CGI::Wiki->new( store => $store, # mandatory search => $search, # defaults to undef formatter => $formatter # defaults to something suitable );
store
must be an object of typeCGI::Wiki::Store::*
andsearch
if supplied must be of typeCGI::Wiki::Search::*
(though this isn't checked yet - FIXME). Ifformatter
isn't supplied, it defaults to an object of class CGI::Wiki::Formatter::Default.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 CGI::Wiki::Store::SQLite, CGI::Wiki::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 aformat
method which takes in raw text and returns the formatted version. See CGI::Wiki::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.
- retrieve_node
-
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:
- last_modified
- version
- checksum
- 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. Theversion
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.
- verify_checksum
-
my $ok = $wiki->verify_checksum($node, $checksum);
Sees whether your checksum is current for the given node. Returns true if so, false if not.
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_backlinks
-
# List all nodes that link to the Home Page. my @links = $wiki->list_backlinks( node => "Home Page" );
- list_dangling_links
-
# 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.
- list_all_nodes
-
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.
- list_nodes_by_metadata
-
# 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
andmetadata_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 theignore_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_recent_changes
-
# Nodes changed in last 7 days - each node listed only once. my @nodes = $wiki->list_recent_changes( days => 7 ); # All changes in last 7 days - nodes changed more than once will # be listed more than once. my @nodes = $wiki->list_recent_changes( days => 7, include_all_changes => 1, ); # Nodes changed between 1 and 7 days ago. my @nodes = $wiki->list_recent_changes( between_days => [ 1, 7 ] ); # Changes since a given time. my @nodes = $wiki->list_recent_changes( since => 1036235131 ); # Most recent change and its details. my @nodes = $wiki->list_recent_changes( last_n_changes => 1 ); print "Node: $nodes[0]{name}"; print "Last modified: $nodes[0]{last_modified}"; print "Comment: $nodes[0]{metadata}{comment}"; # Last 5 restaurant nodes edited. my @nodes = $wiki->list_recent_changes( last_n_changes => 5, metadata_is => { category => "Restaurants" } ); # Last 5 nodes edited by Kake. my @nodes = $wiki->list_recent_changes( last_n_changes => 5, metadata_was => { username => "Kake" } ); # Last 10 changes that weren't minor edits. my @nodes = $wiki->list_recent_changes( last_n_changes => 5, metadata_wasnt => { edit_type => "Minor tidying" } );
You must supply one of the following constraints:
days
(integer),since
(epoch),last_n_changes
(integer). You may also supply one of the following constraints:metadata_is
,metadata_isnt
,metadata_was
,metadata_wasnt
. Each should be a ref to a hash with a single key and value.metadata_is
andmetadata_isnt
look only at the metadata that the node currently has.metadata_was
andmetadata_wasnt
also take into account the metadata of previous versions of a node. NOTE: If you supply either or both ofmetadata_was
andmetadata_wasnt
then anymetadata_is
andmetadata_isnt
will be ignored.Returns results as an array, in reverse chronological order. Each element of the array is a reference to a hash with the following entries:
name: the name of the node
version: the latest version number
last_modified: the timestamp of when it was last modified
metadata: a ref to a hash containing any metadata attached to the current version of the node
Unless you supply
include_all_changes
,metadata_was
ormetadata_wasnt
, each node will only be returned once regardless of how many times it has been changed recently. - node_exists
-
if ( $wiki->node_exists( "Wombat Defenestration" ) { # do something about the weird people infesting your wiki } else { # ah, safe, no weirdos here }
Returns true if the node has ever been created (even if it is currently empty), and false otherwise.
- delete_node
-
$wiki->delete_node($node);
Deletes the node completely, including removing all its history. 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 doesn't exist, returns true if no error.
- search_nodes
-
# 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, perhaps.
Defaults to AND searches (if $and_or is not supplied, or is anything other than
OR
oror
).Searches are case-insensitive.
Croaks if you haven't defined a search backend.
- supports_phrase_searches
-
if ( $wiki->supports_phrase_searches ) { return $wiki->search_nodes( '"fox in socks"' ); }
Returns true if your chosen search backend supports phrase searching, and false otherwise.
- supports_fuzzy_searches
-
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 otherwise.
- fuzzy_title_match
-
NOTE: This section of the documentation assumes you are using a search engine which supports fuzzy matching. (See above.) The CGI::Wiki::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 score.
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.
- register_plugin
-
my $plugin = CGI::Wiki::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 node.
If the plugin
isa
CGI::Wiki::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 CGI::Wiki::Plugin subclasses can use thedatastore
,indexer
andformatter
methods as it needs to. - get_registered_plugins
-
my @plugins = $wiki->get_registered_plugins;
Returns an array of plugin objects.
- write_node
-
my $written = $wiki->write_node($node, $content, $checksum, \%metadata); if ($written) { display_node($node); } else { handle_conflict(); }
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
undef
.Returns 1 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.
- format
-
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. - store
-
my $store = $wiki->store; my $dbname = eval { $wiki->store->dbname; } or warn "Not a DB backend";
Returns the storage backend object.
- search_obj
-
my $search_obj = $wiki->search_obj;
Returns the search backend object.
- formatter
-
my $formatter = $wiki->formatter;
Returns the formatter backend object.
SEE ALSO
For a very quick Wiki startup without any of that icky programming stuff, see Tom Insam's CGI::Wiki::Kwiki, an instant wiki based on CGI::Wiki.
Or for the specialised application of a wiki about a city, see the OpenGuides distribution.
CGI::Wiki allows you to use different formatting modules. Text::WikiFormat might be useful for anyone wanting to write a custom formatter. Existing formatters include:
CGI::Wiki::Formatter::Default (in this distro)
There's currently a choice of three storage backends - all database-backed.
CGI::Wiki::Store::MySQL (in this distro)
CGI::Wiki::Store::Pg (in this distro)
CGI::Wiki::Store::SQLite (in this distro)
CGI::Wiki::Store::Database (parent class for the above - in this distro)
A search backend is optional:
CGI::Wiki::Search::DBIxFTS (in this distro, uses DBIx::FullTextSearch)
CGI::Wiki::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:
If writing a plugin you might want an easy way to run tests for it on all possible backends:
CGI::Wiki::TestConfig::Utilities (in this distro)
Other ways to implement Wikis in Perl include:
CGI::Kwiki (an instant wiki)
UseModWiki http://usemod.com
Chiq Chaq http://chiqchaq.sourceforge.net/
AUTHOR
Kake Pugh (kake@earth.li).
SUPPORT
Questions, feature requests and bug reports should go to cgi-wiki-dev@earth.li
COPYRIGHT
Copyright (C) 2002-2004 Kake Pugh. All Rights Reserved.
This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
FEEDBACK
Please send me mail and tell me what you think of this, particularly if something is broken or confusing. I would much rather fix it than not know. I love getting mail, even if all it says is "I used your thing and I like it", or "I didn't use your thing because of X".
You could also subscribe to the dev list at http://www.earth.li/cgi-bin/mailman/listinfo/cgi-wiki-dev
CREDITS
Various London.pm 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.
GRATUITOUS PLUG
I'm only obsessed with Wikis because of the Open Guide to London -- http://openguides.org/london/
1 POD Error
The following errors were encountered while parsing the POD:
- Around line 728:
You forgot a '=back' before '=head1'