Item10677: CompareRevisionsAddonPlugin doesn't set $NO_PREFS_IN_TOPIC

so thats 3 pointless topic access every operation (almost doubling the number of topics needed for a raw=all view).

1. CompareRevisionsAddon
2. InterWikiPlugin
3. SmiliesPlugin

sadly, because of the way it works (legacy wise) these topics are read and parsed even when doing a raw topic view - ie, when its not needed at all.

imo we should change this - that way http://foswiki.org/Main/SomethingSimple?raw=all= would only need to access 4 topics (or even less really)

1. siteprefs
2. the last editor's topic
3. webprefs
4. the topic...

we should probly consider inverting the default some time.

-- SvenDowideit - 25 Apr 2011

I don't see that CompareRevisionsAddOn or CompareRevisionsAddonPlugin actually use any preference settings. Probably safe to change this one.

InterWikiPlugin contains our $NO_PREFS_IN_TOPIC = 1; in both the release11 and trunk versions. Are you sure about this one?

Same for the SmilesPlugin - both trunk and release11 have the our $NO_PREFS_IN_TOPIC = 1; set.

-- GeorgeClark - 25 Apr 2011

I will take care of CompareRevisionsAddonPlugin.

The two other by design must read the topic that defined the smilies and the interwikis to build the regexes that then search for the patterns in the text. I cannot see how we can avoid this.

It may however make sense to build a cached regex for both instead of parsing the two files which takes time.

It requires a trigger mechanism that rebuilds the cache when people add new interwikis or smilies. But that cannot be so hard to do. Both plugins could simply do this in a save handler. If its setting file is saved then update cache.

If we put the plugin version in the cache file the plugin can upgrade its cache when the plugin is upgraded.

We have successfully done this with the language list and we could also go the same with the list of webs.

-- KennethLavrsen - 16 May 2011

I have fixed the CompareRevisionsAddonPlugin

The two others are confirmed to not check for plugin prefs. But by nature these plugin read the smilies and interwikis and I cannot see a way to avoid that with the plugins active.

We can optimise by making them with a small cache but by nature one way or the other the two plugin need to check the topic for smilies and interwikis at each page view.

I am setting this report to WaitingForRelease.

It should be separate bug items to figure out how to optimize the the two other plugins. This plugin needs to be closed for 1.1.4.

-- KennethLavrsen - 17 May 2011

brilliant, thankyou

-- SvenDowideit - 18 May 2011

Commenting is disabled while not logged in