DokuWiki Installer


This page assists in the first time installation and configuration of Dokuwiki. More info on this installer is available on it's own documentation page.

DokuWiki uses ordinary files for the storage of wiki pages and other information associated with those pages (e.g. images, search indexes, old revisions, etc). In order to operate successfully DokuWiki must have write access to the directories that hold those files. This installer is not capable of setting up directory permissions. That normally needs to be done directly on a command shell or if you are using hosting, through FTP or your hosting control panel (e.g. cPanel).

This installer will setup your DokuWiki configuration for ACL, which in turn allows administrator login and access to DokuWiki's admin menu for installing plugins, managing users, managing access to wiki pages and alteration of configuration settings. It isn't required for DokuWiki to operate, however it will make Dokuwiki easier to administer.

Experienced users or users with special setup requirements should use these links for details concerning installation instructions and configuration settings.

For security reasons this script will only work with a new and unmodified Dokuwiki installation. You should either re-extract the files from the downloaded package or consult the complete Dokuwiki installation instructions

driven by DokuWiki powered by PHP
Proposal : Provide an extension adding Relationships to external bugs in remote bugtrackers [Mantis Bug Tracker Wiki]

User Tools

Site Tools


Proposal : Provide an extension adding Relationships to external bugs in remote bugtrackers

Authors :

This proposal has been added here for review by Mantis devs, accompanying An initial draft was made at , FYI.

We propose to have a plugin in Mantis which facilitates the monitoring of remote-bugs.

There are 2 goals for this extension of Mantis :

  • provide a formal way to describe pointers to other external bugs in remote bugtrackers, set by and displayed for the persons interested in the bugs (more formal than URLs added in notes, since a semantics is defined for types of relations).
  • allow the use of such relations by agents which could automatically monitor such external bugs. A first use could be to notify these interested persons whenever a status change of the remote bug is noticed by agents, as is done by bts-link for the debbugs Debian bugtracker (or similar features).

Bug relationships

Mantis already provides certain relationship_types in the “metadata”, for property of relations between bugs. Currently however, this feature is only for linking local bugs (in the same mantis instance). Through the plugin, we propose to add additional relationship_types and also allow the current relationship_types for external bugs (also called remote bugs / external bugs ?). The new relationship_types could represent different semantics, like:

  • “See also” : meant for general URL pointing to other bugs without further semantics
  • “Forwarded upstream” : meant for distributions monitoring upstream projects for instance (and used by agents like bts-link)
  • “External Duplicate of” : meant for duplicate bugs in other projects

In addition, the current relationship types used for local bugs could also be used for external bugs (parent / child, etc.) It will be the administrator's duty to define the relationship types in an understandable way, and compatible with the agents capabilities (see below).

Description of the data

Each local bug is permitted to have multiple relationships which connect it to different external bugs. Each of these relations would have:

  • a bug_id (local)
  • a URL of the external bug (could be split in remote bugtracker URL + ID in that bugtracker) * (optional) an external “master bug” in case the previous external one was closed as duplicate of that one
  • a relation_type among the ones configured globally (see bellow)
  • a log corresponding to the state changes of the remote bug over time as monitored by an agents, bts-link, for e.g. (during each periodic run, the agent appends to the log if there is a status change). The log contains a lists of entries :
    • the agent login
    • the date of addition
    • the status and other properties of the remote bug noticed at the time of processing (potentially formatted in a suitable way for agents to retrieve)
  • the login of the agent authorized to append to that log if set. If unset, the first agent to “apply” will be set.

There is a set of configured external_bugs_relation_types with :

  • a “label” supposedly meaningful (see above : “Forwarded upstream”, etc.), and known to agents monitoring these relationships
  • a “notify” property (this indicates that additions to the log will be notified to users monitoring the bug)

Whenever new elements are added to the external bug's log, notifications are sent by mantis to all users who have the monitoring property On for its local bug. These notifications are sent in the same way through emails, as is done for comments added to the bug, for all those monitoring it, reporter, etc.

The log would be available as RSS too.

As per the need of bts-link, the plugin would monitor specifically “forwarded-upstream” relations meaning that the bug is no longer local but needs to be addressed in an external bugtracker. Additional “resolution” values would be added to the existing ones :

  • fixed-upstream
  • reopened-upstream

These could be set by the bts-link agent, in addition to its additions to the relationship logs, to allow reports to be performed on such “pending” bugs which need to be considered by developers (in the “My view” page for instance).

The agent will fetch (through soap) a list of all bugs whose external bugs are to be monitored by bts-link (filtering by relation_ship types). This would consist of the local bug ids and the corresponding external bug URLs. By default only open bugs will be returned, but an option could be used to retrieve closed ones as well.

Whenever a related external bug is closed as a duplicate of another one, the one still open will be saved and proposed instead of the one recorded initially.

The bts-link allowed to monitor a relation_type on a mantis instance will extract the previous state from the most recent entry notifying the status in its log. In case concurrent tools are running, the others will not use that log nor notify users through mantis, but they could run nevertheless, using usertags and separate notification mechanisms (described in another document).

Note : the following proposal is made in the frame of the Helios project working on the subject of bugtracker synchronisation.

Note that in waiting for this feature to be integrated in Mantis, we have devised a working version of bts-link anyway, see :

mantisbt/issue/10543.txt · Last modified: 2009/07/03 11:09 by mdhar