Summary: Talk Page for MovePage recipe
Maintainer: Petko (original author: Eemeli Aro)

Please add new threads below this line:

Older threads

These threads are for MovePage version 2018XXXX or older. Version 20240109 was a major rewrite and should be discussed above.

I think I found a bug. In our wikis we have:

$EnablePostAuthorRequired = 1;
$AuthorRequiredFmt = '<font size="+3" color="#ff3e1b">Fill in your username otherwise you cannot SAVE!</font>';

If movepage is used before any page has been saved, one will get the "Fill in your username..." prompt, and there is no way to specify a username!

/Johan Bengtsson, 2018-11-09

In the mean time you can disable $EnablePostAuthorRequired for the move actions. In config.php:

  if (($action=='copy') || ($action=='move') || ($action=='rename')) {
     $EnablePostAuthorRequired = 0;

This is instead of the installation code documented at MovePage, and after the $EnablePostAuthorRequired = 1; line. This will allow you to move pages without typing your name. Until I find some time to review this. --Petko November 09, 2018, at 01:54 PM

I'd very much like to see this enhancement added, or even a simple configuration change that forces the author field to be shown. My users are challenged with this, and I don't wish to disable the author required requirement. thanks

simon December 06, 2020, at 12:02 AM

Petko, uploading / posting this here as I see you have noted you are maintaining this recipe and so want to make sure you approve of these changes before replacing the official version: movepage_20171206.phpΔ

This version adds the following enhancements:

  1. A default_action class is added to that button which corresponds to the default action (i.e. the action which will happen if the user hits Enter in the text field), for distinctive styling with CSS if desired (see e.g. screenshot — this is analogous to similar UX features in many desktop apps…).
  2. The $MovePageDefaultAction variable (actually added in an earlier version but was not documented before), which sets what actually is the default (caused by hitting Enter) action
  3. The $MovePageSetDefaultActionFromPageAction variable (default to false, i.e. old behavior)—if set to true, will cause $MovePageDefaultAction to be ignored, and instead set the default action from the pageaction used to trigger the MovePage form (in this way one can determine what is the default action, by altering the link used to go to the form, e.g. by editing Site/PageActions, etc.)

(Motivation for all of this is to minimize mouse clicks required to use this functionality, and make the MovePage form more amenable to keyboard-only use, which some users prefer; this is especially useful if one uses the MovePage feature a lot. Note that the default behavior remains the same as ever, i.e. if a user gets this new version and doesn't change any defaults, it behaves exactly as it always has.)

Said Achmiz December 06, 2017, at 11:30 AM

Looks good, added, thanks! --Petko December 06, 2017, at 10:12 PM

A small enhancement request, a tick box to disable/enable the retention of the original page with the redirect. simon November 23, 2010, at 11:30 PM

This feature is now added in the form of the 'rename' action (and button). —Said Achmiz November 20, 2017, at 12:33 AM

Its very good to see this alternative, I have tried this out and its excellent.

One thing I have recently noticed that I have needed, due to making rename a page an available function on the PmWikis I support, is that the move or copy also needs to move or copy the uploaded (attached) files, otherwise naive users wonder where their attachments have gone and have no means (other than reuploading them) to restoring them (to fix this takes some sort of ftp access).

Now there are three use cases here, assuming the PmWiki is using the standard flat file storage, these are set using the Upload directory configuration ($UploadPrefixFmt)

  • the PmWiki uses an entirely flat, site wide, file store, in which case attachments do not need to be moved
  • the PmWiki uses (the misnamed) Per Group Sub Directories to store attachments by page, in which case the directory for that page needs to be copied, renamed, or moved (this is the configuration of my PmWikis)
  • the PmWiki uses the standard (default) by group page storage, in which case if the page stays in the group no change is required, but if the page changes groups the files attached to the page have to be moved

Note that I would not expect the recipe to fix other pages that reference files on a moved page, this can be done manually. Simply ensuring the attached files "follow" the page would be a fantastic "wiki-ish" enhancement

good work, Simon August 17, 2009, at 03:38 PM
I agree, moving files along with pages would be a good idea. I've left it out for now to keep the recipe as simple as possible, but eventually I'll get this included. I tend to use the default per-group directories for attachments, which are the trickiest case to handle.
The really tricky part in this is finding all the references to attachments to figure out whether an attached file is only referred to on the page being moved, or, say, other pages in the group as well. I do something like this for the Attachtable reference count, so a working hack shouldn't be too difficult to put together. However, I've also got half an idea for a complete rework of the Attachtable/Fileinfo mess where I make attached files a kind of PageStore accessible via page lists and page variables somewhat like Sisterly does for multiple wikis on the same server, and said idea would give a completely different implementation for MovePage's attachment tracking. So handling attachments in MovePage may wait until I get that done, unless you feel like putting together a fix for this. :) —Eemeli Aro August 24, 2009, at 06:52 AM

I can be patient :-). I'm not sure my knowledge and skills are up to yours when it comes to fixing this. I very much like the idea of treating attachments as a page store and being amenable to pagelist processing.

As a first step moving the files, even if it breaks links, would be an improvement over the current situation where files can get left behind.

How can I get this recipe to work for action=rename

thanks simon August 22, 2009, at 04:19 AM
Adding this to your config file should work: —Eemeli Aro August 24, 2009, at 06:52 AM
$HandleActions['rename'] = 'HandleMovePage';
$HandleAuth['rename'] = 'edit';

I suggest that the default length of the input text field is increased.

thanks simon August 23, 2009, at 05:16 PM
The input field doesn't have any default length set. To customize the form, you could look into using a custom form. Or for a quick fix, try adding something like this to your config file: —Eemeli Aro August 24, 2009, at 06:52 AM
$HTMLStylesFmt['movepage'] = ' #wikimove input[type="text"] { width: 30em; } ';

I tried moving a page for the first time. I got the error MovePage: error writing page (NZSSAGM.2009PhotographicCompetition). I checked the permissions (all 777), and the target did not exist. I was able to create the page normally, any siggestions for what I should look out for (need to find a test case on a website that is accessible) simon October 01, 2009, at 02:58 AM

If you are using the page creation time then you may notice that copied pages retain the original page's creation time. To make it act as if it was just created, add

if ($mp_action=='copy') $new['ctime'] = $Now;

just before the first call to UpdatePage. It is a little weird, as the new page now has a changelog that predates its creation time, but if you're using copying as a way to template new pages then it may be useful.

I get the error message
[Dead remote image link] Two suggestions:

  1. add author field to form
  2. generate summary for source page, eg (:Summary Redirects to NewGroup.NewPage:)

simon March 05, 2011, at 10:56 PM

Suggestion: Make both author field and a manually entered change summary configurable options for the form (so those who don't want additional fields aren't burdened with them.) RandyB March 06, 2011, at 03:03 PM

Is there a simple way to have this not check if a page exists? It's problematic when a user attempts to move a page back to the original location. Nemo? February 01, 2013, at 05:52 AM

Talk page for the MovePage recipe (users).