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

1. undef (no args on the stack) or
2. $includingWeb (another arg on the stack pending) or
3. $url or
4. $incWeb.$incTopic or
5. $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:

1. 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.
2. former $includingWeb will now be shown as $includingWeb.$includingTopic
3. $url isn't really a "topic", but so what. It couldn't be included, and that's what counts.
4. $incWeb.$incTopic is correct for where it is used
5. 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