I just updated the
TWiki:Plugins.BlackListPlugin (see
Item796) and found out that there is an issue with the variable evaluation on Dakar which results in an unusable the Plugin on Dakar.
The BlackListPlugin topic has several
%BLACKLIST{...}%
variables. They are evaluated conditionally based on the action, e.g.
%nop>BLACKLIST{ action="user_score" }%
or
%BLACKLIST{ action="spam_show" }%
. The proper behaviour is that those variables get evaluated in the commonTagsHandler callback one by one (as it does in Cairo). In Dakar it looks like the variables are
already evaluated when commonTagsHandler is called.
Extracted variables from Plugin topic:
* Current BANLIST: %BLACKLIST{ action="ban_show" }%
* Your current score: %BLACKLIST{ action="user_score" }% for IP address %REMOTE_ADDR%
* Current SPAMLIST: %BLACKLIST{ action="spam_show" }%
Cairo results in this output:
- Current list: 203.88.152.3, 1.2.3.4
- Your current score: 7 for IP address 71.141.119.124
- Current list: cncxj\.cn
Dakar results in this output:
- Current list: 203.88.152., 203.88.155., 219.65.75.
- Your current score: 203.88.152., 203.88.155., 219.65.75. for IP address 71.141.119.124
- Current list: 203.88.152., 203.88.155., 219.65.75.
It looks like Dakar evaluates all variables to the same (incorrect) value. Strangly, they all get evaluated to the BLACKLIST setting. Attached is the debug.txt output where you can see that the variables in the topic text are already evaluated when commonTagsHandler is called!?!?!? Text supplied to commonTagsHandler is enclosed in
>>>>>>>>>>
and
<<<<<<<<<<
.
Any idea what is going on?
--
PTh
I had the same display of the ban list instead of my score under Cairo, so that behaviour hasn't changed. See
Item799
--
AJA
Hmm, I have Cairo and Dakar installed on the same machine. Happens here only on Dakar. I recall that you reported this in
TWiki:Plugins.BlackListPluginDev in April. Double-checking, was that really on Cairo and not on an early Dakar?
--
PTh
I did some more debugging, no luck.
_makeFileName( "spam_list" )
produces the right filename. The text supplied to commonTagsHandler has all variables already expanded, including all
%BLACKLIST{...}%
. Puzzled.
--
PTh
TWiki::Func::getPreferencesValue( "\U$pluginName\E_BLACKLIST" )
returns the Plugin's BLACKLIST setting,
203.88.152., 203.88.155., 219.65.75.
, which by coincidence is the same variable name as
%BLACKLIST{...}%
. Does this indicate a bug in the preferences handling?
--
PTh
Confirmed. I renamed the BLACKLIST setting to BLACKLISTXXX and now it works! What is the reason to evaluate all
%BLACKLIST{...}%
prematurely and assign the Plugin's BLACKLIST setting to it?
--
PTh
I worked around this bug by changing
%BLACKLIST{...}%
to
%BLACKLISTPLUGIN{...}%
(svn 7224). The Plugin now works on Dakar.
However: This is a bug that needs to be fixed. Other Plugins might run into the same issue.
--
PTh
I assume you are running that query in the plugin topic (
BlackListPlugin), but I don't know what your test environment is so I can't be sure.
Anyway, the probable reason is that you have declared a topic variable (preference value) BLACKLIST in that topic. Dakar clarifies a confusion that existed in Cairo, between preferences and twiki variables, which had a common syntax but were handled quite differently. The resolution is to treat them identically, so preferences and
TWikiVariables are parsed by the same code. Thus %BLACKLIST{}% is equivalent to %BLACKLIST%, and if a %BLACKLIST% preference is defined then it will be inserted in place of %BLACKLIST{.*}% everywhere.
Note that this is an elegant solution in several ways:
- it allows an administrator to electively disable variables processed by plugins, simply by defining an overriding preference.
- it rationalises the semantics in line with the common syntax.
- it allows a single parser to do all the work, allowing localised optimisation.
- it prevents a plugin from accidentally kidnapping system TWiki variable (while this can still be done by registering a tag handler, it's a much more explicit process).
- the ground rules are set for a possible future extension to support parameterised TWikiVariables e.g.
- Set CAR{make model} = My car is a %make% %model% %CAR{make="Aston Martin" model="DB9"}%
The most logical solution to your specific problem is to simply to rename the variable in the plugin topic to sidestep the conflict:
- Set BLACK_LIST = ....
- Set WHITE_LIST = .... (for consistency)
I have enhanced the documentation in
DakarReleaseNotes and
TWikiVariables to highlight this to plugins authors. I also checked all the plugins for potential conflicts of this kind, and there are no others.
Please close this issue when you are happy.
CC
As indicated earlier I changed the plugin variable name.
I can see that there are benefits to changing the spec. Although I believe that this causes confusion. This spec change caused me to debug the plugin for several hours, and Anton was not able to use the plugin for many month. Closing this in the interest of a speedy release, personally as a "disagree and commit" item.
--
PTh