Fixed a bug that $conf['compression'] is turned off when gzopen doesn't exist and gzopen64 does exist.

Move check after libraries are loaded, so that $conf['compression'] is not turned off in the case that gzopen doesn't exist while gzopen64 does exist, as inc/compatibility.php ought to have fixed.

Accept some new gTLD e-Mail addresses

Translation update (zh-tw)

Translation update (de)

Translation update (cs)

visibility from private to protected for DokuCssFile

Translation update (ru)

Fixed unrecognized regular expressions behind '&&' or '||' operators in JavaScript compression. Finally fixes #897.

by allowing longer TLDs (up to 63 characters, which is the DN maximum: https://tools.ietf.org/html/rfc1034):
"Each node has a label, which is zero to 63 octets in length."

For an up-to-date-length, see http://stackoverflow.com/a/22038535

Translation update (eu)

Fixed JavaScript compression. The compressor did not recognize a regular expression after a '&&' ot '||' operator. So it could happen that code had been cut off if the regular expression included '\//' (which was treated as a single line comment because of the regular expression not being recognized). Finally fixes #897.

that's the version in Debian old stable

Update index.php

Update lang.php

Translation update (hr)

AUTH_USER_CHANGE handler can modify passed data

this ensures there will be never, ever an outdated update message shown
after upgrade.

Fix for update messages never completely going away

Corrected compression for ++ and -- operator. Partially fixes #897.

preserve comments in less if 'compress' config disabled

Originally AUTH_USER_CHANGE handler could modify the user data, however,
auth plugin consequently worked with different copy of the array thus
effectively preventing any changes by the AUTH_USER_CHANGE implementer.

Otherwise comments are never visible in css.php

The existing logic for messages.txt requires some valid update
response (ending in %) to the messages update check before it clears
the current messages.

However update.dokuwiki.org appears to return an empty string response
if everything is up to date. (ie http://update.dokuwiki.org/check/46.1 )

As a result if there are update messages in messages.txt they don't
automatically go away after updating to the current version. The only
time they change is when a newer release comes out. The upgrade plugin
has logic in it to force a re-download of messages.txt, but currently
this just re-downloads the old update messages.

This change explicitly allows for "" as a valid "no messages"
indicator (distinct from false, which is the HTTP error indicator.)

Translation update (ko)

Fix for issues #877 & #885 related to a bug in PCRE 6.6