Item2375: Couldn't save a topic while SetVariablePlugin was enabled
Priority: Normal
Current State: Closed
Released In:
Target Release: n/a
Seems that yesterdays improvements are now causing this error:
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.
Save time 1 with SetVariablePlugin (enabled)
Save time 1 without SetVariablePlugin (disabled)
Save time 2 with SetVariablePlugin (enabled)
Save time 2 without SetVariablePlugin (disabled)
--
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.
Save time 3 wit SetVariablePlugin (enabled)
--
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:
Save time 4 wit SetVariablePlugin (enabled)
Save time 4 without SetVariablePlugin (disabled)
To give some "Butter bei die Fische" I've attached the full topic which is saved just above or included.
--
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