[patch] WikiRenamePlugin doesn't update Tags etc., missing extension point for other plugins

[Björn Swift]

If the TagsPlugin is installed, renaming pages can have some tedious side effects. Since the tags table isn't updated, TagsPlugin will be pointing to nonexistent pages.

TagsPlugin is a widely spread plugin (used by trac-hacs, for instance) and by many considered to be a necessary addition to Trac. It's therefor my opinion that WikiRenamePlugin should support renaming tag pointers.

I added the following code to util.py. A simple check is included to make sure that users not using the TagsPlugin won't be effected.

49,53d49
<     # Check to see if TracTags are installed and if so, update the tags table
<     if 'tractags.*' in env.config['components']:
<         if debug: print "Updating tags"
<         cursor.execute('UPDATE tags SET name =%s WHERE name = %s', (newname,oldname))
< 

Hope this get submitted.

[Noah Kantrowitz]

The biggest problem with this is the lack of extras support in the current trunk.

[Björn Swift]

I'm not sure I realize the relation between this modification and the lack of extras support in the trunk. Could you elaborate?

[Noah Kantrowitz]

To implement this correctly, support would have to be added in the Tags plugin for moving tags (as altering someone else's database is a bad idea). This means that functions will need to be called in the Tags modules, which means that the Tags egg must be loaded before WikiRename. The only way to do this in the current trunk is to add it as a dependency, but then it becomes hard to work with as it should really be an extra (optional dependency).

[garyo]

coderanger: you're saying that although the patch above will work, functionally, with current TagsPlugin, it violates its encapsulation, right? I only wonder since the page rename issue is so significant, and everyone is using TagsPlugin; if this is the one thing standing in the way of using WikiRenamePlugin it seems like a compromise could be struck.

[anonymous]

TracTags handling was requestet with #2813 too.

[anonymous]

This issue is bugging people for 4 years! If this is so difficult to fix, then just include the tags in the default trac-functionality and make it WORK.

I've seen people dumping Trac over this issue.

[Steffen Hoffmann]

Replying to anonymous (that was me):

TracTags handling was requestet with #2813 too.

And another time, but #5252 at least with a hint about how the solution could look like:

athomas:

The only way this could be fixed is by WikiRenamePlugin implementing an extension point for renames, that the TagsPlugin could optionally hook into. Reassigning.

(#5252 was originally assigned to TagsPlugin.)

Uups, someone was quicker than me. 100 % agree with the above, pressing a little moreon the subject:

What now? The dirty OPs (bjornswift) fix just works(TM), while any cleaner solution is not in sight. I've looked into the code but not knowing Python and the Trac extension point functionality in detail I'm feeling not up to take the challenge. I could merely try to copy and modify similar looking/working code from another plugin with try-n-error. I agree with garyo that widespread use of TracTags should make this issue urgent enough to fix for someone who is capable of doing so (in a split of the time I'd need for this).

BTW, FlexibleWikiPlugin is another case, where data needs to be corrected on wiki page renaming.

[Steffen Hoffmann]

forgot to make enhancement to the summary before

[Steffen Hoffmann]

Got fed up with this. (If you can think it, you can do it anyway.)
Trying hard to provide an initial implementation of IWikiRenameHandler within the next few days ...

BTW, as stated in ​http://trac.edgewall.org/wiki/TracPluggableModules the Trac Component Architecture with ExtensionPoints was implemented for trac-0.9, so this should in theory be backward-compatible. However development focuses on trac-0.12dev. So I won't have resources to test and fix bugs for current/older versions.

[Steffen Hoffmann]

meanwhile another dirty fix for updating page and parent page names in db tables of FlexibleWikiPlugin

@@ -85,6 +85,16 @@
         newtext = re.sub('\[wiki:%s'%oldname,'[wiki:%s'%newname,row[2])
         cursor.execute('UPDATE wiki SET text=%s WHERE name=%s AND version=%s', (newtext,row[1],row[0]))
 
+    # Check to see if FlexWiki is installed and if so, update that table too
+    if 'tracflexwiki.*' in env.config['components']:
+        debug("Updating wiki page names for FlexWiki")
+        # page references
+        cursor.execute('UPDATE flex SET name =%s WHERE name = %s', (newname,oldname))
+        debug("Found %s page name reference(s) for that page", cursor.rowcount)
+        # parent page references
+        cursor.execute('UPDATE flex SET parent =%s WHERE parent = %s', (newname,oldname))
+        debug("Found %s reference(s) for that page as parent page", cursor.rowcount)
+
     if handle_commit:
         db.commit()

The initially proposed patch still contains a no longer valid call for debug printing. The old syntax if debug: print "msg" needs to be updated to debug("msg)" to actually print anything even in DEBUG logging mode.

[Steffen Hoffmann]

a typo above: should have written new debug syntax as debug("msg") of corse

[Steffen Hoffmann]

as I didn's saw this before: ​t:ticket:1106 is trying to provide WikiRenamePlugin function in Trac natively, had a talk at #trac at freenode.net, looks like more people will join now to help fix this issue

[Ryan J Ollos]

0.10 version of the plugin is deprecated.