[PATCH] TagsPlugin should implement wiki_page_renamed method of IWikiChangeListener interface

[Itamar Ostricher]

Starting Trac 0.12 the WikiRename functionality is available in core, and notifies plugins about page renaming via the wiki_page_renamed() method of the IWikiChangeListener interface.

TagsPlugin should implement this API in order to move tags from old_page to page when a rename is performed.

[anonymous]

Patch again 0.6 tag to make wiki_page_renamed work.

[anonymous]

Patch against trunk to make wiki_page_renamed work.

[sika]

Included patches against 0.6 tag and trunk to make tags update accordingly after wiki page rename.

To patch your tagsplugin first apply the patch from comment 5 of ticket 5345 or you will get an error trying to upgrade your existing installation. Then apply the patch normally, e.g.

$ svn co http://trac-hacks.org/svn/tagsplugin/tags/0.6 tagsplugin-0.6
$ cd tagsplugin-0.6
$ patch -p0 < ../wiki_rename-0.6.patch
$ python setup.py bdist_egg
$ cp dist/*.egg /path/to/projenv/plugins

[Steffen Hoffmann]

#8670 has been closed as a duplicate of this ticket.

BTW, why should a missing new functionality for a 0.11 plugin with "works with 0.12 too" be considered as a bug? If it was explicitly designed for Trac 0.12, in fact it isn't, so please be reasonable.

Nevertheless the hint and patches are highly appreciated and should go into the repo soon. Thank you for your the effort put into this.

[Steffen Hoffmann]

(In [10632]) TagsPlugin: Implement IWikiChangeListener interface for Trac 0.12, refs #8638 and #9059.

This work is based on code contributed/tested by Itamar Ostricher and sika.

Had a hard time myself to understand the consequences of wiki rename in Trac 0.12 i.e. for attachments, but now I favor this approach, even regarding naming conventions.

So I preferred reparent_resource_tags over rename_resource because the former is what we actually do while the latter has already been done, when IWikiChangeListener method wiki_page_renamed is triggered. Other details regarding the latest patch by Itamar have been discussed in #9059 before.

[Steffen Hoffmann]

No more removing and re-adding tags to wiki pages before/after move. Enjoy, and tell me, how it goes for you.

[Steffen Hoffmann]

(In [10636]) TagsPlugin: A spurious self argument slipped in into changeset [10632], refs #8638 and #9059.

As outlined by Odd (osimons) in comment 4 of #9059 the usual first argument self is omitted from Interface definitions intentionally; cite:

Interface class declarations in Trac (and plugins) are always defined without adding self to the template methods. It has no real functional meaning, other than established practice to specify the essence of the API without implementation details + prevent that someone by accident makes an instance of the Interface class and tries to call it (if so it should fail).

[anonymous]

Not sure if this is connected, but I get a

Oops… Trac detected an internal error: AttributeError: 'TagSystem' object has no attribute 'reparent_resource_tags'

when trying to rename a wiki page

Trac 0.12.2 TracTags 0.7dev-r10639

[anonymous]

ok, current r11061 seems to work. Thanks for the work guys.

[Steffen Hoffmann]

Replying to anonymous:

ok, current r11061 seems to work. Thanks for the work guys.

Thanks, your issue was related indeed. And thank you too for the ok-report afterwards, especially, because anonymous have a tendency to only report bugs, and often they never come back again to respond/report on progress.

[Daniel Kahn Gillmor]

We ​just ran into this problem with an older version of trac-tags, and i can confirm that updating to the current svn resolved the problem for us.

Thanks for this work. I've submitted a new SVN snapshot to debian's unstable as well, fwiw.

[Steffen Hoffmann]

Great new for a long-time Debian fellow. :-)

[Steffen Hoffmann]

In 13815:

TagsPlugin: Completing preparation for v0.7 release.

Availability of that code as stable, tagged release
closes #2429, #3359, #3610, #3624, #3677, #3754, #3864, #3947, #3983, #4078, #4277, #4503, #4799, #5523, #7787, #7857, #8638, #9057, #9058, #9059, #9060, #9061, #9062, #9063, #9149, #9210, #9521, #9630, #9636, #10032, #10416, #10636, #11096, #11147, #11152, #11274, #11302, #11658 and #11659.

Additionally there are some issues and enhancement requests showing progress,
but known to require more work to resolve them satisfactorily, specifically
refs #2804, #4200, #8747 and #9064.

Thanks to all contributors and followers, that enabled and encouraged a good
portion of this development work.