[pmwiki-users] Slight issue with {=$LastModifiedSummary}

[ABClf]

Thank you Petko for advice and great support ;
fix is done now, with $EnableRCDiffBytes in place rather than former
cookbook, all looks fine for future edits.
Gilles.

Le mer. 27 sept. 2023 à 07:46, Petko Yotov <5ko at 5ko.fr> a écrit :
>
> On 27/09/2023 02:30, ABClf wrote:
> > I have a slight issue with {=$LastModifiedSummary}, when used in
> > pagelists.
> > I'm expecting the summary for the last edit only, when it exists ;
> > but in place of that, I am given a list of the summaries of recent
> > edits (but not all summaries from the beginning : only a few, and I
> > can not see what is the logical reason of the limited aggregation).
> > And, my Group.RecentChanges look all fine, showing the last summary, as
> > normal.
> >
> > I have an impacted test pagelist shown here :
> > https://www.languefrancaise.net/Test/LastModified
> > where pagelist is something like :
> >
> > (:pagelist group=Bob,Tintin "Roland de L." fmt=#rdl1
> > order=-$LastModified count=30:)
>
> (Off topic: "order=-time" would be faster and more portable.)
>
> > [[#rdl1]]
> > *[[{=$FullName}|+]] | [[{=$FullName}?action=diff|diff]]
> > **{=$LastModifiedSummary}
> > [[#rdl1end]]
> >
> > PmWiki website doesn't have this issue
> > (https://www.pmwiki.org/wiki/Test/LastModified)
> >
> > It is quite a recent issue I guess but that's not something I would
> > have seen immediately as soon as it had appeared.
>
> Thanks for the report.
>
> Version 2.3.24 refactored the change summary code into a separate
> function which is now processed a little later than before.
>
> I see on your profile page on pmwiki.org you have a custom edit function
> that adds the revision number to the end of $new["csum"] and
> $new["csum:$Now"], and you also use DeltaBytesRecentChanges.
>
> Until 2.3.23, the core function HandleEdit redefined $new['csum'] this
> before calling your function.
>
> Since 2.3.24, it does this after calling your function, but if
> $new["csum:$Now"] is already defined, it considers a recipe has already
> done what is needed so it skips it.
>
> When a page is saved, all properties from the previous version are
> copied into the new version, which means the new "csum" property is
> initially the previous one. Your custom function now has access to the
> previous change summary, not to the latest one, and it adds the revision
> number (with every edit, the next revision number is appended rather
> than replaced).
>
> I didn't anticipate this problem, I'll consider if something should be
> done in the core.
>
> For a quick fix, you can move your function processing after the new
> SaveChangeSummary:
>
> replace:
>    array_unshift($EditFunctions, "NumeroRevision");
>
> with:
>    InsertEditFunction("NumeroRevision", '>SaveChangeSummary');
>
>
> I see you also enabled a feature that shows the number of bytes added or
> removed in the edit like (+123).
>
> If you are using the core feature $EnableRCDiffBytes, no need to do
> anything.
>
> If you are using one of the older recipes, they also need to be
> processed after SaveChangeSummary -- I just updated
> Cookbook:DeltaBytesRecentChanges, and Cookbook:PageDiffSize is already
> there.
>
> Petko