It's better when it's simple

User Tools

Site Tools


This is an old revision of the document!

editx plugin

Compatible with DokuWiki

2013-03-06, 2012-10-13,2010-11-07, rincewind, Angua, Weatherwax, Binky

plugin Extended edit functions such as renaming or deleting a page

Last updated on

This extension has not been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues.

Similar to move, pagemove

Tagged with !experimental, delete, move, rename

The above download link is the latest release, which should be more stable. For the newest revision (may be experimental), go here.

Installation And Usage

Download and install the plugin using the Plugin Manager using the URL given above. Refer to Plugins on how to install plugins manually.

  • Go to the edit page and click on the link in the header: If you want to do a page management such as renaming, go here: (or simply use the action editx)
  • use the form to manage a page rename or deletion for the current page.

Moving a page

Move moves a page and all histories to the targeted name, leaving a redirection text on the old page. The move summary will be left in the source page history, the target page history, recent changes, and will be sent to the subscribers or the source of the target page.

If the target page exists or has a conflicting file (page, meta or attic files), the move cannot be done. Therefore if you move a page from A to B, you cannot move B back to A until you delete (no history) page A via this plugin or manually.

Authority requirements

  1. edit authority of the source page
  2. edit authority of the target page
  3. being in groups or users defined in user_rename

Moving a page (Without redirection)

If you want to perform a move without leaving a redirection and a note in the history, just check the checkbox No redirect, the source will be totally removed just as delete does.

Authority requirements

  1. delete file authority of the source page
  2. edit authority of the target page
  3. being in groups or users defined in user_rename_nr

Deleting a page

Delete removes all files in pages/ meta/ and attic/ related to the page, except .mlist. The delete summary will be left in the source page history, recent changes, and will be sent to the subscribers of the source page.

If no delete history is checked, there will be no history in the source page but still in the recent changes.

Authority requirements

  1. delete file authority of the page
  2. being in groups or users defined in user_delete


Here are configs in the configuration manager:

  • redirecttext: Text left after moving a page, and @ID@ refers to the target page. If it's left blank, the default text (in the language pack) is used.
    • If you have PageRedirect plugin installed, you can fill in ~~REDIRECT>:@ID@~~
    • If you have GOTO plugin, use ~~GOTO>:@ID@~~
    • If you have mediasyntax plugin, use #REDIRECT [[:@ID@]]
  • user_rename: The groups and/or users allowed to perform page name (note that edit authority is still needed, see above documentation), listed in comma seperated form.
    • If you want to enable for all with edit authority, leave it blank.
    • If you want to disable for all, write an impossible “user name” such as -.
  • user_rename_nr: similar to above
  • user_delete: similar to above




Translations can be put here, I'll check them in to the new version.

Note that the fixes in 2011/01/16 is big. German and Dutch translation, although in the language pack, may be outdated and errorsome. — danny0838danny0838

2011/01/16 17:12

I'm already use it in my personal wiki, works fine for me. — hatifnatthatifnatt

2011/05/28 17:50


I am going to add several features in the plugin, such as hiding/unhiding histories and recycle/recover page. If anyone has good ideas, tell me about 'em.

Automatically update all backlinks to point to the new location when a page is moved.

This eliminates the need to leave a redirect page with in the old location. This of course might cause a lot of page edits if the page is linked from many pages but it sure beats doing this by hand and not having redirect pages keeps things much cleaner and more manageable over time.

Yes! - this is the one thing the old pagemove did well. Maybe the old code can be reused ?

Please, can you give the status of Update Backlink ? Can you explain the following change: Revert "Feature: Added updated forward links and backlinks to case modification" (2013/03/11 15:24) ?


Translations can be put here, I'll check them in to the new version.

Note that the fixes in 2011/01/16 is big. German and Dutch translation, although in the language pack, may be outdated and errorsome. — danny0838 2011/01/16 17:12

  I'm already use it in my personal wiki, works fine for me. — hatifnatt 2011/05/28 17:50

Hide for unauthorized people

I wanted to avoid that unauthorized people (those who were not authorized to edit the page) see the 'intro' part and thus see the rename part of this plugin. To do this I made a small alteration in the function _prepend_to_edit in the action.php:

	function _prepend_to_edit(&$event, $param) {
        if ($event->data != 'edit') return;
		global $ID;
		$link = html_wikilink($ID.'?do=editx');
		$intro = $this->locale_xhtml('intro');
		$intro = str_replace( '@LINK@', $link, $intro );
		if (auth_quickaclcheck($ID)>=AUTH_EDIT) {
        print $intro;


2010/12/29 11:39

Thank you for pointing it out. But I added if (auth_quickaclcheck($ID)<AUTH_EDIT) return; instead. — danny0838danny0838

2010/12/29 15:18

Make available only of admins

Could you add a setting to make this functional availible only for admins and managers? — MalamutMalamut

2010/12/29 17:03

It should be possible but I didn't mean to do this since I think it's always better for people with edit authority to move a page instead of deleting and recreating a page, and checking delete file authority for page deletion is generally enough. Another reason is there is already a pagemove plugin doing it.
There are several ways that I've thought about to achieve the similar feature such as:
  1. Add a config whether to restrict AUTH_ADMIN to access action editx
  2. Config settings which restrict groups that are allowed to perform move, delete and purge
  3. Configs for authority requirement for move, delete and purge
Could you tell more about why and how you want the feature so we can make the best decision? — danny0838danny0838

2010/12/29 17:39
As it is now, those who don't have the rights to delete a page cannot do so with the editx plugin.. I personally agree that users should be allowed to move pages, which works fine if they both have the rights to edit in the old page and the new page. I would not like the situation that for every move the administrator should be contacted etc. More work, greater chance of errors.. but these are just my thoughts

2010/12/30 08:59
Because the page moving is not the most popular operation, but it's required to bring the wiki in order. So It'll be better if only maganers can rename pages to be sure, that all pages will be with correct names. Otherwise in some cases users can make very strangw redirection chain for example.
The best solution is to add option to config, something like “Who can move a page: All users with edit permissions, Only managers, Only admins”. By default it should be “All users…” of course. — MalamutMalamut

2011/01/02 13:23
This feature is added in the 2011/11/16 release. Set user_rename in the config manager. — danny0838danny0838

2011/01/16 16:56


The following line keeps creating errors:

foreach ($tasks as $task) rename($task[0],$task[1]);

When deleted the plugin seems to work fine though.. — Theo-KTheo-K

2010/12/30 09:03

Correction: I updated to todays version and now I don't see the errormessage..

Action on namespaces

:?: Is possible to add the function to delete/move even entire namespace with their all contents?

I would also appreciate operation on entire namespaces, including a copy function. A copy operation should only copy the last version, not the entire history of the pages in a namespace. – Use case: I'm counselling wiki users who need to copy the structure of a namespace including pagenames on a regular basis. The easiest way to do this seems to be by copying the existing namespace, thereby renaming the top level of the branch. This leaves the original pages intact. Of course all copied pages have to be cleaned up then. But copying seems to be a more efficient way than creating 40+ pages from scratch. Maybe this is an odd application of the plugin and there are better ways to achieve the goal. Leif – 2011/03/29

Headings in intro.txt

Right now, the 'edit' page is prepended with lang/*/intro.txt, which provides a link to the editx dialog. Using headings in intro.txt (the way it is done right now) is not such a good Idea, IMHO, as it clashes with plugin-creole (====== is interpreted as a 6th level heading in creole). Also, from an aesthetics point of view, I find that it somewhat clutters the editing dialog – which probably should be as simple and clean as possible to save space for the editing window. I would suggest keeping intro.txt as short as possible, e.g. just:

Page Management: @LINK@

Alternatively, a toolbar button could be used to open editx, but this would require some more invasive changes to the plugin due to the way the “mediapopup” buttons are addressed… — Benjamin Molitor 2011/02/13 16:31

Problems with var plugin

When using the plugin var: Deactivation of @Link@ in index.txt

Corrections of the following files:
file /editx/action.php line 30:

 OLD:        $intro = str_replace( '@LINK@', $link, $intro );
 NEW:        $intro = str_replace( '@%LINK%@', $link, $intro );

file /editx/lang/$lang/intro.txt line 3:

 OLD:        If you want to do a page management such as renaming, go here: @LINK@.
 NEW:        If you want to do a page management such as renaming, go here: @%LINK%@.

that's all.

This is fixed now in the var plugin. No further modifications in editx plugin required. (Fix) — M. S.Matthias Schulte

2012/06/28 18:46

Avoid eating up edit space

I modified the intro.txt to only say “====== Edit this page ======” and instead have a button in the lower bar, sort of in the same way as the old pagemove. This can be done by adding these lines to tpl/default/main.php

diff tpl/default/main.php.ORG tpl/default/main.php
>       <form class="button" method="get" action="<?php wl($ID)?>">
>         <div class="no">
>           <input type="submit" value="MoveThisPage" class="button" />
>           <input type="hidden" name="do" value="editx" />
>           <input type="hidden" name="id" value="<?php echo $ID?>" />
>         </div>
>       </form>

This puts a button with the text “MoveThisPage” in the lower bar - sort of where the old pagemove was.

If one uses a list of users that can use editx, it might be an idea to make this code conditional on the users permissions, but as I am not currently restricting users for this, I haven't. — L Sorth 2011/12/12

Compatibility with the data plugin

Hi, I have a data plugin installed. When I move a page with a data inside, data in database remains, but they should be deleted as the original page is actualy deleted. Does this plugin use the regular docuwiki page deletion method (which activates consequentant plugins?)

Dangerous deleting

I just accidentaly pressed wrong submit button and deleted my page including its history WITHOUT ANY WARNINGS! TWICE! The main editing form is very dangerous, because there are two SAME submit buttons, one renames the page and the other DELETES the whole page including history (which is default) without any warning. I suppose two changes: default keep history on changes and legacy javascript confirm on delete.

Added a checkbox for confirmation in the latest version. Hope this helps. — danny0838danny0838

2012/07/05 18:43

Compatibility problems with fckglite

Hello, the plugin is very interesting, but unfortunately it doesn't get along with fckglite. I tried it out with dokuwiki-2010-11-07 and Rincewind with the newest dailies of fckglite. Installation of editx always ends up with the menu bar of fckglite being “destroyed”. The error message is: Menu bar “Dokuwiki” does not exist (maybe not exactly, but in that way, I had to translate from German). The biggest problem is, that even after deinstallation of editx the problem persists, so to get fckglite working again you have to clear your browser and dns cache, delete everything under data/cache, change the settings for “compress” in the dokuwiki configuration (if checked, uncheck and vice versa) and restart your browser (and eventually reboot your computer, if that all doesn't help). As a good WYSIWYG editor is pretty mandatory for most users, it would be great, it this problem could get checked over and maybe solved. Because editx would be a very mandatory plugin for most users, too. – JBorchert, 2012-01-26

I tested latest editx with the latest distribution of fckgLite (Version 07), in Rincewind RC1, and had no problems. Tested as well with Angua. — Myron TurnerMyron Turner

2012/06/11 18:55

cannot download plugin with wget or plugin manager


I can't download plugin with Plugin Manager (or with wget) on GitHub.

Please could you get a direct URL for downloading ?


I had problems too with the downloadlink. I found on Gtihub a working link: editx on Github


plugin/editx.1394100857.txt.gz · Last modified: 2014-03-06 11:14 by