The MediaWiki Integration AMP integrates MediaWiki with Alfresco.
This is done by installing MediaWiki into the Alfresco WAR using an AMP and then making use of the PHP capabilities made available by installing the PHP Integration AMP to extend MediaWiki to work closely with Alfresco.
The objectives of the MediaWiki integration are as follows:
Simple and automatic installation of Mediawiki, running within the same JVM as the repository
All content entered into MediaWiki stored in the Alfresco repository
A standard MediaWiki install can be used with no need to modify core source code
Configuration of MediaWiki possible from within the repository
Integration capable of supporting mutiple MediaWiki's
Permission and authentication of MediaWiki configured and controlled from the Alfresco repository
A MediaWiki space viewable from the web client UI, customised to allow configuration and control of the wiki
MediaWiki content library integrated with Alfresco, so content is stored and managed in the repository
MediaWiki search capable of leveraging the Alfresco search capabilities
The MediaWiki Alfresco Integration uses a standard MediaWiki installation. This source files of the MediaWiki distribution are installed into the Alfresco WAR by packaging them into an AMP and installing them using the module management tool.
The MediaWiki Integration AMP is dependent on the PHP capabilities provided by the PHP Integration AMP. The PHP integration AMP integrates the Quercus Java written PHP engine and provides a Alfresco PHP API to access the standard Alfresco functionality. With this AMP installed templates and scripts can be written in PHP and also PHP code can be hosted within the repository WAR and served to clients.
It is this capability that allows us to host a standard, PHP written, MediaWiki instance within the Alfresco WAR. Without modification, this instance of MediaWiki could be accessed normally and will allow access to MySQL databases, meaning setup of MediaWiki is as expected.
In order to achieve the objectives set out above, the installed MediaWiki instance is primed with a customized localsettings.php file. In a standard MediaWiki installation, this file contains the configuration values of the MediaWiki installation.
In the Alfresco Integration, the localSetttings.php file does a few jobs for us. The first is to retrieve the context of the wiki in relation to the repository.
At this point we should take a step back and look at how we relate an instance of MediaWiki with the repository. Part of the MediaWiki Integration AMP includes a custom content model, which defines a MediaWiki space content type. This extends the default space definition and provides a structure where we can store wiki content, configure the wiki and define the wiki users.
To this end, when MediaWiki is accessed, the related Wiki space needs to be determined so that the appropriate configuration, authentication details, and content can be accessed. This context is expected as an additional parameter on the request URL where the node reference of the related wiki space is provided. It is this parameter that the localSettings.php reads and stores in the PHP session for later use. Storing this information in the session means that it is only the first call to Mediawiki that requires the wiki space to be provided.
Later we will talk about how we can support multiple MediaWikis in one repository and the need for providing the context in this manner will become clearer.
Another important job the modified localSettings.php does is to bind the Alfresco external store and authentication implementations to the MediaWiki integration. Once bound in correctly, they take responsibility for storing the content of the wiki and authentication of the wiki, respectively.
As well as binding these alternative implementations, the localSettings.php hooks some supporting functions to standard MediaWiki events. From these hook points, information about the flow of content can be retrieved and this information be provided to Alfresco implementations.
Alfresco MediaWiki Content Store
Looking at the Alfresco external store in some more detail, once hooked into MediaWiki correctly, it will intercept all calls made to store and retrieve the content of the wiki. With these calls intercepted the content can be streamed into the wiki's associated space as regular content objects. Some simple meta data relating to the namespace and title of the content is maintained (ie: the name of the content in the repository will match the title of the content in mediawiki) and the version history is also synced, so when a page is edited in mediawiki a new version of the associated content in the repository is also created.
Once the content is stored within the Alfresco repository it can be used in other content processes, but in the initial implementation any modifications made to the content directly in the repository will not be reflected back into MediaWiki. This may be possible to do by using the MediaWiki rest-like API that is partially available in later versions. Policies could be placed around the mediawiki content in the repository and update calls made to MediaWiki, via this API, to ensure the MediaWiki meta0data is kept up to date.
Alfresco/MediaWiki Authentication Integration
The authentication implementation redirects any authentication requests back to Alfresco. More specifically, in order for a user to be authenticated as a user of the MediaWiki instance, the user must be a valid user of the repository and also have the correct permissions on the associated MediaWiki space.
The integration AMP provides a custom permission model that defines two custom permission roles that can be assigned to users of a MediaWiki space:
WikiAdmin - have permissions to not only create and edit content in the wiki space, but also to change the configuration of the wiki
WikiUser - have permissions to read and edit content in the wiki space
If a repository user is assigned either of these permission roles on a wiki space, then they will be allowed to login to the associated MediaWiki instance via the standard MediaWiki interface.
In the initial implementation, users can not create new accounts on the MediaWiki site and to ensure this is not the case, MediaWiki is configured to disable this option. This is specified in the provided localSettings.php. In future, it should be possible, if appropriate, to allow guest users access to the wiki and also to allow these guest users to register on the wiki, consequently creating user accounts in the repository.
Other context parameters that can be passed to Alfresco MediaWiki integration are a user name and ticket. If these parameters are provided on the request URL, then the localSettings.php file will retrieve them and try to use them to automatically authenticate against the repository with. This provides a way to link directly into the MediaWiki instance from another Alfresco context (for example, the web client) without the need to redirect the user to the MediaWiki login screen.
The final job the localSettings.php file does is to retrieve the configuration settings for MediaWiki from the associated wiki space in the repository. Each wiki space has a child object that holds the configuration properties for the associated MediaWiki instance. Normally these settings are enteterd directly into the localSettings.php file of a MediaWiki installation, but by storing them in the repository against the wiki space, it keeps the physical MediaWiki code installed neutral to the instance of the wiki space. This means that in one repository, we can have multiple wiki spaces, all with different configuration, all driven off the same installed MediaWiki code. Each different MediaWiki content is shown by simply providing the relevant wiki space node reference on the request URL, as discussed earlier.
The configuration information stored for the wiki on the space consists of the name of the wiki and the MediaWiki database connection details. These can be edited via the web client UI and further configuration values can be added by extending the content model to include them, to both the content model and the UI configuration.