[Show/Hide Right Column]

This feature is superceded by Flagged Revisions in Tiki8.

Wiki Staging & Approval tab

Use this tab to allow wiki pages to be "staged (drafted) before they are "approved" (published)

To Access
From the Administer Wiki page, click the Staging and Approval tab.

You must enable and configure the necessary categories before enabling this feature.

Staging and Approval tab
Staging and Approval tab

Setting Description Default
Use wiki page staging and approval
Force bounce of editing of approved pages to staging
Delete staging pages at approval As soon as a page is approved the staging page is deleted
If not in the group, edit is always redirected to the staging page edit: This allow you to create new pages in a staging status.
Page name
Unique page name prefix to indicate staging copy: A prefix is used to indicate staging copy: This is required.
Basically staging copies of (approved) wiki pages are marked and recognized by having a prefix in front of their name. For example, if the prefix is set to "*", which is the default, the page "*Using Tiki" will be the staging copy of the page "Using Tiki". If you like, you can replace the prefix with something more meaningful, e.g. "On staging - ". Note, however, that if you change the prefix after initial configuration, you will need to rename the old staging copy pages in order to preserve the link between staging and approved versions. Otherwise, new staging copies based on the new prefix will begin to be used.
Hide page name prefix If selected, the prefix will be hidden in the page name that is shown on top of pages as they are viewed and edited (there is already will be a separate message on these pages to indicate to a user that he is viewing a page which is staging copy). The prefix is still shown on other pages, e.g. lists of pages, etc... as they will be relevant in those cases.
Staging: It is highly recommended to select a category to put staging pages in. You can then set permissions for this category, for example, edit perms and view perms both for registered users only. When staging pages are edited, they are automatically placed in this category when a user saves the page. This happens regardless of what other/no categories are selected by the user. None
Approved (mandatory for feature to work): None
Out-of-sync: If "Delete staging pages at approval" is not activated, it is highly recommended to select a category to identify pages that are out of sync. When a user saves edits to staging pages, they are automatically placed in this category regardless of what other/no categories are selected by the user. At the same time, when these staging pages are approved, they are taken out of that category. If this setting is off, staging pages are always considered "out of sync" and there will be no indication, so setting this is really useful. Moreover, you can review pages that are out of sync through browsing the category. None
Categorize approved pages with categories of staging copy on approval If selected, the categorization of the approved page is set to that of the staging page upon approval, with the exception that auto-categorization of the special categories configured in this system are not affected (on approval, the approved copy will not have the category for staging pages set, and will continue to have the category for approved pages set).
Replace freetags with that of staging pages, on approval If selected, this replaces the freetags set on the approved page to those in the staging page upon approval.
Add new freetags of approved copy (into tags field) when editing staging pages If selected, when a user edits a staging page, freetags that are in the approved copy but not in the staging page will automatically be inserted into the freetags field. An editor/document reviewer will have a chance to change these tags before his final edit before approving.

Wiki Page Staging and Approval

Requirements: This feature requires categories to be turned on and categories created before it will work (see below).

The information below may be a bit out of date now. For best results, see http://profiles.tiki.org/Staging_and_Approval

Introduced in Tiki2.

This feature is similar but different than the articles and submissions feature. Articles are like newspaper articles, once approved and published, they normally don't change. Whilst wiki pages are, by nature, always in flux.

This is a feature to allow wiki pages to be "staged" or drafted before they are approved (published). This is useful, for example, to have a staging area where open contributions are welcome, but at the same time to have an official pr published knowledge base that is extremely stable, hence needing some kind of approval before page changes are shown there. This feature works with the groups and categories features to have customizable access to pages with different status.

Documentation site has a policy that
  • approved pages are visible to the public, but are updated (approved) only by senior editors.
  • meanwhile any registered user can edit the draft version of the page, which is reviewed periodically and approved (or not) by senior editors.

Sample use case

This is not meant to be definitive, but has been tested to work.

2 groups: author / approver
2 categories: staged / approved

  1. An author creates a page XXXX in the staged category.
  2. If category notification set, approver receives a message.
  3. Anyone can edit the page while it remains in the staged category.
  4. An approver approves the page for the 1st time by categorizing it to approved category.
  5. Tiki automatically creates a page *XXXX with the staged category and without the approved category.
  6. An author can see the page *XXXX and edits it again. If he tries to edit XXXX, tw redirects him to edit *XXXX. An approver is also redirected to edit *XXXX if he tries to edit XXXX.
  7. If category notification set, approver receives a message whoever edits *XXXX. Alternatively, approvers can check the "Out of Sync" category for pages that have edits not yet approved.
  8. When ready, an approver approves the page, by clicking on "approve" that appear on top of *XXXX. Moreover, if not ready, the authors/approvers/ etc.. can all conduct edit war on the *XXXX until they are happy, before approving.
Because no one edits the approved page directly, there is no chance of conflict, at the cost of a small inconvenience to approvers.

Features that will be apparent

  • A link to approve a page appears while viewing staging pages if they are out of sync.
  • A link to show page history since the last approval (a diff) appears while viewing staging pages if the pages are out of sync. The determination of the version is based on the last edit date/time of the approved page, so it will not be correct if the approved page has been edited directly without going through the staging copy, another reason to use the "Force bounce option" above, but it is foreseeable that admins may want to be able to directly edit the approved page and consider that an "approved" version, so it depends on your needs.
  • A note appears on the edit page screen indicating to a user that he is editing a staging page and if the page is out of sync.

Important notes about creating new pages

  • When creating new pages as someone with permission to the approved category, place the page in the category for approved pages if this is a page that needs to be staged.
  • When creating new pages as someone without permission to the approved category, it really doesn't matter in which category the page is stored. However, this page cannot be "approved" the automated way until it is approving for the first time by someone with permission to include it in the category for approved pages. For convenient locating of new items created by these users, it is possible (using another feature), to set the default category to a category you can create such as "New Pages", for the different groups/levels of contributors as you need.

Important admin notes

  • Changing the categories settings explained above after initial install will require moving of pages to new categories to make sure that those specific features still work for those pages.
  • Renaming or changing parent of categories have no effect (the system refers to categories by their ID, not name).
  • Change the prefix setting after initial install will require Renaming the old staging copy pages in order to preserve the "link" between staging and approved versions.
  • Direct Renaming of staging pages have been blocked in tiki-rename.php for usability reasons, and Renaming of pages now checks and renames staging copies as well (based on prefix) if this feature feature_wikiapproval is on. Admins that have custom code doing Renaming of pages should be careful.

See attached comment for an example of perms


  • Wiki page attachments are not handled
  • Structures are not handled



Evolution of this feature

This feature will be probably abandoned in future Tiki releases and Flagged revisions will be used instead for a similar behavior.



Site Language


These keywords serve as "hubs" for navigation within the Tiki documentation. They correspond to development keywords (bug reports and feature requests):

Tiki Newsletter

Delivered fresh to your email inbox!
Newsletter subscribe icon
Don't miss major announcements and other news!
Contribute to Tiki