NAME

       MojoMojo - A Wiki with a tree

SYNOPSIS

         # Set up database (see mojomojo.conf first)

         ./script/mojomojo_spawn_db.pl

         # Standalone mode

         ./script/mojomo_server.pl

         # In apache conf
         <Location /mojomojo>
           SetHandler perl-script
           PerlHandler MojoMojo
         </Location>

DESCRIPTION

       Mojomojo is a content management system, borrowing many concepts from wikis and blogs. It
       allows you to maintain a full tree-structure of pages, and to interlink them in various
       ways. It has full version support, so you can always go back to a previous version and see
       what's changed with an easy diff system. There are also a some of useful features like
       live AJAX preview while editing, tagging, built-in fulltext search, image galleries, and
       RSS feeds for every wiki page.

       To find out more about how you can use MojoMojo, please visit <http://mojomojo.org/> or
       read the installation instructions in MojoMojo::Installation to try it out yourself.

METHODS

   prepare
       Accommodate a forcing of SSL if needed in a reverse proxy setup.

   ajax
       Return whether the request is an AJAX one (used by the live preview, for example), as
       opposed to a rgular request (such as one used to view a page).

   expand_wikilink
       Proxy method for the MojoMojo::Formatter::Wiki expand_wikilink method.

   wikiword
       Format a wikiword as a link or as a wanted page, as appropriate.

   pref
       Find or create a preference key. Update it if a value is passed, then return the current
       setting.

   pref_cached
       Get preference key/value from cache if possible.

   fixw
       Clean up wiki words: replace spaces with underscores and remove non-\w, / and .
       characters.

   tz
       Convert timezone

   prepare_action
       Provide "No DB" message when one needs to spawn the db (script/mojomojo_spawn.pl).

   prepare_path
       We override this method to work around some of Catalyst's assumptions about dispatching.
       Since MojoMojo supports page namespaces (e.g. "/parent_page/child_page"), with page paths
       that always start with "/", we strip the trailing slash from "$c->req->base". Also, since
       MojoMojo indicates actions by appending a ".$action" to the path (e.g.
       "/parent_page/child_page.edit"), we remove the page path and save it in
       "$c->stash->{path}" and reset "$c->req->path" to $action.  We save the original URI in
       "$c->stash->{pre_hacked_uri}".

   base_uri
       Return "$c->req->base" as an URI object.

   uri_for
       Override "$c->uri_for" to append path, if a relative path is used.

   uri_for_static
       "/static/" has been remapped to "/.static/".

   _cleanup_path
       Lowercase the path and remove any double-slashes.

   _expand_path_elements
       Generate all the intermediary paths to "/path/to/a/page", starting from "/" and ending
       with the complete path:

           /
           /path
           /path/to
           /path/to/a
           /path/to/a/page

   get_permissions_data
       Permissions are checked prior to most actions, including "view" if that is turned on in
       the configuration. The permission system works as follows:

       1.  There is a base set of rules which may be defined in the application config. These
           are:

               $c->config->{permissions}{view_allowed} = 1; # or 0

           Similar entries exist for "delete", "edit", "create" and "attachment".  If these
           config variables are not defined, the default is to allow anyone to do anything.

       2.  Global rules that apply to everyone may be specified by creating a record with a role
           id of 0.

       3.  Rules are defined using a combination of path(s)?, and role and may be applied to
           subpages or not.

           TODO: clarify.

       4.  All rules matching a given user's roles and the current path are used to determine the
           final yes/no on each permission. Rules are evaluated from least-specific path to most
           specific. This means that when checking permissions on "/foo/bar/baz", permission
           rules set for "/foo" will be overridden by rules set on "/foo/bar" when editing
           "/foo/bar/baz". When two rules (from different roles) are found for the same path
           prefix, explicit "allow"s override "deny"s. Null entries for a given permission are
           always ignored and do not affect the permissions defined at earlier level. This allows
           you to change certain permissions (such as "create") only while not affecting
           previously determined permissions for the other actions. Finally - "apply_to_subpages"
           "yes"/"no" is exclusive, meaning that a rule for "/foo" with "apply_to_subpages" set
           to "yes" will apply to "/foo/bar" but not to "/foo" alone. The endpoint in the path is
           always checked for a rule explicitly for that page - meaning "apply_to_subpages = no".

   user_role_ids
       Get the list of role ids for a user.

   check_permissions
       Check user permissions for a path.

   check_view_permission
       Check if a user can view a path.

SUPPORT

       •   <http://mojomojo.org>

       •   IRC: <irc://irc.perl.org/mojomojo>.

       •   Mailing list: <http://mojomojo.2358427.n2.nabble.com/>

       •   Commercial support and customization for MojoMojo is also provided by Nordaaker Ltd.
           Contact "arneandmarcus@nordaaker.com" for details.

AUTHORS

       Marcus Ramberg "marcus@nordaaker.com"

       David Naughton "naughton@umn.edu"

       Andy Grundman "andy@hybridized.org"

       Jonathan Rockway "jrockway@jrockway.us"

       A number of other contributors over the years:
       https://www.ohloh.net/p/mojomojo/contributors

COPYRIGHT

       Unless explicitly stated otherwise, all modules and scripts in this distribution are:
       Copyright 2005-2010, Marcus Ramberg

LICENSE

       You may distribute this code under the same terms as Perl itself.