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

WARNING: This plugin is incompatible with PHP8. Uninstall this plugin before you upgrade to PHP8. You may find alternative plugins for renaming and deleting the page. You may see instructions on disabling plugin at https://forum.dokuwiki.org/d/17863-quick-reminder-what-to-do-when-a-plugin-doesnt-work-on-hogfather if you found the page is inaccessible after upgrading to PHP8.

Search and install the plugin using the Extension Manager. Refer to Plugins on how to install plugins manually.

Further:

• 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.

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.

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

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.

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

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.

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

• Merge pull request #12 from splitbrain-forks/php7-signature (2016-02-07 04:18)
• Adjust method signatures to match parent (2016-02-02 13:07)
• Update plugin info (2014-09-19 16:43)
• Merge pull request #9 from dturkalj/master (2014-09-19 16:42)
• Croatian translate (2014-09-19 15:44)
• Croatian translate (2014-09-19 15:44)
• Croatian translate (2014-09-19 15:43)
• Update plugin info (2013-03-19 03: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

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.

I'm working on a project where work done in subdirectories can be cloned to other subdirectories. So for example, I'm building a course (say GEOG 420) and I search other courses and find a page from GEOG 346 I'd like to clone and edit.

The way I'd like it to work is I clone the page, and it brings the revision history along with it, writes “cloned from” to the new page log and “page cloned by” to the old page log. It otherwise works much like rename page, but without deleting old files.

In my perfect world there'd also be a checkbox “Clone media from this namespace into new namespace?” so that relative image links would still work, but that's more dream than necessity.

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

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;
		}
	}

— Theo-K 2010/12/29 11:39

Thank you for pointing it out. But I added if (auth_quickaclcheck($ID)<AUTH_EDIT) return; instead. — danny0838 2010/12/29 15:18

Could you add a setting to make this functional availible only for admins and managers? — Malamut 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? — danny0838 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
— Theo-K 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. — Malamut 2011/01/02 13:23

This feature is added in the 2011/11/16 release. Set user_rename in the config manager. — danny0838 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-K 2010/12/30 09:03

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

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

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

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

Remedy:
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. 2012/06/28 18:46

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
146a147,155
> 
>       <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

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?)

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. — danny0838 2012/07/05 18:43

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 Turner 2012/06/11 18:55

Hello,

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

Please could you get a direct URL for downloading ?

Thanks.

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

Jan

We are not going to support this plugin. Although updates might be possible in the future, they would be rather small or personal. It is welcome to take over the whole job, using the same name or another name, under the given license (GPL 2).

If your are going to keep developing using the same name, please leave a note and update the plugin info and relink the download link, source repo, etc. to yours in this page. If you are going to take over the source repo also, please send us a message in the GitHub and we'll transfer the ownership. First come first win. — danny0838 2015-01-18 11:42