Opened 18 years ago
Closed 12 years ago
#457 closed enhancement (wontfix)
[patch] WikiRenamePlugin doesn't update Tags etc., missing extension point for other plugins
Reported by: | Björn Swift | Owned by: | Noah Kantrowitz |
---|---|---|---|
Priority: | high | Component: | WikiRenamePlugin |
Severity: | normal | Keywords: | Tags FlexibleWiki extension |
Cc: | Adrian Fritz | Trac Release: | 0.10 |
Description
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.
Attachments (0)
Change History (14)
comment:1 Changed 18 years ago by
comment:2 Changed 18 years ago by
I'm not sure I realize the relation between this modification and the lack of extras support in the trunk. Could you elaborate?
comment:3 Changed 18 years ago by
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).
comment:4 Changed 16 years ago by
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.
comment:6 Changed 15 years ago by
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.
comment:7 Changed 15 years ago by
Keywords: | Tags FlexibleWiki extension added |
---|---|
Priority: | normal → high |
Replying to anonymous (that was me):
And another time, but #5252 at least with a hint about how the solution could look like:
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.
comment:8 Changed 15 years ago by
Summary: | WikiRenamePlugin doesn't update Tags → [patch] WikiRenamePlugin doesn't update Tags etc., missing extension point for other plugins |
---|
forgot to make enhancement to the summary before
comment:9 Changed 15 years ago by
Cc: | Adrian Fritz added; anonymous removed |
---|
comment:10 Changed 15 years ago by
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.
comment:11 Changed 15 years ago by
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.
comment:12 Changed 15 years ago by
a typo above: should have written new debug syntax as debug("msg")
of corse
comment:13 Changed 15 years ago by
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
comment:14 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
0.10 version of the plugin is deprecated.
The biggest problem with this is the lack of extras support in the current trunk.