Description

The RecentChanges page displays incorrect results most of the time. By this I mean it skips changes made by other users, and clicking on the "Updated" button display the wrong diff.

Steps to reproduce

This particular bug is specific to one wiki. I also run another Wiki on the same box which works correctly. The one that works incorrectly was moved here from another box that used an older version (1.2.x). The data has been correctly updated as per the instructions.For example, a user created a page two days ago. It was correctly listed as new for that day. As soon as another user changed it, it no longer appears as a new page on that date!

As for the wrong diff, a lots of cases the diff will include multiple changes spanning many days, making it useless.

I think it has to do with incorrect timestamps stored with the pages.

Example

Here is the history of the page:

As you can see, it was created on the 16th, and modified by me on the 18th.

Here are the recent changes:

As you can see, it no longer appears as new on the 18th, even though it did before I modified it.

• Maybe because it is not new any more 2 days after it was created, but an existing page that was edited recently?

Details

Workaround

I've uploaded a patch that changes RecentChanges to work in a more predictable manner. -- MaxCampos 2006-10-24 05:38:38

Discussion

The wrong diff is not wrong technically - it shows the diff from your bookmark date to the last revision. If you set your bookmark 2 days ago, you will get all diffs from 2 days ago to current revision. Practically these diff are annoying - I always want to see the last change, and sometimes the change before and so on. Its possible only through the info action, with a lot of clicks and pain.

Something not working as you expect or like it doesn't make it a bug. The (usually green) bookmark diff AFAIK works correctly and as intended. A bookmark (as in a paper book) means: "I read until there". Moin's bookmarks are similar: "I read changes until there (in time)". One effect sometimes confusing people is that moin tries to aggregate changes and tries NOT to list a page multiple times. So if you edit a page today for 3 times, it shows only one RC entry, documenting that this page was changed (and listing [1-3] changes). This is quite clearly visible. But sometimes the following happens:

• a page gets changed yesterday
• same page gets changed today

Moin aggregates those 2 changes to 1 RecentChanges entry (under "today"), showing that the page was recently changed TODAY. It doesn't list it under yesterday, too, because if you review your bookmark diffs of all pages on RC, you would see that stuff twice if it did. You won't overlook a change, because the page is listed on RC. If you use bookmark diffs, it will show you exactly what you didn't read yet.

Some people think that this is a bug, because the entry under "yesterday" is not there (kind of "lost"), but moin just saves you work. This is intended and NOT a bug.

I've been using Moin for years now, and I find this behaviour very confusing. The display style of RecentChanges suggest that different days are different entities, and you would expect that change aggregation and diffs stop at a day boundary.

Anyhow, I know that Moin aggregates my changes, but in this example user Bogdan changed the page on 16th, and use Dimi changed it on 18th. Dropping Bogdan makes no sense. If a page is changed by diferrent people on the same day, I can see the different names, not only one. Why is it different in this case?

• Hmm, this is either wanted, too (maybe ask JürgenHermann ) or an implementation limitation.

I now see how this works (thank you for the explanation), but I always want to stop at a day's boundary. Any way I can get that behaviour?

• RecentChanges is a macro, macros are plugins. So you could make your own one, if you want.

After running this in a debugger a few times, I believe the problem here is that once a page is displayed on the recent changes list, it's not displayed any longer for any reason -- irrespective of when the older change(s) happened. This is due to the "ignore_changes" stuff in RecentChanges.py.

• I think after applying this patch, RC will (still) show bookmark diffs between "before current change on RC" and "latest revision" (you didn't change that part). Thus, every diff (of the same page you now have multiple times on RC) will show partly duplicate information (information you already have read when going through all diff links). This is an annoyance the original behaviour tries to avoid. -- ThomasWaldmann 2006-10-04 07:27:46

The patch at MoinMoinPatch/LessConfusingRecentChanges addresses this issue. -- MaxCampos 2006-10-24 05:38:38

Example

Revision history

Without the patch (ignore_changes in place)

With the patch (ignore_changes removed)

-- MaxCampos 2006-10-03 23:51:08

BTW, if someone does make a patch for RecentChanges to behave in a "waste your users time" manner (like showing every change separately or showing the same diffs multiple times), he should be aware that chances getting this into main branch are rather low. Chances are slightly better if this behaviour is driven by a user preferences setting. On the other hand, every wiki admin can feel free to drop his own RecentChanges.py into data/plugin/macro/ - but be aware that your users might hate you if you increase their workload.

• Thomas, I'll update the patch I previously provided. My 2 cents: RC as it is now creates a false perception of being a comprehensive list of changes, which it is not. As the "wikimaster" for our nonprofit organization I must follow RC and fix errors made by others. I scan for users who are notorious for making syntax mistakes and double check content accuracy for really important pages. With RC as it is now, some of those changes sneak by without ever appearing on the RC page. Further, if I left RC alone it would only be a matter of time before someone else gets tripped up on this & I receive a "Max, why doesn't my recent change show up on the recent changes page?" type question. These folks require training to be able to use the GUI editor; there's no way they'll understand current RC behavior. We'll just have to agree to disagree on the benefit of displaying every change, every editor and every comment. I'll add this to my standard set of moin install patches. -- MaxCampos 2006-10-06 21:05:56

• I really think the current RecentChanges behavior is also very user confusing, and have had lots of complaints about it from my users (including myself). Thanks Max for putting together a patch for the old behavior. It is a shame that the maintainers are so wed to the current behavior, as it is really confusing and unexpected. -- SeanDague 2024-11-22 04:50:33

• Sean you can sign by @ SIG @ without the blanks. Your arguments are user dependent. So may be we should think on adding a feature request to have the possibility to choose between those different behaviour. -- ReimarBauer 2006-12-31 17:56:08

I find the standard behaviour of Moin very confusing, too. Max, could you please provide the patch here, so that people interested in this horrible, extra-workload behaviour could download it? Thanks!

Moreover: I would strictly recommand to move the patch Max provided to the main branch and call his patch "RecentChanges"! Why? Because Jürgen, Thomas and the other seem to confuse "RecentChanges" with "LatestChanges"! The actual behaviour of Moin is not a "RecentChanges" but a "LatestChanges" behaviour. RecentChanges means: a list of all the changes being made in the last, recent days. "LatestChanges" means: only show the latest changes, the latest version of a page, the newest edits of a page (Please look for the differcence of the two words "recent" and "latest" in some dictionary!). And that's what we have in Moin: "RecentChanges" is actually a "LatestChanges"! But normal users would expect, when reading "RecentChanges", to get a chronological list of all the recent changes and not a list of "latest versions or edits on a page". I was confused by that so called "RecentChanges" behaviour of Moin too. I can understand, that many other users are confused by that, as you have told us Max, too. This again shows the reluctance and unwillingness of the main developpers of Moin to understand what's going on in normal users heads, see for that also http://moinmoin.wikiwikiweb.de/UsabilityObservation/HowToGetHistory. That's why usability is so poor in Moin. And I don't think this is going to change in future. Rahter the discussion on usabiltiy will remain on that autistic level. Having nearly no contributions on UsabilityObservation does not mean: Usability is prefect! It could also mean: Moin is still to freeky, to complicated for normal users, too many things unclear, so that they not even start to post their ideas. Most posts are from Wikiadmins, which couldn't be considered as normal users. And when normal users do post some ideas, then their ideas are turned down. So how to improve?

• I have applied the patch to my wiki. Using it for a week showed that Thomas' observatin is true. In 90% of the cases it really is a waste fo time to have pages displayed several times. However, there are a few circumstances when it would be helpful (e.g. when I want to observe the activities of all users).

• My solution was to rename the patched version to AllChanges, and to have both coexist. I added a note at the bottom of RecentChanges, explaining what it does and linking to AllChanges. Would this be a solution that is applicable to MoinMoin in general? -- ChristophKoenig 2006-11-15 16:33:15

Plan

• Priority:
• Assigned to:
• Status:

CategoryMoinMoinNoBug