From Mahara Wiki

< Mahara日本語ドキュメント‎ | 開発者エリア

作成中です - mits (talk)



MaharaはPHPで書かれたウェブアプリケーションであり、Moodle、Drupal、phpBB等と極めて類似しています。フレームワークのような機能を提供するためいくつかのライブラリを使用しますが、それ自体はZendフレームワークのようなPHPフレームワークをベースとしているわけではありません 実際のところ、Maharaはデータベースアクセス/フォーム構築のためのライブラリおよびプラグインアーキテクチャ等、あなたがその中で作業するために必要なフレームワークを提供して、あなたのカスタマイズをコアのハッキングから遠ざけることを可能にします。この意味においてMaharaはDrupalおよびMoodleのようなプラグイン脱着可能な製品と極めて類似しています。


Maharaのコアには「プラグイン」という概念があります。Maharaの機能の大部分 (コア機能でさえも) はプラグインの記述により実装されます。そして、あなたが変更したいMaharaの部分がプラグイン化されていない場合、Maharaは簡単にハックできるよう設計されています。

ハッカビリティ Hackability

Maharaは高度にプラグイン可能であり、ハックしやすいようゼロから設計されています。私たちは意図的にMaharaをPHPで記述することを選択しました - PHPおよびLAMPスタックに精通している開発者の膨大なコレクションが存在するためです。Mahara can run on many variations LAMP, including swapping Linux for Solaris/BSD/Mac, Apache for Nginx/Lighttpd, and MySQL for PostgreSQL (which is the preferred DBMS to use). MaharaはLinuxをSolaris/BSD/Macに交換、ApacheをNginx/Lighttpdに交換、そしてMySQLをPostgreSQL (これは望ましいDBMSです) に交換する等、多くのバリエーションのLAMP上で動作させることが可能です。People have also got Mahara going under Windows and IIS, though the Mahara team doesn't explicitly test under such conditions. Patches are welcome :)

Speaking of patches, Mahara is free, open source software (as you probably already know). There is a small army of developers on the team working on new functionality, bug fixes, helping in the forums and generally improving Mahara every day. Surrounding them is a community of enthusiasts, translators, volunteers, developers and users who improve Mahara in many ways - from developing new features to reporting bugs to suggesting the best way to use Mahara. The point is, it's free software which means you're absolutely encouraged to hack it to death!

Plugin System

A key feature of Mahara's architecture is the plugin system. All sorts of parts of Mahara are pluggable - from the types of content users can have, to how users are authorised, right through to how search is implemented and how groups work. All plugins in Mahara, regardless of their type (more on that in the next section), share some functionality such as the ability to register cron jobs and subscribe to events. There are quite a few subsystems in place to make the job of writing plugins easier as well.

Plugin Types

Where parts of Mahara are pluggable, an API has been created especially for that purpose. For example, the API for user content types contains methods dealing with the content itself and ownership of the content, while the searching API provides methods detailing what search results are required. We call all of these a different type of plugin. Here are some examples:

  • The artefact plugin type deals with user content (an item of user content is called an artefact, hence the name).
  • The auth plugin type has an API for authorising user accounts.
  • The blocktype plugin type provides a pluggable way to put new types of block into the system.

As of Mahara 1.1, the following plugin types are available: artefact, auth, blocktype, grouptype, interaction, notification and search.

This approach has some nice benefits. For example, in parts of the system where one of the plugin types is being used, we don't have to ask every single plugin in the system whether it supports the API - only plugins of the correct type will be used. Plugin types also allows us to customise the API for the actual requirements. For example, a plugin dealing with search can just implement the search API methods, and doesn't have to say that it doesn't support user content, notifications or anything else for that matter.

On disk: Each plugin type has a directory in the htdocs/ folder. Each of these directories contains a lib.php


Given the previous section, the plugins themselves are simply instances of a plugin type. So for example, for artefact, the Mahara core ships with plugins for blogs, a file manager, resume and profile information. And in notification, Mahara has 'internal' (which logs messages to a user's activity log), email and emaildigest.

Each plugin has to provide a lib.php, which contains at least one class definition. This class allows the plugin to register cron jobs and events, and also hook into more specific functionality for that plugin type. For example, artefact plugins can register new menu items for the main menu.

In the case of artefact plugins, each plugin can also provide one or more PHP scripts that render pages it requires. In this way, artefact plugins can present highly custom interfaces for managing content, while gaining all the benefits of sharing various properties with other items of content.

On disk: Each plugin is a subdirectory under the appropriate plugin type subdirectory. It provides a lib.php and version.php, and if it needs database tables, a db/ directory. Some plugin types have other directories too - such as theme/ or blocktype/.

In code: Each plugin's lib.php contains a Plugin class which extends Plugin. E.g., PluginArtefactBlog which extends PluginArtefact. This implements the appropriate API. Other classes may be necessary depending on the plugin type.

Next: Core Components