Without this commit, what used to happen is that if ban-contributors
banned a contributor in a namespace, the pageidx of the main space got
overwritten with the pageidx of the namespace: since the values of
@IndexList and %IndexHash remained unchanged.
New approach: save the original value of $DataDir in
$NamespacesRootDataDir. When reading the value of $BannedHosts or
$BannedContent via GetPageContent in UserIsBanned or BannedContent,
and in DoBanHosts for ban-contributors.pl, use the root data dir; when
saving $BannedHosts or $BannedContent via DoPost, use the root data
dir.
To facilitate spamfighting, the namespace is not set when the current
action refers to one of the page ids in the @NamespaceIgnored list.
The default value for these is $BannedContent and $BannedHosts, in
other words, the pages 'BannedContent' and 'BannedHosts'.
Encoding of namespace and page name under Mojolicious is not OK and I
don't know why. I added some tests that try to at least prove that the
workaround in the config file is OK.
On a new server with Debian Jessie (8), Apache 2.4, Perl 5.25.1 and CGI
4.28 I'm getting double-decoded namespaces. An Umlaut will thus turn
into an undisplayable character (a questionmark in a black diamond).
Decoding of path_info was necessary on my old server with Debian
Wheezy (7), Apache 2.2, Perl 5.14.2 and CGI 3.52.
If you're still in the unfortunate situation, you can copy the old
implementation of NamespacesInitVariables into your config file.
As we derive a lot of filenames from strings in UTF-8 encoded files, we
need to make sure that any filename that might might be set by a user –
including all the filenames containing a directory deriving from
$DataDir – are passed through utf8::encode. That is, every character
gets replaced with a sequence of one or more characters that represent
the individual bytes of the character and the UTF8 flag is turned off.
In other words, -d $DataDir might not work if $DataDir contains a UTF-8
encoded string. The solution is to use the following replacements:
-f $name IsFile($name)
-e $name IsFile($name)
-d $name IsDir($name)
(stat($name))[9] Modified($name)
-M $name $Now - Modified($name)
-z $name ZeroSize($name)
unlink $name Unlink($name)
mkdir $name CreateDir($name)
rmdir $name RemoveDir($name)
(Using IsFile for -e is probably not ideal?)
If you don’t, and Oddmuse gets used with Mojolicious, and you use the
Namespaces Extension, and a namespace contains non-ASCII characters such
as ä, ö, or ü, these characters will end up as part of $DataDir and
trigger the problem.
I also wonder whether we should be using some other Perl library.
sub ParseData is fully backwards compatible. If some module runs it in list
context, then it will get listified hash like previously. New code should
always run it in scalar context though (everything in our code base
was changed according to that).
sub GetTextRevision is not backwards compatible (don't let “wantarray” usage
to confuse you). Most modules do not touch that subroutine, so we are probably
fine (modules from our git repo that do use were changed accordingly).
“EncodePage(%$page)” looks wrong. It seems like we should change it to accept
hash ref.
This option is never set and even it was set (in the old days it
indicated that the entire wiki was going to be exported as a single
file), then I don't see why that should prevent namespaces from
working.
There is no way to provide an encoding layer to directory names.
Therefore they need to be raw bytes and not characters. This becomes
apparent when creating namespaces containing non-ASCII characters.
The Debian installation uses ext3 and therefore raw bytes for
filenames unlike the HFS filesystem of Mac OSX.
Copyright years were updated. The maintenance output of for drafts was
cleaned up.
Replaced the $Id$ tags in $WikiDescription for all the modules and wiki.pl itself with a link to the source and an appropriate wiki page, if possible. This is shown in action=version and should help users figure out what another wiki has installed.
between intersites and namespaces.
(NamespacesInitVariables): Set it instead of a local variable.
(DoNamespacesList): Use it.
(NamespacesMenu): Add it to a menu.
the case of namespaces containing non-ASCII characters. This
should be legal, but lead to problems when generating links to
pages in such namespaces. The URL encoding of the non-ASCII
characters prevented the $InterSitePattern from matching. Instead
of using this regular expression, we now try and guess at the
string using URL constraints ([^/?&;=]+), URL decoding it, and
then checking the $InterSitePattern.
