MovePage-Talk

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

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

.

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