/ 
MojoMojo-1.12
River stage one • 1 direct dependent • 1 total dependent
/ MojoMojo

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).

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 allows override denys. 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

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.