There's a feature of INCLUDE to let you specify a warning text
if the include fails. So
%INCLUDE{"NonExistentWeb.NonExistentTopic" warn="where is my topic"}%
returns
where is my topic
instead of an inline alert.
Docu says you could use a
$topic
being replaced with the topic.
But
%INCLUDE{"NonExistentWeb.NonExistentTopic" warn="where is my $topic"}%
returns
where is my NonExistentWeb
and not
where is my NonExistentWeb.NonExistentTopic
Test: where is my
NonExistentTopic
Infact, the problem goes deeper. The function to render the is
include warning is
TWiki::_includeWarning
being used for any possible
error that could occur during an INCLUDE (opic_not_found, already_included,
bad_protocol, geturl_failed, bad_content, etc).
Now, if
_includeWarning
is called and the
$warn
argument is set
to some default message as in the examples above it will fetch
one
extra argument from the stack and replace
$topic
in the warn string with it.
Looking at the calls to
_includeWarning
this next argument is
-
undef
(no args on the stack) or
-
$includingWeb
(another arg on the stack pending) or
-
$url
or
-
$incWeb.$incTopic
or
-
$contentType
which is all wrong as it is everything but not a
$topic
.
Just one example:
You type:
%INCLUDE{foo="bar"}%
You get:
Warning: Can't find topic "".""
This has the potential to break TWiki Applications, so regrading as Urgent. Marking as Actioning, as Micha's analysis is pretty clear.
CC
Apparently the problem has been foreseen, there's an old
SMELL
comment in the code. The code will remain smelly, but at least the behaviour will be sort of correct:
- If no topic is given, a makeshift
"".""
will be inserted. For everything more verbose like (no topic given)
it is too late since this is an insert for a MAKETEXT
message, so should be language-agnostic.
- former
$includingWeb
will now be shown as $includingWeb.$includingTopic
-
$url
isn't really a "topic", but so what. It couldn't be included, and that's what counts.
-
$incWeb.$incTopic
is correct for where it is used
- For
$contentType
messages it is still not possible (and never has been) to define useful custom error messages.
The flaw is that
sub _includeWarning
triggers messages with different argument counts. The actual interface is between the callers of
_includeWarning()
, which pass a keyword, and
messages.tmpl
, which defines the appropriate blocks matching these keywords. This can't be mapped properly to one single user defined message.
And to make that clear: I
am currently actioning.
HJ
4.1.0 released
KJL