An error in the Makefile treated all *.pl files in the translations
directory as translation files -- including these other files which are
not regular translation files.
Changes to oddtrans make sure that lines starting with # are comments
and will be stripped when the translation file is read. When writing new
translation files, comments are added to indicate which files are being
processed right now. This will help translators figure out where the
texts originated from. Note that every key appears only once, so
translations will be missing in the section for later files if they
appeared in earlier sections.
Recreated new-utf8.pl in order to illustrate the new format.
Previously if some user cancelled his request (simply by pressing Stop button
in his browser), then the script will receive a TERM signal or the like.
This means that some locks could be left behind, which required someone
to unlock the wiki manually (by using Unlock Wiki action).
Now we remove these locks automatically!
However, some tasks might want to handle such situations gracefully. That's why
%LockCleaners hash was added. Use lock name as the key and put a coderef as a
value. If SIGTERM (or a bunch of other signals) is received, then it will run
this code, which, supposedly, cleans all of the stuff after it. Private Wiki
Extension was changed according to that, so you can see it in action.
Also, tests added!
Modules are not loaded recursively, so we are free to use any directory inside
$ModuleDir. It is also where translations are located in the git repo.
Also, %library was renamed to %TranslationsLibrary (which is now "our"). This
is required for tests and for custom configuration.
Remember the problem with toc.pl when the whole page was *sometimes* not
utf8-decoded? There were some thoughts that it might be associated with
memory files, and it is correct. Although I was not able to narrow it down
last time, now I did (simply because this problem appeared elsewhere).
If you look at $output variable after utf8::decode with Devel::Peek, you
will see two variants of flags. This one looks good:
FLAGS = (PADMY,POK,pPOK,UTF8)
And this one is wrong:
FLAGS = (PADMY,POK,pPOK)
This problem is weird because it works inconsistently. Most of the time
you will get correct output, but sometimes it will be broken.
Someone has to golf it down to something short in order to submit perl
bug report. This, however, does not look like a simple task.
Current workaround is as stupid as it looks like, but it works.
Somehow assigning it to another variable solves the problem (which, by the
way, is similar to solving other perl string-related problems).
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 also requires a change in gravatar.pl because we can no longer test
for MailNewGetCommentForm. Instead, we test @MyFormChanges as variables
are being initialized and if MailCommentAdditions is already on it, we
don't add GravatarFormAddition.
GetEditForm and GetCommentForm will now call all the subs in
@FormChanges in order to let them change the generated HTML. This is
used by all the modules that used to hook into either of these two
functions.
A typical change from questionasker.pl:
push(@MyFormChanges, \&QuestionAddTo);
sub QuestionAddTo {
my ($form, $type, $upload) = @_;
if (not $upload
and not QuestionaskerException(GetId())
and not $QuestionaskerRememberAnswer && GetParam($QuestionaskerSecretKey, 0)
and not UserIsEditor()) {
my $question = QuestionaskerGetQuestion();
$form =~ s/(.*)<p>(.*?)<label for="username">/$1$question<p>$2<label for="username">/;
}
return $form;
}
This commit als moves from &$foo to $foo->() based on a recommendation
in Modern Perl by Conway.
We already called all the subs on @MyFooters and printed the result,
but this commit moves all the code from PrintFooters into subs and
puts those subs on @MyFooters. This allows us to write modules that
can better control where exactly their output should appear. In this
case the change was required in order to allow the Google +1 module to
coexist with code that maybe prints the comment form for all pages.
For example, knowing that the Google +1 sub is the first on one the
list because of unshift(@MyFooters, \&GooglePlusPrintFooter), we can
now write the following:
splice(@MyFooters, 1, 0, \&MyCommentsInTheFooter);
sub MyCommentsInTheFooter {
my ($id, $rev, $comment) = @_;
if (not $GooglePlusThisPagePrintedJournal
and (GetParam('action', 'browse') eq 'browse'
and $id and $CommentsPrefix
and $id ne $RCName
and $id !~ /^$CommentsPrefix(.*)/o)) {
my $target = $CommentsPrefix . $id;
my $page = '';
$page = PageHtml($target) if $IndexHash{$target};
return $q->div({-class=>'comment'},
$q->h2(T('Comments')),
$page)
. GetCommentForm("$CommentsPrefix$id", $rev, $comment);
}
}
The Google +1 extension was also fixed to not triger the EFF's Privacy
Badger. This is OK because we're using a two step button: The user
needs to click a button before we're loading the script from Google.
$q->param in list context can be problematic. At the same time, we don't
want to depend on $q->multi_param because it was only added in CGI 4.08
(2014). That's why we're setting $CGI::LIST_CONTEXT_WARN = 0 instead.
When the GrepFiltered sub was removed, we didn't check our modules. As
it turns out, tags.pl and mac.pl hooked into this sub to do their job. A
simple no-op Filtered sub was reintroduced for those modules.
Also, all instances of $UseGrep were removed.
Displaying the cookie is dangerous. If someone finds a way to perform XSS
attack, then he could steal the cookies just by looking at the page contents.
Please note that otherwise cookie contents are not visible from javascript
due to httponly flag.
This feature was not really useful anyway.
