The rename page feature is included JSPWiki 2.3 and newer. It is accessible via the Page Info link if you have proper permissions.

This is a patch that adds simple page renaming to JSPWiki. We use JSPWiki primarily as an Intranet collaboration tool, so we can trust people to use it fairly sensibly, but it's certainly been useful maintaining our Wiki.

Featurewise, it can automatically update referring links to point to the new page, as well as having optional page overwriting. It can also be used as a rudimentary page deletion feature. For example, when you want to delete a page you just rename it to Trash (or something like that), overwriting any previous Trash page.

Renames aren't themselves versioned, but version history is retained over a rename on providers that support it.

Current patches are [rename.2_0_39.patch] and [rename.2_0_39srczip.patch] for the CVS tree and Source Zip respectively.

I haven't generated the latest patch against the 2.1 tree yet, so stick with these two.



''1st May 2003'': I've made some fairly major modifications to the patch based on John's suggestions below, and also on his attempt at modularising my terrible monolithic rename method.
* CamelCase referrer links are now altered correctly (and ~ escaped ones aren't)
* Plural referrer links are now altered correctly (although there may possibly be some boundary conditions where it doesn't work)
* The referrer link renaming scheme now follows the pattern set out in 1-5 in John's note.
* Code has now been refactored, and most of the renaming now takes place in a PageRenamer class.


__NOTE:__ Chris, we've been using this patch just a little bit on one of our internal wiki's and to be honest I did not even look at the code for the patch until just recently.  There are two minor issues that I figured needed pointed out here before anyone else uses this.
# If you use match english plurals, be warned that renames will be incomplete, check for unreferenced pages after a spate of renames to manually fix them up.  Not much that can be done about this, I'm thinking that the match plurals feature is really a ''mis-''feature and I'm going to turn it off.
# Bewarned if you use camel case links:  if you ~RenameMe to ~NewlyRenamed, but had a page named ~DontRenameMe you will get ~DontNewlyRenamed.  This can be fixed but will take some thought.

I wrote this as I was thinking, ideas? thoughts?
     * Change the text of each referer to reflect the renamed page.  There are seven starting cases 
     * and two differenting ending scenarios depending on if the new name is clean(camel) or long.
     * <pre>
     * "Start"                               "A"                                "B"
     * 1) OldCleanLink                   --> NewCleanLink                   --> [New Long Link]
     * 2) [OldCleanLink]                 --> NewCleanLink                   --> [New Long Link]
     * 3) [old long text|OldCleanLink]   --> [old long text|NewCleanLink]   --> [old long text|New Long Link]
     * 4) [Old Long Link]                --> NewCleanLink                   --> [New Long Link]
     * 5) [old long text|Old Long Link]  --> [old long text|NewCleanLink]   --> [old long text|New Long Link]
     * 6) OldLongLink                    --> NewCleanLink                   --> NewLongLink
     * 7) [OldLongLink]                  --> NewCleanLink                   --> [NewLongLink]
     * </pre>
     * It's important to note that case 6 and 7 can exist, but are not expected since they are 
     * counter intuitive.
     * <br/>
     * When doing any of the above renames these should not get touched...
     * A) OtherOldCleanLink
     * B) ~OldCleanLink     <-Um maybe we _should_ rename this one?
     * C) [[OldCleanLink]   <-Maybe rename this too?
     * D) 

--JohnVolkar Apr-29-2003

''Thanks for the suggestions, I haven't had time to think about things like this in a lot of detail, as I'm a bit bogged down thinking in detail about other things! However, you've certainly cleared things up a lot for me. 

The CamelCase link problem in the last update is a bit dumb, and I can see that in retrospect, so I can only apologise for that. I'll take a look at implementing a refined link replacer very soon.'' -- ChrisLisle (29th April 2003)

''Just for the record, TranslatorReader doesn't translate B) or C), so I'll try and make the replacer work in the same way. I'll see if I can think of a simple way of not replacing text inside "code" blocks as well.'' -- ChrisLisle (30th April 2003)


__Update:__ After a few suggestions from JohnVolkar I've updated the patch with a couple of bits and pieces.

Firstly I've created two separate patches: one for the stable version 2.0.39, and one for the CVS HEAD, which is currently version 2.1.11.

Secondly, renaming now supports the updating of CamelCase referring links, which was something I missed in the original version.

Thirdly, I altered the code to use ORO like the rest of JSPWiki. This (hopefully) removes the dependence on JDK 1.4 and lessens the mixing of APIs.

--[Chris Lisle] (16/4/2003)

__Update:__ Apparently the CVS revision 2.0.39 is different to the 2.0.39 source zip (unless I've made a stupid mistake). I've added another patch to account for this.

--[Chris Lisle] (24/4/2003)


The patch should be fairly simple to understand. As a brief overview: it adds a movePage method to the PageProvider hierarchy, a moveAttachmentsByPage method to the AttachmentProvider, the WikiEngine class has a rename method added, which does the work, and a new JSP page Rename.jsp adds the interface to this.

The actual rename form is on the Info page at the bottom (it seemed the logical place at the time). The actual code for this is only included in the default template InfoContent.jsp file, so if you're using a different template you'll have to copy it over.

The patch was generated against the CVS tree as of 20/03/2003.

[Chris Lisle] (21/03/2003)

Is there any publicly reachable site that has this patch applied?  Janne, if this works as nicely as it sounds it might, and the implementation is clean any possibility of this making it into the CVS head?  --JohnVolkar.  

Alas no, there isn't a publicly available site. We have a JSPWiki that we use internally for an Intranet collaboration tool, and that's all we've used this patch in.  -- ChrisLisle

I'll certainly take a look at it - it is one of the most requested features.  Won't make it to the CVS head until I manage to release the %"#&%!"/# 2.0 stable :-) -- JanneJalkanen

Okay with 2.1.1 work going on in CVS, is this patch going to be considered?  If it's not being considered due to lack of bandwidth or a volunteer I hereby volunteer to work this thru to completion as I __need__ this patch on my 2.0.36 version.  Janne?  How do you want this handled?  I can regenerate this patch against the 2.0.36 release (Chris?  Do you have it already?) and post it, or I can take steps to help moving it into the "current" CVS head., let me know.


For the CVS head I'll integrate mostly the JSPWikiAuthentication and JSPWikiAuthorization stuff.  This causes the head to live and bounce very wildly for the next few weeks, so I would recommend against keeping any code current against that.

It might be a good idea to keep it live against 2.0.36, as there is going to be at least one bug-fix release for 2.0 (I believe the CVS branch is at 2.0.37 at the moment :-).

After the head stabilizes, which is roughly at the same time as 2.0.x branch is finally frozen, I would recommend looking at the 2.1.x branch.

This patch is on in top #5, unless I can find something seriously wrong with it...  Much like with [PreviewPageSaveButton], which does have a fatal data-loss bug in its current incarnation.

-- JanneJalkanen, 01-Apr-2004.


This is definitely useful in doc-app and intranet use, but unless there's a good history facility, it could make fixing vandalism cumbersome on public wikis. Is there an option to disable or undo page moving? --[ebu]

''Not as written, although I can definately see it being useful. I'd imagine you could disable it by not including the Rename part of the InfoContent.jsp template, and completely removing the Rename.jsp file. Hence no interface to it. Not elegant I know, but just a thought.'' -- [ChrisLisle] (2nd April 2003)

* I'm also nervous about the delete part of rename (for public wikis especially).  How about if renaming a page just made a copy with the new name, while leaving a version of the old page behind with a pointer to the new page and a deleteme link so an admin can delete it? That would also provide an audit trail. --[Daggerbox] 2003-11-20

* How about requiring login by use of Tomcat authentication?  Then you can create a wikiadmin group and put everyone that is supposed to be able to rename pages in this group (which would also require they have a login and password.  Pretty much like the Delete is handled today.) / [ErikAlm] 2005-07-22


I am interested in trying this patch. Can you tell me what format is the patch file, and what do I do with it? I am running v. 2.1.86 on Windows. Thanks.

''This is a Unix (or Cygwin) ''patch'' input file; ''patch'' is an application that can read output from ''diff'' and apply it to input files.  They're text files; you should be able to figure out what they're doing by reading them and apply the patch manually, if someone hasn't generated a patch for your specific version of the software.'' -- JerryAndrews


Would someone like to update this for the current CVS?

-- JanneJalkanen

Have updatet that patch to current 2.2.16 beta. Unfortunately I haven't had to much time to do necessary testing (volunteers ?). I'm using it with the RCSFileProvider and and BasicAttachmentProvider.\\
In addition I've removed the delete feature, since that one gave me some trouble related to caching and 2.2.16 provides the delete functionality by itself. When there is an existing document, where the old one is supposed to be renamed to, the patch doesn't do anything beside an info log entry.

-- Joerg Luedeker 2005-06-01
Fixed an issue where page rename failed due to a special char like a german Umlaut within the new page name. (Tested with UTF-8 and ISO-8859-1).

-- Joerg Luedeker 2005-06-13
Fixed some minor things and verified the fix against 2.2.20. [rename-2.2.20.patch]

--Joerg Luedeker 2005-06-17
I would feel the real problem is that the title and name(ID) of a page are too tightly coupled. If you can set the title of a page, there would be much less need to rename a page.
It would be beter if the name/id of the page is hidden from the user, and the title of a page can be set by the user (title attribute?).
This could also replace/update the camelcase/beautify feature.\\
So I would propose:
* Page name (ID) is internal. It can be generated by JSPWiki as it currently is derived from the page name (title)
* Page name (title) is exposed. It can be stored in the page as an attribute. It can be changed by the editor. If no title is set the default is used as it currently is..
* renames of pages (physical) should not be needed as the pagename is internal.
* Renames (of titles) is tracked in the history
* More flexibility in the title of the page regarding spaces etc, characters.
-- Arent-Jan 2005-06-16

One of the key functionalities of wikis is that you can create links easily by linking to the title of the page - and that the title and the name of the page are one and the same.  If they're different, you'll get into interesting problems...  At its worst, this would result in having LotusNotes-like URLs.  I think strong coupling of URLs and page titles is mostly a good thing, and should not be broken lightly.  I don't think page renaming is very frequent anyway.

In fact, I'm considering relaxing the naming of pages (by allowing spaces and making the comparison case-independent) to support natural languages better.  This will make renaming of pages less frequent, but it will increase the complexity of renaming.

-- JanneJalkanen

Problem is that the file-based providers use the page name as the filename. This poses the limition of the filesystem wiki is deployed on the page names. For example on Unix (case sensitive) SecondPage is different then Secondpage, while on Windows (case insensitive) both are the same page.

-- Arent-Jan

Yup.  One of the reasons why page name comparisons should also be case insensitive...

-- JanneJalkanen


This patch is now included in CVS 2.3.0.

For those who don't want to shift to the 2.3 stream (that includes myself) I've adapted the patch to 2.2.28

-- Joerg Luedeker 2005-07-24

Updated the patch slightly because there is a issue (will open a bugreport soon) related to the referring pages plugin when deleting a page or renaming a page with this patch. In certain circumstances the old name of the deleted/renamed page still shows up in list of referrenced pages though it has been deleted/renamed.
The fix for this requires the rename patch to be changed slightly in renamePage(..) (See [BugReferenceToDeletedPageNotCleared])

-- Joerg Luedeker 2005-08-09
Would this patch work with the latest release of the 2.2 branch ? (2.2.33)

-- David Stringer 2005-09-09

I've applied the 2.2.28 patch to 2.2.33 code with only a slight hitch:
For the patch of /src/com/ecyrd/jspwiki/providers/CachingAttachmentProvider.java,
the insertion of import statements doesn't work because the import list has changed. I pasted in the proper import statements by hand. I've recompiled and everything seems to be working OK.

-- Ihor Slabkyy 2008-03-19

And what about patch for v2.6.1? The folders are different and some files do not exist.

Back to [Category Patches]