While DokuWiki suppresses PHP Notices they are still a code smell and
should be fixed. This fixes some PHP Notices that occurred.

Some of these fixes could be refactored into nicer code once we move to
PHP 7 and get access to the `??` operator.

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

You really never want to search the whole filesystem, so something must
have gone wrong. Better abort than go on.

many PHPDocs
some unused variables
some dynamically declared variables declared

replace boolean conditional checks on possibly uninitialized vars with \!empty/empty/isset as appropriate

The refshow configuration option wasn't used as described anymore
already in the latest release and after the introduction of the media
usage index the parameter is also no longer relevant for internal
optimization. The only place where it was still used is the no longer
used search_references()-function which is removed here, too.

The refshow configuration option wasn't used as described anymore
already in the latest release and after the introduction of the media
usage index the parameter is also no longer relevant for internal
optimization. The only place where it was still used is the no longer
used search_references()-function which is removed here, too.

This reverts parts of the changes from #154: Before merging the pull
request, a depth of 1 returned just the pages in the root namespace.
With the changes in the pull request, a depth of 1 also returned pages
in subnamespaces of the root namespace (as it was also tested in the test case).
This reverts this part of the changes and a depth of 1 returns just the
pages in the root namespace again.

This reverts parts of the changes from #154: Before merging the pull
request, a depth of 1 returned just the pages in the root namespace.
With the changes in the pull request, a depth of 1 also returned pages
in subnamespaces of the root namespace (as it was also tested in the test case).
This reverts this part of the changes and a depth of 1 returns just the
pages in the root namespace again.

At least if we want to be consistent with search_universal

Otherwise, when we check for equality, the test fails if the search start beneath
the max depth.
Eg: if I have the page ns1:ns2:mypage in my wiki, and launch the xmlrpc query
getPagelist("ns1", "depth => 1"), without this patch, it retrieves mypage

This problem was reported in https://forum.dokuwiki.org/thread/8143.
Apart from warnings you could notice that when you have namespaces "foo"
and "f.o" and you open the sitemap for "foo" that "f.o" is opened, too.

This reverts commit ba6c070e.
This reverts commit 92351008.

This changes the cache logic for metadata. It introduces a new mode that
tries to avoid rendering the page again for simple requests but still
updates the metadata when the page has been changed (but not when the
cache timeout has been reached or purge is used). It simply compares the
time of the last rendering with the last modified time of the page.

The old boolean $render parameter has been changed into an int with
three possible values. Compatibility for the old parameter is provided
using a check with is_numeric using the following mapping:
- false is still don't render (0 is the new value for that)
- true is using that new render logic which means that many plugins will
  still work unchanged even if they request a lot of data using
  $render=true (1 is the new value for that providing full compatibility
  in the case 1 has been used instead of true)

The default value for p_get_first_heading is now that new simple cache
logic, the default value for getting metadata is the cache logic which
should be used with care but is the only way to request (rendered)
metadata that can change because of plugin installations or upgrades.

As of VIM 7.3 it is no longer possible to specify the encoding in the
modeline. This gives an error message whenever such a file is opened,
thus this commit removes the enc setting from the modeline.

The hash option did not hash the correct content for the
found media files. This causes troubles in the sync plugin
http://github.com/splitbrain/dokuwiki-plugin-sync/issues#issue/1