create new tag
, view all tags

CompareRevisionsAddOnDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on CompareRevisionsAddOn contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Feedback on CompareRevisionsAddOn

-- JChristophFuchs - 20 Jan 2005

Thanks Christoph for sharing this add-on. Very intuitive output!

-- PeterThoeny - 21 Jan 2005

Hi Christoph, cool add-on!

Unfortunately the algorithm is very sensitive when it comes to the ugly <p />-tags, spreaded all over twikis HTML rendering frown For example, when you have a headline followed by a bullet list, and then you insert a blank line between them, compare will replace the whole list. Do you see a work around for this, or is it time to get rid of the <p />-tags altogether?

-- AndreUlrich - 01 Feb 2005

Yes, I also noticed this. I just uploaded version 1.1, which removes the blank paragraphs before comparing the revisions.

-- JChristophFuchs - 03 Feb 2005

Hi Christoph, your add-on is very helpful in understanding more complex changes!

I have just installed it in our TWiki instance. However, our apache server complains constantly about uninitialized variables, which are all located in the subroutine _compareText:

[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in string ne at ../lib/TWiki/UI/Compare.pm line 397.
[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in string eq at ../lib/TWiki/UI/Compare.pm line 416.
[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in string eq at ../lib/TWiki/UI/Compare.pm line 416.
[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in string eq at ../lib/TWiki/UI/Compare.pm line 416.
[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in concatenation (.) or string at ../lib/TWiki/UI/Compare.pm line 434.
[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in concatenation (.) or string at ../lib/TWiki/UI/Compare.pm line 435.
To me it seems to be a boundary problem with some index?

-- MichaelSchmidt - 28 Feb 2005

Hi Michael, thanks for your help.

The bug has been corrected, I have uploaded a new version of the addon.

-- JChristophFuchs - 02 Mar 2005

Has anyone managed to get CompareRevisionsAddOn to work with TWikiRelease01Feb2003?

I've done the following:

  • updated Algorithm::Diff to the version (1.13) that includes sdiff
  • replaced all references to formatTime (not supported in Beijing?) with formatGmTime
  • replaced all references to TWiki::Render::getRenderedVersion (undocumented function?) with TWiki::Func::renderText
The compare script now runs, but I get only partially rendered pages back and the somewhat cryptic grep: *.txt: No such file or directory (twice) in the http error log. I kind of feel bad about posting this without debugging it properly, but just wondered if anyone had any ideas about what might be going wrong.


-- MartinRothbaum - 21 Mar 2005

Hi Martin,

Sorry, I do not have any old TWiki version installed, so I cannot debug CompareRevisionsAddOn on TWikiRelease01Feb2003. However, the following points might help to fix the problem:

When I started to write the addon, I tried to use only documented routines from the Func module. However, I did not succeed in getting a fully html rendered topic including the meta data. So I decided to use other routines from TWiki (the only documented routine from the Func module which deals with meta data seems to be the deprecated readTopic).

The rendering text -> html is done in subroutine _getTree with the call to TWiki::handleMetaTags, which internally in TWikiRelease01Sep2004 calls Twiki::Render::getRenderedVersion. It is very likely that this has changed since older versions.

You could try to replace the section labeled '# Process Meta data' in Compare.pm (lines 258-267) by

$text = TWiki::Func::expandCommonVariables($text, $topic, $webName);
$text = TWiki::Func::renderText($text, $webName);
but this will print meta data in their internal form '%Meta...', which is not very user friendly.

The call to TWiki::Render::getRenderedVersion in Compare.pm is only in the routine getRevInfo, which was copied from TWiki::UI::RDiff. The addon should work even without this subroutine.

There are no calls to grep in the addon, so the error message in the log file must be from some TWiki core module ?

-- JChristophFuchs - 24 Mar 2005

I'm trying to make a "WikiPedia killer" TWiki system with this plugin along with HistoryPlugin. Can interested parties please see more details at MediaWikiHistoryAndComparisonInTWiki and comment there?

-- MattEngland - 09 Apr 2005

I think, there is a bug in handling html-comments. On my system, users sometimes use html-comment-tags to hide unfinished or noisy parts of a topic. Viewing the topic with the CompareRevisionsAddOn the content of the html-comment comes to surface.

-- OliverKrueger - 05 May 2005

Hi Oliver, I was not able to reproduce this bug. Could you please send me a test case (topic text and rcs repository) for debugging ?

-- JChristophFuchs - 09 May 2005

Christoph tracked down this problem to a nested html-comment, which is not allowed by definition (W3C). -- Thanks. smile

-- OliverKrueger - 09 May 2005

(Nested html comments are rendered differently by different browsers: Mozilla, Firefox etc do not show netsed comments, which is not correct, but in most cases intended by the author. Internet Explorer, Opera and Lynx render them correctly: they show the second part of the outer comment. CompareRevisionsAddOn also handles nested comments in the correct way (with the help of perl modules from HTML::TreeBuilder), even if this surprises the author.)

-- JChristophFuchs - 10 May 2005

Has anyone managed to get this to work with DragonSkin? Any help would be appreciated.

-- PankajPant - 09 May 2005

I have attached templates compare.dragon.tmpl and interweave.dragon.tmpl in dragonskin.zip

-- JChristophFuchs - 10 May 2005

Thanks. I'll check it out.

-- PankajPant - 10 May 2005

Hi, does anyone have an idea what could go wrong when, after installing this Add-On, I get:

Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request.

Please comment in CompareRevisionsAddOnGivesInternalServerErrorFivehundred if you have an idea. Thanks!

-- JosMaccabiani - 10 Jun 2005

Due to a wierd problem with dates on TWiki.org I can't edit the abovementioned topic, but I wanted to state that JChristophFuchs solved my problem. Thanks!

-- JosMaccabiani - 10 Jun 2005

By the way, consider mentioning the possible combination of HistoryPlugin, CompareRevisionsAddOn and RevCommentPlugin. They work together really nicely and the last one even provides the oopshistory.tmpl to integrate the three plugins, making the whole thing rather painless.

-- JosMaccabiani - 10 Jun 2005

added .zip to CVS

-- WillNorris - 27 Jun 2005

Dont see the point of having strike-out AND red background - the latter should be sufficient and the strike-out just makes things harder to read.

-- JackGlendeni - 09 Nov 2005

This is not hard-coded: Just change the default styles in the supplied template files to your needs

-- JChristophFuchs - 11 Nov 2005

I installed the CompareRevisionsAddOn. I am able to make it work but was expecting that it would seamlessly replace the existing rdiff. Is there a simple (considering my lack of knowledge of perl etc) way to make it replace rdiff ? My wish is that when I click on the '>' sign displayed at the bottom between the revisions, I should get the output from this add-on, with sidebyside rendition and pattern skin (though I am using dragon skin for the pages)

-- ChengappaCB - 24 Nov 2005

Please see my answer in CompareRevisionsAddOn

-- JChristophFuchs - 24 Nov 2005

When I use the add-on in the way described in CombineHistoryPluginWithCompareRevisionsAddOn, I observe that the compare function only works for webs that are not protected by access control like ALLOWWEBVIEW. For any topic of a protected web I get the error message "View Access Denied". I am eager to know, what has to be changed in order to being able to compare revisions in protected webs too.

-- MichaelSchmidt - 14 Dec 2005

I am not familiar with this add-on. It looks like bin/compare needs to be authenticated (which requires users to login to see the diffs). Alternatively, bin/compare could be enhanced to redirect to an authenticated bin/compareauth if needed (in the same way the bin/view script works.)

-- PeterThoeny - 15 Dec 2005

Thanks for the hint. The problem arose after setting the configuration variable $doRememberRemoteUser to 0 which was necessary due to the fact that some users are accessing twiki with the IP address of some proxy. BTW rdiff caused the same error.
Meanwhile I found, that the problem is resolved by choosing the option to force authentication for all files in the .htaccess file of the \bin directory.

-- MichaelSchmidt - 16 Dec 2005

This is an add-on I would really like to see available for Dakar.

The way it shows changes in large documents with a lot of text is far superior to the normal rdiff in TWiki. For seeing changes of TWiki valiable and other hidden stuff the rdiff is better so we use both at the moment.

I just tried to install it in Dakar and it seems the structure in the core code has changed quite a bit so this add-on is no longer compatible at all.

I get this error when I install and run it (and have updated the shebang line of bin/compare).

Can't locate object method "read" via package "TWiki::Meta" at /usr/local/apache2/dakar/lib/TWiki/UI/Compare.pm line 259.

I tried to see if it was something simple but the different in the TWiki::Meta is beyond my rudimentary Perl skills.

-- KennethLavrsen - 20 Dec 2005

Can someone help me with some hint of how to make this add-on work?

And for those that do not know it - it is fantastic - when it works.

-- KennethLavrsen - 05 Feb 2006

Many thanks for updating the addon for Dakar! My initial tests were successful.

-- ScottHoge - 27 Feb 2006

Tests also very successful here. My users are very happy to have the this wonderful feature back.

Note that you may need to make tamplate updates when 4.0.2 is out since the pattern skin is about to change back to a pure DIV defined skin (no tables). It should however - from what I have seen - also be much simpler to taylor.

But great work. And to those that only live with rdiff. You should really consider this plugin. Highly recommended.

-- KennethLavrsen - 27 Feb 2006

Christoph, thanks for updating the add-on. Please consider upgrading this add-on so that it runs on Cairo and Dakar codebase. HandlingCairoDakarPluginDifferences has more.

If you prefer to maintain just the Dakar version, please remove the CompareRevisionsAddOn.Dakar.zip file and overwrite CompareRevisionsAddOn.zip with the Dakar version. In the add-on doc you can point to a previously attached zip version for the Cairo version.

-- PeterThoeny - 27 Feb 2006

I will maintain both the Cairo and Dakar versions, and combine the two versions eventually.

-- JChristophFuchs - 01 Mar 2006

Could someone please check this issue PrintableStoppedWorkingShowsTheSameAsNormalView which I had with CompareRevisionsAddOn. I solved my problem here PrintableStoppedWorkingShowsTheSameAsNormalView#Answer but it appears to me as a problem related to the plugin and not to my particular configuration.

-- DaliborSvoboda - 07 Mar 2006

Thanks for the hint. I indeed did not check all implications of the VIEW_TEMPLATE preference variable. I have changed the install instructions for the plugin so that you should replace the view templates by the provided templates and not use this prefernce variable.

-- JChristophFuchs - 07 Mar 2006

The pattern skin had a major update between TWiki 4.0.1 and TWiki 4.0.2. Between Cairo and TWiki 4.0.0 the Pattern Skin had been changed into a table layout. This caused serious trouble when you had graphics and verbatim text. So serious that many topics could not be viewed or printed at all. So in TWiki 4.0.2 the Pattern skin was changed back to a pure style sheet defined design and all is working fine again. Except 2-3 extensions that depend on the Pattern skin. And CompareRevisionsAddOn is one of them. Could I kindly ask you to update the templates so they work with 4.0.2 again?

My users love this extension so much but since I upgraded to 4.0.2 I just get a blank screen when using it.

-- KennethLavrsen - 08 Apr 2006

Any reason this can't get bundled with the core? Its baseline functionality wrt: other wikis.

-- MartinCleaver - 08 Apr 2006

And while we're at bundling baseline functionality in the core: please also consider HistoryPlugin and RevisionCommentAddOn for this! (e.g. turned 'off' by default)

-- JosMaccabiani - 08 Apr 2006

Martin. In my view - the way this add-on works should be a replacement for the current rdiff. It is far superior. But I have seen some small glitches in a few cases where this add-on is not perfect so it would need a little more testing.

SteffenPoulsen has made a fix for the compare.pattern.tmpl and interweave.pattern.tmpl which works fine. I will check them into SVN. There is still some work missing to get the view_cra.pattern.tmpl made.

-- KennethLavrsen - 09 Apr 2006

Hi Christoph, this is a very cool plugin! I updated this and HistoryPlugin to be 4.0.2 compatible in SVN (TWiki4 branch), feel free to use this as input for next release :-).

I did some changes:

  • Changes view changed from full view with top/left bar, to a more simple view
  • Took out view_cra.pattern.tmpl and put in viewtopicactionbuttons_cra.pattern.tmpl (thinking of it, this is not optimal for 4.0.0 and 4.0.1 ... hmmm, I guess people should consider upgrading to 4.0.2 asap anyway :-)).
  • Template support for both rdiff and compare in HistoryPlugin, dependent on context CompareRevisionsAddonPluginEnabled

Thanks again, hope this plugin will come closer to the core eventually (in spite of the additional CPAN requirements)!.

-- SteffenPoulsen - 09 Apr 2006

I was wondering, how much effort would be needed to make this excellent plugin show diffs in META as well?

-- SteffenPoulsen - 12 Apr 2006

Since the plugin compares the html-rendered output of a topic, differences in METAs are normally not shown.

However, if you can include your META data in the rendered output, differences will be shown. This is presently done for the list of attachments and for form fields, which are both stored as META data.

-- JChristophFuchs - 12 Apr 2006

Ah, I see, that's the way to go. I was thinking along the lines of "all meta", like current diff functionality that will also display arbitrary meta changes, like

> META REVCOMMENT    comment_1="New responsibilities for software maintenance" minor_1="" ncomments="1" rev_1="" t_1="0"
< META REVCOMMENT    comment_1="Updated with new server info for front setup" minor_1="" ncomments="1" rev_1="" t_1="0"

But I guess that would require some kind of way to render all meta as HTML. Or perhaps just separate the remaining bits out, along the lines of a %META{"other"}%.

Forms and attachments are the most important, need to consider the last part a bit more.

(BTW: merlin.lavrsen.dk is running an SVN install where you can see the 4.0.2 look in action).

-- SteffenPoulsen - 12 Apr 2006

I am sorry to announce that I am no longer able to do any work on this addon. For more information please read JChristophFuchsStopsWorkOnTWikiPlugins.

-- JChristophFuchs - 13 Apr 2006

Thanks for your effort, JC!

Uploaded a new version from SVN, compatible with TWikiRelease04x00x02. Users on earlier releases of TWiki should use:

Latest PatternSkin (in SVN) supports this plugin directly, but is not released yet. Until next release of PatternSkin the updated template viewtopicactionbuttons.pattern.tmpl supporting this plugin can be retrieved from this link: viewtopicactionbuttons.pattern.tmpl in SVN.

-- SteffenPoulsen - 13 Apr 2006

I added a SHORTDESCRIPTION to the "Add-On Info" section so that this add-on is represented properly in the AddOnPackage topic and query topics. Please feel free to take this into the next release.

-- PeterThoeny - 06 Oct 2006

It seems to have a problem with UTF-8 encoding. I guess it's related with HTML::Parser, but couldn't manage it to work.

-- KyungdahmYun - 29 Mar 2007

now there's an addon who's functionality should have been merged into the core years ago. I don't know why no-one's done so - but anyone that is interested, please think about doing so.

especially as when i wrote rdiff (the Cairo version was a complete re-write), i made it kind of pluggable!

-- SvenDowideit - 20 Jul 2007

-- SvenDowideit - 20 Jul 2007

I agree ... into the CORE !

-- KeithHelfrich - 20 Jul 2007

It is the very good proposal, and by the way Bugs:Item3683 can be eliminated. (This wonderful script suddenly stopped to recognize custom charset without any visible reason)

-- SergejZnamenskij - 21 Jul 2007

Does anyone know whether this Add On works with TWiki 4.1.2? I'm really keen to use it.

-- TamsinTweddell - 30 Aug 2007

Works great on 4.1.2, I'm using it on a daily basis! Thanks Steffen!

-- FranzJosefGigler - 30 Aug 2007

There is a new version ready for 4.2. Unfortunately incompatible changes in the 4.2 template system makes the new version of CompareRevisionsAddOn totally incompatible with 4.1.2 and earlier.

So once we release the 4.2.0 version - a 4.1.X user that accidentally update this extension with Configure will see themselves in a lot of trouble.

I have raised Bugs:Item5117 to address this issue. I am not sure it will be an easy one to resolve.

It is a real pity that we allowed these incompatible template changes in 4.2.0 IMHO.

The worst part is that the developers learn nothing of the past. Just see JChristophFuchsStopsWorkOnTWikiPlugins. This is exactly the same that happens again now.

-- KennethLavrsen - 12 Dec 2007

I am sorry to say, but with 4.2 we are correcting templates incompatibilties I have created earlier. So it is no longer needed to have a special pattern template for each plugin.

The reason why we changed (again) is exactly to address this issue.

But I don't find it very encouraging to find rants from one Core developer against the other on random places on twiki.org.

-- ArthurClemens - 12 Dec 2007

Template work is complicated and takes quite a lot of energy - as I guess you have recently experienced, Kenneth.

I also guess that when you revisit your comment now you will acknowledge that you are way out of line here, but I can understand the frustration - I've been there myself smile

If we look back at the roadmap agreed at our latest summit we discussed the interest in a stable template baseline, and Arthur is already doing incredible work in this direction - even though none of us voted this item as one of our top priorities. What would you vote if you had to vote right now?

Anyway, it is perfectly ok to let off steam - but remember, it is also perfectly ok to find a way to come clean again afterwards ..

-- SteffenPoulsen - 12 Dec 2007

I am not personally affected by this issue. I do not upgrade the plugin in 4.1.2. I upgrade to TWiki to 4.2.0. I am talking on behalf of the customers who will not all go and upgrade to 4.2.0 tomorrow.

I wrote the statement above - here - to warn people that may consider upgrading - and developers who may consider uploading the 4.2.0. And the rant - well - it is my hope that this time developers will learn and remember that changes to templates and plugins must consider compatibility. The roadmap suggestion was mine. I raised it after these template changes were made because I feared issues like this would be the effect.

What are we going to do about the problem with this plugin?

-- KennethLavrsen - 13 Dec 2007

As a general solution (for all plugins) we could offer a general pattern skin template update for TWiki 4.0.5 up to 4.1.2.

-- ArthurClemens - 13 Dec 2007

If that is possible then it sounds like the best possible solution.

But it sounds like a big job. But I will be happy to help testing it.

-- KennethLavrsen - 13 Dec 2007

The short description settings that has been added is lost. Please add something like this to the add-on topic:

  • Set SHORTDESCRIPTION = Compare two topic revisions and shows the differences on a word-by-word level

-- PeterThoeny - 04 Feb 2008

This plugin doesn't actually display all changes as advertised. An image on the plugin topic shows tables as a single table with changes rendered inside table cells. On our 4.2 installation, any changes in tables are rendered with the whole table removed and re-added. There are some other issues also (the default style preference doesn't work). Having scanned over the above discussion - is this plugin still being maintained/developed?

-- MarcusLeonard - 02 Apr 2008

ArthurClemens and I KennethLavrsen are trying hard to keep it up to date.

I have also noticed the table problem which partly seems to be when an old topic is edited by Wysiwyg which cleans out extra whitespace - or when you insert new rows.

Do you have some patches to the default style preference. Any improvements you have I will be glad to test, check into Subversion and upload as a new version here on Plugins web at twiki.org

-- KennethLavrsen - 02 Apr 2008

Um. My Perl sucks. I'll have a look at the preferences thing, but frown . As for the table-as-single-unit issue (which is more important to us), I've just done a quick test. I didn't use wysiwyg at all. I changed the contents of one cell and the whole table was treated as changed.

But really, this is part of a wider problem I've been chewing over. It's probably fodder for a Codev topic, but I'm not a developer so I'm not sure of the protocol here. In a very small nutshell, without any supporting arguments (which I'm happy to provide) my thoughts are...

The introduction of wysiwyg as default editor is a very important shift in the interaction metaphor away from TWikiML, and makes a strong argument for the inclusion of a more "user-friendly" "track-changes" style of version diff display, because TWiki users will now be increasingly removed from TWikiML, so diffs should be based more on "end result" information in line with what they're seeing in normal View and now in Edit. The same metaphor should operate across the system.

We're now apparently in a situation where core developers (you smile ) are maintaining abandoned plugins like this anyway because there's a demand, so there's a strong argument to either bring it into the core or update the core system to cover the basic functionality of the plugin. (A certain level of the popularity of a plugin should be a pathway to have it brought into the core.)

So the display of changes to topics should be revamped to at least include the basic functionality of this plugin. I doubt that end-users will complain and there's already some voting above. I like the new "debug" diffs, it's great for my TWiki apps, but it's in the other direction for end-users.

Not sure how much weight my argument/opinion carries 'cos I'm not going to pony-up the code. But anyway.

-- MarcusLeonard - 03 Apr 2008

After installing this Add on, I noticed that any searches that included the Sandbox web (such as Sandbox.WebHome ) were broken and displayed an error long lines of Could not perform search. Error was: /bin/grep -E -i -l -H -- %TOKEN|U% %FILES|F% Grep for '.*' returned error . After some mucking around, I finally figured the problem was that the distributed version of Sandbox/CompareRevisionsAddOnDemoTopic.txt had permission set to 000. For some reason, this causes grep to choke. Correcting the permission on the file level fixed everything. Just thought I'd mention this in case someone else runs into problem and note for someone to fix in future releases.

-- LynnwoodBrown - 17 Sep 2008

I have checked both the tgz, the MANIFEST and the Sandbox/CompareRevisionsAddOnDemoTopic.txt has the correct 644 setting so it is something that went wrong in your installation Lynnwood.

-- KennethLavrsen - 18 Sep 2008

Had that happen to me too. And I'm still not able to use this addon reliably on my TWikiVMDebianStable. Whenever I activate the corresponding Plugin the compare results in an empty page. Strange. Always thought it must be something wrong with my installation, but I did'nt find out what yet, so I chose to wait for somebody else to report something similar.

-- FranzJosefGigler - 18 Sep 2008

Bugs:Item6126 on broken UTF-8 characters filed.

-- KyungdahmYun - 18 Nov 2008

I need to set the param rev to the correct value in compare.pm sub _getTree to get the right value for %REVINFO%:

my ( $meta, $text ) = TWiki::Func::readTopic( $webName, $topicName, $rev );
$text .= "\n" . '%META{"form"}%';
$text .= "\n" . '%META{"attachments"}%';

# patch to get the right value for %REVINFO%
$session->{cgiQuery}->param( 'rev', $rev );

$session->enterContext( 'can_render_meta', $meta );

-- ManfredMeiser - 2009-08-28

Topic attachments
I Attachment History Action Size Date Who Comment
HTMLhtm CompareRevisionsAddOnDev.htm r1 manage 15.7 K 2006-09-13 - 02:14 MartinRothbaum Partially rendered compare on Beijing release - removed email address to avoid spam
HTMLhtml compare_WebHome.html r2 r1 manage 15.7 K 2006-09-13 - 02:16 MartinRothbaum Partially rendered compare on Beijing release
Edit | Attach | Watch | Print version | History: r73 < r72 < r71 < r70 < r69 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r73 - 2009-08-28 - ManfredMeiser
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.