The above novel approach has some problems.

1. If you only want the last 5 days entries you can't do it. The search parameters, (for some reason described on TWikiVariables) allow the last n hits but not the last 5 days.
2. You need table plugin.
   • We could this by giving TWiki an underlying aggregation - as described on FormattedSearchAcrossMultipleWebs
3. It shows all the Web* topics (which are considered noise by most)
   • We need a way to pull from the changeslog instead
   • even better we could update this view with a plugin with a hook to save.

A useful view, nonetheless.

-- MartinCleaver - 22 Oct 2003

This is useful. I changed web="all" to web="Codev TWiki Support Plugins" to list only webs relevant to the CodevCommunity.

A FormattedSearchLimitedByDate feature would be nice where you could specify limit="5 days" or limit="2026/01/14" instead of limit="5"

The noisy Web* topics can be excluded once ExcludeWebTopicsFromSearch is implemented.

-- PeterThoeny - 25 Oct 2003

How about renaming this page to SiteChanges and making it part of the standard distribution? This would agree with SiteMap, etc.

-- MartinCleaver - 07 Nov 2003

I considered this a useful enough idea to implement it immediately on my own site. In the process, I discovered something odd that limits it's utility significantly: the sort defined in the TABLE variable actually ends up sorting by day-of-the-month. This is not much of a problem on a site like this one that has a rapid change rate, but renders the list fairly useless on my site.

-- LynnwoodBrown - 08 Jan 2004

I guess the TablePlugin doesn't realise understand about time after the date and so sort as a string. Does this sound like the problem you are having?

-- JohnTalintyre - 09 Jan 2004

As a workaround you can use $isodate. It's not easy to read but it sorts correctly.

-- SamHasler - 09 Jan 2004

John - Yes, that is the problem I'm observing. Sorry I didn't describe it clearly.

Sam - I'll try using $isodate and I'm sure that will work.

-- LynnwoodBrown - 09 Jan 2004

I fixed my search (which Martin posted above incidentally) to make sure that the search is in chronological order when you first look at it. I've copied over my search from owiki.org, with tweaks to match local formats. (With a minor change on format for the date - this makes sorting on that column do more what you expect and as a bonus shows the revision number)

(The purpose of ?_foo=$rev BTW is to make it so that you can see at a glance from the topic name whether you've visited the page with that revision.)

-- MS - 04 Feb 2004

The links in the Last Modified column don't appear to be working. What should they be pointing to?

-- SamHasler - 09 Feb 2004

Probably something other than what they do at present - I just shifted things about a bit to make the search follow the intended meaning, rather than what it actually did. They could be made to point at the rdiff URL, but that would always give you the full history, rather than the last edit. If that's what someone want to change it to, the format should be changed to:

format="|$web|[[%SCRIPTURL%/view/$web.$topic?_foo=$rev][$web.$topic]]|$date ([[%SCRIPTURL%/rdiff/$web.$topic?_foo=$rev][$rev]])| $wikiusername |"

(Again the _foo parameter makes it simple to see instantaneously if the URL has changed since you last clicked. That idea came from MartinCleaver )

-- MS - 09 Feb 2004

Removed web column since it is in the topic column. Fixed broken rdiff link. Also, changed the r1.x link to a diff label because I find it confusing that a r.10 link shows the diffs, the label suggest to see that particular revision.

-- PeterThoeny - 10 Feb 2004

Looks almost identical to http://www.pmichaud.com/wiki/Main/AllRecentChanges now. (With new namespace creation & upgrades significantly harder in TWiki.)

-- MS - 10 Feb 2004

The limit=10 in the search is a per web and because of the way the webs are merged if there are more than 10 changes on one web today, and less than 10 in another it looks like it is showing all changes between the date in the first and last rows when if fact it does not.

As a stop-gap until we have FormattedSearchLimitedByDate I've made it into 2 searches, one on Codev with a limit of 20 (now 30 on 2nd Mar), and another for the other webs with a limit of 10. The table sorting should still work.

-- SamHasler - 11 Feb - 02 Mar 2004

added large context inline diff - basically equivalent to a topic view, but with changes marked up. please report any issues you find with it.

-- SvenDowideit - 18 Apr 2004

I've swaped the first two columns. I scan the Web.Topic column with my mouse and it's a bit of a stretch to the in-line diff link. This way all the topic links are near each other.

-- SamHasler - 28 Apr 2004

Added _foo=$rev to the URLs for diff and in-line diff for those that prefer to view topics using those links and want to be able to see at a glance from the link whether they've visited the page with that revision.

-- SamHasler - 27 Jul 2004

Replaced $web.$topic with $web/$topic in topic name links. This will have the effect of losing any link history that people may have been using, but the $web/$topic makes more sense since TOC anchor links take this form and I was finding that clicking on TOC links was having to reload the page. The problem with the anchor links was caused by a lack of RelativeAnchorLinks.

I understand the reason for supporting the $web.$topic syntax, but would it have been better implemented as an apache redirect instead of in the code?

-- SamHasler - 28 Jul 2004

Continued a bit where Sam left off. Exchanged ?_foo=$rev for #foo_$rev to be able to jump using the (TOC | topic end | to top) links without reloading the page at first click (Internet Explorer for some reason would still reload the page at first click with the ?_foo variable set). Exchanged $web.$topic with $web/$topic in two searches.

-- SteffenPoulsen - 08 Aug 2004

Added Wikilearn web to search.

-- SamHasler - 27 Aug 2004

Removed the double search and changed the limit to %URLPARAM{"limit" default="25"}% and links below the table to increase the limit. Also put %URLPARAM{"skin" default="%SKIN%"}% in the links so you can view the page in a plain skin and keep it when clicking the links.

-- SamHasler - 07 Sep 2004

Does anyone know why WebChangesForAllWebs is showing topics from all webs instead of just the webs specified by the web parameter?

-- SamHasler - 27 Oct 2004

The SEARCH had two web parameters: web="Codev, Plugins, TWiki, Support, Wikilearn" web="all". I removed the second one. This is an artefact of the recent refactor. The old code took the first web parameter, the new code takes the last parameter.

-- PeterThoeny - 27 Oct 2004

Changed web to a URLPARAM so that you can add &web=all to the url to see all webs.

-- SamHasler - 30 Oct 2004

Moved to TWiki.SiteChanges as I got no objections to my suggestion above. My intent is for this to make it into the distribution.

-- MartinCleaver - 31 Oct 2004

Changed SiteChanges to default to all webs as that is a sensible default for a topic that will be distributed. I had to revert it from being an include to being defined in this topic though so that this topic can still default to Codev, Plugins, TWiki, Support, Wikilearn webs (specified three times using URLPARAM, remember to edit them all if the default changes). There was no way to have it as an include and use a different web parameter.

Converted the links under the table to a form to make selecting other views easier. I'll move that to SiteChanges when I'm happy with it. If someone can work out how to make the radio buttons fit in better with the rest of the text I'd appreciate it.

If there are specific variations that users want to use then they can select them using the form and then bookmark the url or add a link to it somewhere.

-- SamHasler - 31 Oct 2004

Changed display of topic name to $topic(35, ...) to truncate overly long topic names. With this setting I get no rows wrapping onto more than one line in IE or Mozilla at a screen width on 1024 using the normal view (i.e. with the WebLeftBar).

-- SamHasler - 03 Nov 2004

1. Patch: Jump directly to first inline diff
   • Add patch HtmlAnchorsOnRdiffSequentialOutput to RDiff.pm
   • add #diff001 as lastpart of inline url (I did it above - but of course it has no effect untill RDiff.pm is patched)
2. Sorting (cf. Jan 2004 postings above)
   • Idea: enable correct sorting of date columns by prefixing with invisible $isodate and postfixing with whatever you wish user to see, e.g. $date
   • Sample:
     | <div style="display: none"> $isodate </div> $date |
   • For some reason a simple HTML comment does not do the trick, but the above will.
   • BTW: It seems to be working here without this hack - is the TABLE thingy changed ... hmm....

-- NielsKoldso - 28 Dec 2004

I think TablePlugin sorting was fixed. There's some reference to this on TablePluginDev in Nov 2003, although there's no mension in the change history of the plugin.

Also increased the context from 1000 to 9000 lines since sadly many topics are not refactored and have grown larger than the old limit.

-- SamHasler - 29 Dec 2004

The problem SamHasler had "_There was no way to have it as an include and use a different web parameter._" needs exploring.

The Sangalina web is seldom updated. I question whether we could move this off TWiki.org and continue to support it by using a rewrite rule.

-- MartinCleaver - 31 Dec 2004

No offence to Randy, but, should Wikilearn be in the standard list? The topics on it, while perhaps interesting, are not specific to TWiki's development and thus do not fit the content of the rest of the site.

The webs list ought to be variable - perhaps we should be using WEBS?

-- MartinCleaver - 03 Jan 2005

It's a small thing but I don't really see the utility of having #foo=$rev in the main topic link. MS says that it allows you to see if you've read that version. I suppose that's true if I made a habit of memorizing which version I last read!

More commonly, I may not have refreshed this page within a little while and clicking on a link shows me a version that might not be the most current. Plus, I can't simply refresh the page to see more recent updates - I have to edit the url.

Why not have the main topic link simply go the most current version? If someone wants to view the version number, they could still scan the links for diff/inline.

-- LynnwoodBrown - 01 Mar 2005

I want to pose my question above again because I'm finding #foo=$rev in the main topic link an annoyance. Before I go and change it, could someone give a rationale why they need this. If, as a gather from comments above, that the purpose is to allow a "quick glimpse" of the current version, wouldn't this still be available with diff/inline links. If I don't get any objections, I may change this in a few days.

-- LynnwoodBrown - 25 Apr 2005

OK, I've made the change I proposed above. Let's see how long before someone who used this feature notices.

-- LynnwoodBrown - 05 May 2005

! aaaargh, you did what? bloody hell! its the only way I keep up with whats changed. If you don't like it, you could go use the more useless WebChanges!

grrrr !

-- SvenDowideit - 08 May 2005

No worries, Sven! I just didn't see it's value so my apologies. I don't feel that strongly about it so it's back as it was.

-- LynnwoodBrown - 08 May 2005

after coffe, and a day doing other things, I think i understand - In my browser, a link that I have not been to is a different colour from one that I have been to. the #foo_$rev therefore tell me what has changed since i last read, without needing to remember anything at all. Your change meant that I suddenly had no idea...

-- SvenDowideit - 08 May 2005

Ahhh, now I understand what you were doing! My browser does the same but I had never thought of using it that way. You give me an idea for another approach which I have implemented on trial basis. If you notice, the topic version (displayed beside the diff links) is now a link to that version of the topic (same link format currently associated with the topic name). If I understand you correctly, viewing this link would serve your purpose and then perhaps we could make the topic link just be regular link. What do you think?

-- LynnwoodBrown - 08 May 2005

right now i don't like it I don't see there being any problem with the previous implementation was to begin with, and now oyu have hidden the functionality from anyone that does not know about it, by moving it to a non-obvious place.

Also, it is now misleading, as clicking on 1.80 one would correctly summise that the link would take you to versoin 1.80, which it will not do. (if someone has updated since then, it will take you to v1.81)

so, no, this version also devalues the quite useful feature.

btw, the #foo_$rev does not show you version $rev of the topic. it is just a simple mechanism to ensure that the browser can give the user a hint that they may not have read the latest version of the topic.

so - what exactly is your problem with a feature that a number of people worked hard to make useable?

-- SvenDowideit - 08 May 2005

And the reason it's an anchor is so that the clicking TOC links doesn't force a reload of the topic.

-- SamHasler - 08 May 2005

OK - I've changed all back to the way it was. I'll just make my case why I don't find this as intuitive as you obviously do and leave it at that.

• The link displayed as Web.Topic does not simply link to that topic - which for average user would surely be the "intuitive" result.
• The Web.Topic link, in fact, links to a specific version which, unless one is accustomed to interpreting the url, is not in any way apparent. If one refreshes that topic, you don't get the most current version. Is a "feature" that is neither tranparent or explained intuitive to a new user? I don't think so.
• Regarding your statement that the #foo_$rev providing "simple mechanism to ensure that the browser can give the user a hint that they may not have read the latest version of the topic" - are you referring to the url being the hint? If so, I just don't find it simple or intuitive mechanism. Depending on the size of my window and the length of topic name, the #foo_$rev is often not visible in my browser. And I can't simply refresh my browser to assure I'm looking the lastest version but rather I have to manually edit the url first.

At present, there is no simple link to the topic. That was my reason for suggesting making the versioned link associated with the version number displayed. However, my intent was only to support your particular approach to tracking topic changes while still allowing a simple link to the topic. I understand now that in a few raw cases, this link my not be completed accurate, however I don't see this as any more misleading then the current set-up.

As I laid out above, my issues with the current set up reflects how I use this page. I open up WebChangesForAllWebs first thing and then open topics I'm interested in separate tabs (in Firefox). If a topic is "hot" I'll probably just leave it open then then refresh it to assure I'm looking at the most current version or if I see (from refreshing the changes page) that someone has made a more recent edit. So to do this, I have to edit the url after opening the topic. Maybe not the most convenient mechanism for me but no big deal.

Anyway, this is a minor thing in the end and if the current setup makes the great amount of work you do for TWiki a little easier then I'm all for it. Enough on this and again, my apologies for any inconvenience caused.

-- LynnwoodBrown - 09 May 2005

Lynwood you have made some false assumptions. The #foo_1.X anchors on links do not make it link to a specific revision. All they indicate is that the topic was at that revision when the search on this topic was run. Clicking on it will always give you the head revision. i.e. If the link is to SomeTopic#foo_1.4 but it has increased to version 1.5 since the link was rendered, clicking on it will display the 1.5 revision. The browser will then try and scroll the page to an anchor called #foo_1.4 which doesn't exist (neither would #foo_1.5 or any such anchor) so it is effectively ignored by the browser.

So Lynwood you don't need to edit the url to see the latest revision. e.g. http://twiki.org/cgi-bin/view/Codev/DakarRedirectBug#foo_1.2 follow this link and you will not see revision 1.2, it's at least at 1.4 at the time I'm writing this which you can confirm from the revision number it will show on the page.

The utility of this is that each link is unique for that version so when clicked on it will change it to the visited link color. Reloading this topic or viewing it tomorrow you can then see which topics have been updated because the link will have changed and therefore will appear as unvisitied.

It's possible that you might 'miss' a revision (i.e you visit a #foo_1.4 link when it's at 1.5 and then visit it again then it shows as #foo_1.5) but most of the time I realise when this has happend and read more than just the latest change (I use the in-line diff's).

(Aside: I've just noticed that the RSS links use the form ?t=2005-05-09T19:52Z. It could be that time is a better choice than revision because it will always increase for merged revisions, however it should be using a #foo_ form to stop the TOC reload problem as I stated above (and potentially less confusing ). I'll look at unifying the formats tomorrow. (I'd also link to have another RSS feed that links to the context diffs, I'll look at that too.))

-- SamHasler - 10 May 2005

Slowly...slowly, the ignorance parts. I finally understand. Thanks Sam. And apologies for being so dense.

-- LynnwoodBrown - 10 May 2005

Hey Sam, I think you've just taught me some thing thanks.

every now an then my rss feed gives the impression that all my topics have changed, even though they have not. Its wuite possible that the timestamp has changed for some reason, and that's triggered the re-un-read marking.

interesting! - and to think - Lynnwood, if you hadn't gone fishing here, i'd have never known about this possible bug / fagility in RcsFile (i think)

-- SvenDowideit - 10 May 2005

I just added !TWiki.SiteChanges to SVN 4418.

I'm not clear whether documentation for this best belongs in DakarReleaseNotes - it seems too much of a trivial change to go in there.

-- MartinCleaver - 23 Jun 2005

yes, it should be added to DakarReleaseNotes; it need not be more than a single line, though.

-- WillNorris - 23 Jun 2005

What is the code in between "=" signs that (in my browser) appears as literal code in the page? Just below "Note You don't have to specify every setting"

Is that supposed to be doing something but not succeeding, or is it supposed to be giving me an example, of something, but I can't see what?

-- MartinGregory - 17 Mar 2006

It was identical to the search used for the table above but escaped so it could be viewed. I belived it was there to document the search but I don't think it's particularly useful so I've removed it.

-- SamHasler - 18 Apr 2006

This listing acts funny at the bottom, my guess is when there are dates with a preceding zero in them. It lists too few changes between 1 and 10 July.

-- ArthurClemens - 18 Jul 2006

Just in case anybody cares. Using the FilterPlugin I have developed a ChangesForAllWebs Solution which compares to the look and feel of the standard WebChanges. This is as follows

%STARTEXTRACT{sort="alpha" reverse="on" 
pattern="((20[0-9][0-9]+.*?)T(.*?)Z)-=-(.*?)-=-(.*?)-=-(.*?)-=-(.*?)-=-(.*?)-=-=-" 
format="<!--$2 $3--><div class=\"patternSearchResult\"><div class=\"twikiTopRow\"><div class=\"twikiLeft\">[[$4.$5][$5 ($4)]]</div><div class=\"twikiRight twikiSRAuthor\"> $6 </div><div class=\"twikiRight twikiSRRev\">$7 - $2 - $3</div><br class=\"twikiClear\" /></div><div class=\"twikiBottomRow\"><div class=\"twikiSummary twikiGrayText\">$8</div></div></div>
$n"}%
%SEARCH{ "." regex="on" nosearch="on" nototal="on" recurse="on" limit="15" web="all,-Main,-Sandbox,-Twiki,-Trash" excludetopic="Web*" reverse="on" order="modified" format="$isodate-=-$web-=-$topic-=-$wikiusername-=-$percntIF{\"$rev=1\" then=\"<img src=\\"%ICONURL{new}%\\" width=\\"30\\" height=\\"16\\" alt=\\"New\\" border=\\"0\\" />
\" else=\"r$rev\"}$percnt-=-$summary(120)-=-=-$n" }%
%STOPEXTRACT%

Some polish might be required for this. Pick up the idea.

-- StefanAlthoefer - 02 Aug 2008

I'm totally puzzled This is the search I used to filter out TWikiJanitor from WebChangesForAllWebs

| *Last Modified* | *Web.Topic* | *Last Editor* |
%!SEARCH{ "!META.TOPICINFO.*author=\".*?TWikiJanitor\"" regex="on" nosearch="on" nototal="on" limit="%URLPARAM{"limit" default="25"}%" web="%URLPARAM{"web" default="Blog, Codev, Plugins, TWiki, Support"}%" excludetopic="WebStatistics" reverse="on" order="modified" format="| $date - [[%SCRIPTURL%/rdiff%SCRIPTSUFFIX%/$web/$topic#_foo=$rev][diff]] / [[%SCRIPTURL%/rdiff%SCRIPTSUFFIX%/$web/$topic?type=last&render=sequential&context=9000&_foo=$rev#diff001][in-line diff]] - $rev | [[%SCRIPTURL%/view%SCRIPTSUFFIX%/$web/$topic#foo_$rev][$web.$topic(45, ...)]] | $wikiusername |" }%

It should work.. it worked until few days ago..., but now it shows for Codev only changes by TWikiJanitor ,which is the opposite of what it is supposed to do.

What is wrong? -- RafaelAlvarez - 29 Aug 2008

I still don't know why it didn't work... but I changed the search to use a QuerySearch and now it should work as intended.

-- RafaelAlvarez - 29 Aug 2008

People%2C%20some%20change%20to%20%3DURLPARAM%3D%20broke%20WebChangesForAllWebsDiscussion.

-- RafaelAlvarez - 28 Nov 2008

We tried to fix something, it broke other stuff. Is reverted for now.

-- PeterThoeny - 29 Nov 2008