Look at the recent changes listing this topic's summary field containing $ nop, $ quot, $ percnt, $ dollar (space added since they get expanded). They get expanded, which is a bug. They should only expand if specified in the header="" and format="", not if found inside a $formfield().
Also reproducable here with a SEARCH on itself:
Topic |
Summary |
Item2837 |
Edit and FormattedSearch expands $nop, $quot, $percnt, $dollar in $formfield() |
--
PTh
I am raising this to requirement since content in formfields gets destroid:
- 'dollar'-nop disappears on edit
- 'dollar'-percnt, 'dollar'-dollar gets expanded on edit
- content after a 'dollar'-quot is lost
--
PTh
Sounds like the call to
expandStandardEscapes
in
Search.pm
needs to be moved up a few lines. Though I am surprised by this, as IIRC that call simply replaced a bunch of individual RE's that did the same thing.....
CC
expandStandardEscapes
is a good hint, though it is not (only)
Search.pm
what is affected: See PTh's initial comment, even a simple edit is enough.
It is too late for me to get it fixed tonight, but I think I've narrowed it to one of the many commits for
Item2905. CC wrote that this is thin ice, and indeed it is. Here's
part of the story:
Index: lib/TWiki/Form.pm
===================================================================
--- lib/TWiki/Form.pm (Revision 12257)
+++ lib/TWiki/Form.pm (Arbeitskopie)
@@ -386,10 +386,11 @@
if( defined( $value )) {
$value = $session->handleCommonTags( $value, $web,
$topic );
+ $value = TWiki::expandStandardEscapes( $value ); # Item2837
}
}
$value = '' unless defined $value; # allow 0 values
- $value = TWiki::expandStandardEscapes( $value );
+ # $value = TWiki::expandStandardEscapes( $value ); # Item2837
( $extra, $value ) =
$this->renderFieldForEdit( $fieldDef, $web, $topic, $value );
This is in
sub renderForEdit
. Currently,
expandStandardEscapes
is called unconditionally. But it may be called only if the data come from the form definition or template topic, but
not if they come from form data.
The fix is partial because it handles the case where the form definition is consulted, but fails to expand the escapes when data from a template topic have to be expanded.
HJ
Looks good now, or at least: Test cases pass. Instead of expanding standard escapes once unconditionally, it has to be done separately for each of the possible sources of initialisations:
- Initialisation per query param in
Form.pm
, sub getFieldValuesFromQuery
- Initialisation per template topic in
Edit.pm
, sub init_edit
.
- Initialisation per form topic in
Form.pm
, sub renderForEdit
.
Since I am not very familiar with form initialisation: Please test and break as you can. I added one more test case for "don't expand anything when editing a topic containing a form".
HJ
Still not done - at least the problem in SEARCH seems to persist. Seems to need more testcases to nail down, since
save
is broken as well.
HJ
Now (r12281) this item survives edit/view, and search is ok. Testcases pass.
Use at own risk
HJ
Excellent, thanks Harald for nailing this down!
--
PTh
4.1.0 released
KJL