You are here: Foswiki>Tasks Web>Item11969 (08 Jul 2015, MichaelDaum)Edit Attach

Item11969: Add default value for parameters passed to STARTSECTION macro.

Priority: Enhancement
Current State: Closed
Released In: 2.0.0
Target Release: major
Applies To: Engine
Component: INCLUDE
Branches: trunk
Reported By: SvenDowideit
Waiting For:
Last Change By: MichaelDaum
see AddDefaultValueToSTARTSECTION

diff --git a/core/lib/Foswiki/Macros/ b/core/lib/Foswiki/Macros/
index ad0366a..e483ffb 100644
--- a/core/lib/Foswiki/Macros/
+++ b/core/lib/Foswiki/Macros/
@@ -227,6 +227,12 @@ sub _includeTopic {
             # Rebuild the text from the interesting sections
             $text = '';
             foreach my $s (@$sections) {
+                $this->{prefs}
+                  ->pushTopicContext( $this->{webName}, $this->{topicName} );
+                $this->{prefs}->setSessionPreferences(%$s);
+                $this->{prefs}->setSessionPreferences(%$params);
                 if (   $control->{section}
                     && $s->{type} eq 'section'
                     && $s->{name} eq $control->{section} )
@@ -241,6 +247,8 @@ sub _includeTopic {
                       substr( $ntext, $s->{start}, $s->{end} - $s->{start} );
                     $interesting = 1;
+                $this->{prefs}->popTopicContext();


yes, this will not cut it in reality - at minimum i need to remove the section hash's internal use keys, otherwise their use in INCLUDE would change (type, name, start and end are a bit too generally useful to suddenly default to non-'')

-- SvenDowideit - 25 Jun 2012

Michael noticed and fixed: Breaks things in some strange combinations, because there's a "last" that doesn't clean up the stack. Happened to me when deleting the wrong topic.

-- SvenDowideit - 26 Jun 2012

I've implemented a more wholesome solution, with unit tests, but need to see what that does to Michael's issue, and if anyone sees anything else interesting.

-- SvenDowideit - 26 Jun 2012

Going to check it out.

The prev error was only ocurring randomly, making it very hard to reproduce. There was something manipulating the value of %WEB% and %TOPIC% so that the respective wiki apps produced a totally wrong delete-topic form. The url was correct - alas it was pointing to some topic once %INCLUDEd in the head of the skin, and nowhere else.

So there might have been some error with regards to the topic context stack not being pushed/popped symetrically. There should be an ASSERT comparing the number of pushes and pops at the end of the request. Not sure how to do that...

-- MichaelDaum - 26 Jun 2012
Topic revision: r12 - 08 Jul 2015, MichaelDaum
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy