now the method is aborting early again unless the data is actually used

This adds an event to dbg_deprecated(). This allows plugins to handle
deprecation warnings. One example would be @cosmocode/dokuwiki-plugin-sentry

One thing I don't like, but don't know how to avaoid is that this
function used to abort super early when $conf['allowdebug'] wasn't set.

However for the sentry plugin you probably would want logs, but still do
not show any debugging to end users (which allow debug would do).

So now the backtrace is always built, the event triggered and then
everything is sent to dbglog() which may simply throw everything away.

Suggestions on how to improve this welcome.

If SSL is not supported, a HTTP request will be made. In the log the request type will be indicated, but on the frontend no additional message would be shown (I think it's better to notify admins about non-SSL situations, but currently when this fetch encounter error, no error message will be shown, so it's better not to add any warning).

I supplemented the existing comments on the methods in which there was not enough information to the standard phpDoc.

DokuWiki assumes that the server's time is correct. Especially page
revisions and cache handling depend on correct time. If that's not the
case it can lead to problems later (as mentioned in #1644).

This patch adds a very simple time check using the Date response header
from the DokuWiki server to our do=check mechanism.

In an older version of PHP a file_exists() call would issue a warning
when the file did not exist. This was fixed in later PHP releases. Since
we require PHP 5.3 now, there's no need to supress any error here
anymore. This might even give a minor performance boost.

that's the version in Debian old stable

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

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.)

This should avoid problems when a WiFi login redirect intercepts the
update check.
See https://forum.dokuwiki.org/post/45076

This introduces a new dbg_deprecated() function which allows for easy
marking of deprecated functions. Each call is logged to the debuglog
when debuggin is enabled.

Removed extraneous whitespace to eliminate errors reported by the
Squiz.WhiteSpace.SuperfluousWhitespace sniff.

for completeness (& defensive coding), test ['show'] against MSG_PUBLIC in case its redefined to a non-zero value

add capability to restrict recipients of dokuwiki 'msg' alerts.  This is useful where message is added to the queue before authentication is initialized

We now have two defines for checking for UTF-8 and Unicode property
support in PREG and use them to work around FS#2636 on older systems.

we now touch the messages before the actual update happens. this should
lower the chance of more than one update check running at a time.

these are already checked in init.php, so we can save some space here

This bug occurs on systems where writing a zero-length string to an
empty file does not update the file's modification timestamp.

This leads to the messages.txt being downloaded almost endlessly, causing
long delays for logged-in users. Visitors are not affected, because the
messages.txt is only updated for logged-in users.

With this test it should be possible to detect if the search index has
been corrupted by using Rincewind RC or a git version of the weeks
before the RC release.

This commit fixes two bugs that occurred when msg() was called after
html_msgarea() had already been called.
- the $MSG array is now cleared when it has been printed (otherwise $MSG
  has been printed again when another msg() call was done)
- headers_sent() didn't work for me, it always reported false although
  html_msgarea() had already been called which might be explainable with
  output buffering. This makes msg() now depend on the first call of
  html_msgarea() or headers_sent() in order to not to break msg() in
  ajax requests etc.

The debug log isn't automatically cleaned so don't write to it when
debugging is disabled and thus nobody is aware that debug output might
be generated.