Item2375: Couldn't save a topic while SetVariablePlugin was enabled

Seems that yesterdays improvements are now causing this error:

• SetVariablePluginError.log

So saving failed but succeeds when the SetVariablePlugin will be disabled.

-- IngoKappler - 18 Nov 2009

Quickfix. Please test.

--- lib/Foswiki/Plugins/SetVariablePlugin/Core.pm       (revision 5573)
+++ lib/Foswiki/Plugins/SetVariablePlugin/Core.pm       (working copy)
@@ -56,6 +56,8 @@
 sub applyRules {
   my ($this, $web, $topic, $meta, $text) = @_;

+  return unless $this->{rules};
+

-- MichaelDaum - 18 Nov 2009

Thanks, it fixes the issue.

Could it be that the SetVariablePlugin introduces a speed issue when saving topics? Please find here some screenshots with a rather complex topic but nevertheless the time for the post differs hugely with the plugin enabled or disabled. Note, this happens on a topic where the SetVariablePlugin isn't used.

-- IngoKappler - 18 Nov 2009

This looks very strange. I don't see these numbers at all. Is there an interplay with some other plugin that you've installed?

I released a new plugin version which also includes some minor performace tweaks.

-- MichaelDaum - 18 Nov 2009

Yep, there is an interplay with other plugins on the same page and quite some includes. The page is rather complex.

Unfortunately your performance tweaks don't seem to have any effect here but thanks anyway.

-- IngoKappler - 18 Nov 2009

Which other plugins do kick in during save? And why does SetVariablePlugin make a difference?

-- MichaelDaum - 18 Nov 2009

It is related to the HolidaylistPlugin but only if I include the table definition from another topic. The included definition is:

%HOLIDAYLIST{ startdate="-15" days="120" allowvarsininclude="on" showoptions="on" showweekends="0" enablepubholidays="1" showpubholidays="0" pubholidayicon=":-)" adayofficon="8-)" holidayicon="8-)" notatworkicon=":w1:" tablecaption="Time Planning %SPACEOUT{%BASETOPIC%}%" namepos="both" todaybgcolor="#fff6a8" tableheadercolor="#bdc6bd" weekendbgcolor="#bdc6bd" showstatrow="off" showstatcol="on" showstatsum="on" statformat="%{pp} | %{ii:8-)} | %{ii::skull:}" statheader=" :-) | 8-) | :skull: " }%

The setting allowvarsininclude="on" are active there and it was introduced as described in Item1652. Setting it to "off" doesn't make a difference nor removing it. Anyway, I need the setting to be "on" and it is just a guess it could be related.

I don't understand why SetVariablePlugin makes a difference. How is it processing the includes? Why does it have such an effect if SETVAR, UNSETVAR and GETVAR aren't used in the saved topic?

Now I found if I save the topic where the includes point to, the times with and without SetVariablePlugin look like that:

To give some "Butter bei die Fische" I've attached the full topic which is saved just above or included.

• WikiCodeTimePlanning.txt

-- IngoKappler - 18 Nov 2009

HolidaylistPlugin, this one is a real resource hog.

Try this

--- lib/Foswiki/Plugins/HolidaylistPlugin.pm    (revision 5574)
+++ lib/Foswiki/Plugins/HolidaylistPlugin.pm    (working copy)
@@ -116,6 +116,7 @@
 {
 ### my ( $text, $topic, $web ) = @_;   # do not uncomment, use $_[0], $_[1]... instead

+    return if Foswiki::Func::getContext()->{'save'};
     Foswiki::Func::writeDebug( "- ${pluginName}::commonTagsHandler( $_[2].$_[1] )" ) if $debug;

Honestly I really don't know why holidaylist is soooo slow. It is by far the slowest page on one of my client's intranet. Still, your numbers indicate an interplay with SetVariablePlugin. Try to enable the DEBUG flag in lib/Foswiki/Plugins/SetVariablePlugin/Core.pm to see what happens during save.

-- MichaelDaum - 19 Nov 2009

I don't know if this is good or bad news but when I now tried to reproduce it while having all the debug stuff active, I cannot reproduce it. The time for the post is definitely max few seconds nothing very very high.

So I'll close the issue and may re-open it in case it re-occurs, for now let's forget.

I've just been wondering where the debug log should be. I looked into foswiki/data for debug.txt but it wasn't updated. Is this the right place or could I have missed some setting maybe in configure to activate it? I did what you described above for HolidaylistPlugin and SetVariablePlugin.

-- IngoKappler - 24 Nov 2009

Just managed to reproduce it. Seems like emptying browser cache and triggering a full page reload changes the picture.

-- IngoKappler - 24 Nov 2009

Ok, looks like this is the fix, if the new line is active the post saves much quicker, if inactive it takes ages.

--- lib/Foswiki/Plugins/HolidaylistPlugin.pm    (revision 5574)
+++ lib/Foswiki/Plugins/HolidaylistPlugin.pm    (working copy)
@@ -116,6 +116,7 @@
 {
 ### my ( $text, $topic, $web ) = @_;   # do not uncomment, use $_[0], $_[1]... instead

+    return if Foswiki::Func::getContext()->{'save'};
     Foswiki::Func::writeDebug( "- ${pluginName}::commonTagsHandler( $_[2].$_[1] )" ) if $debug;

I didn't see a modification policy on the HolidaylistPlugin but if you agree I am for fixing the HolidaylistPlugin.

@Daniel, do you agree?
BTW: Releasing a new HolidaylistPlugin will also release the enhancements/fixes already done in Item1652. That's what I would like to see anyway after using this unreleased version for several months now.

Daniel, if you are short in time I can do all the release stuff if you like.

-- IngoKappler - 24 Nov 2009

Hey, thanks a lot Michael & Daniel!

-- IngoKappler - 24 Nov 2009