Stefan Kamphausen provided a reason for liking the deprecated cal3
extension: he likes cal3 because it also displays the next and
previous month as opposed to calendar.pl which only displays the
current month.
This commit allows users to get the same behaviour by setting
$CalendarOnEveryPage to values greater than 1: 1 shows the current
month on every page, but 2 shows the previous and the current month on
every page, and 3 shows the previous, the current and the next month
on every page.
There were some files that did not offer "or (at your option) any later
version" in their license and these had to be left alone. This should
solve the incorrect FSF address issue #4 on GitHub.
There were some modules that did not offer "or (at your option) any
later version" in their license and these had to be left alone.
This should solve the incorrect FSF address issue #4 on GitHub.
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.
If you're accept-language settings included something for which no file
exists (such as "de-ch"), then the test for the file would
succeed (testing for the existence of "$LoadLanguageDir/") even though
no actual file will be loaded. This is fixed. Also: implemented actual
testing.
It seems like it is operating on url-encoded strings, so all we have to
do is to decode it. This, however, does not mean that we should print
decoded strings. ‘href’ attribute still has to be encoded (or so it seems).
