Re: Slight issue with {=$LastModifiedSummary}
ABClf <[email protected]>
| Newsgroups | gmane.comp.web.wiki.pmwiki.user |
|---|---|
| Message-ID | <CACE3LEtptjy2_6W6SGgs-vp91Df7C_3JMnGntobJaU+Kww-dJA@mail.gmail.com> |
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 <[email protected]> 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 _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users