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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.