Otherwise if you click "More..." it will give you a page that cannot be styled
like a journal (there is just no way to tell that it is a journal from css).
This didn't work as intended. Subroutines relying on memory strings such
as PageHtml were not returning any HTML leading to all sorts of
failures (no description items in RSS feeds, for example).
If for some reason it would be possible to not read a file and not
crash, then PageMarkedForDeletion could have marked it as marked for
deletion: $Page{text} =~ /^\s*$/ might have returned true even if
$Page{text} was undefined. Now we test for existence of the key in
addition for just whitespace.
Somehow the password form was limiting the number of characters to 50.
Private Wiki Extension relies on passwords that are 64 characters in length,
so I have increased the limit.
It was checking if the number of utf8 characters is <= 120, but obviously utf8
characters could be up to 4 bytes in length. 120*4 is much greater than 255
(which is a limit on lots of file systems), so it attempted to write files
with illegal filenames. This is now fixed.
Additionally $PageNameLimit option was added. Now you can choose max page
name length yourself (which is very useful for extensions like mac.pl or
private-wiki.pl)
These flags are essential for security. The problem we are trying to
solve is the following:
1) you visit a wiki using HTTPS and you set your password.
2) you accidentally visit the same website using plain HTTP
3) although you don't notice, your cookies are sent over the insecure
connection.
Even if that website has redirection, even it denies any insecure
traffic, your cookie is still leaked. That's how cookies work.
"secure" and "httponly" flags solve this. It means that these cookies
will only be sent over a secure connection. If you have set your
password using HTTPS and later you visit the same wiki using plain HTTP,
it will look like you are not logged in (because these cookies will not
be used when you access the website using a non-secure connection).
If you have HTTPS on your website -- ALWAYS make sure that you set your
password using it. Alternatively redirect all non-secure requests to
HTTPS - that's even better.
If you set your password using HTTP, the same cookie will be used for
both HTTP and HTTPS requests - this is done for compatibility with
HTTP-only wikis.
$ENV{'HTTPS'} returns 'on' or empty string. 'on' is truthy so it
should not create any problems, we can safely use it.
I've tested this, it works as expected.
We had a problem in the following situation: User A starts editing a
page at t1. This timestamp is stored in a the parameter oldtime. In the
meantime user B edits and saves the same page at t2. If user A saves,
the changes will be merged. If user A previews and saves later, the
changes would not be merged because the preview changed oldtiem from t1
to t2. This commit makes sure that the an oldtime parameter is prefered
over the actual page timestamp.
10 is just too low. For wikis with css page it means that you can only
fetch about 5 pages in 20 seconds.
I've seen my users complain about that limit and I've seen it myself
too many times.
Doubling the $SurgeProtectionViews should make it more sane.
The old code decided whether the show the replacement field as part of
DoSearch and set $ReplaceForm. By that time, GetHeader had already
called GetSearchForm, so it was too late. I'm not sure why the
variable was necessary in the first place and so I'm removing it
entirely.
grep ReplaceForm *.pl modules/*.pl t/*.t comes up empty, now.
This command was used:
find . -type f -print0 | xargs -0 sed -i 's/return undef/return/g'
The idea behind this commit is described on http://oddmuse.org/wiki/Refactoring page.
In short: 'return undef' returns (undef) in list context (a list with one element),
which is wrong.
The summary for uploaded files had nested p elements; this was
removed. When no summary is provided, we now remove the "#FILE..."
stuff. In this case, no summary is better.
When closing the pipe to grep, check the status returned by the child
process in $? and return all pages if there was an error (which means
that grep did not filter any pages).
As explained on my blog
<https://alexschroeder.ch/wiki/2015-01-13_Handwritten_Optimization>,
the current implementation is "suddenly" very slow. This is specially
noticeable when loading large pages. Without quite understanding how
this is possible, I'm reverting to the old implementation.
