This is useful for anonymously useable forms, like the search.

This also renames the event for the search form on the search page.

The scheme for naming events that provide the new Form-class as $data is
FORM_<formname>_OUTPUT

This way we do not loose the context of the current page. Further, the
new id generated from the query before wasn't really that useful (see
issue #1124 ). And we can still generate a meaningful link "create a
page for your query", if that is considered useful.

Further redirects exist for the old urls, so bookmarked searches etc.
should mostly keep working.

Quick-search positioning and other templates break when removing this
tag.

There are several use cases in which knowing the page where a search
request originated would be useful. This commit adds a `from` parameter
which provides that information.

This makes it easier to read, reason and extend.

This commit fixes a bug in the media manager when viewing an old version
of a media file. While, in case of an image, the old image would be
displayed in the third pane, the link above would still link to the
current version.

The HTML-spec[0] specifies:

> If the element has no label attribute and is not a child of a datalist element: Text that is not inter-element whitespace.

So a non-breaking space is valid solution.

[0] https://html.spec.whatwg.org/multipage/form-elements.html#the-option-element

When a page is marked as hidden (through the hidepages option) it should
not be indexed by search engines.

This function is now deprecated.

Tests even surfaced some smaller bugs :-)

If an entry in the loop at `_tpl_metaheaders_action` has no content, skip this entry.

This is just a quick and dirty hack to try and see if the router
actually behaves as it should. I renamed the old methods to XXX_* and
implemented new ones calling the router. This has to be cleaned up
later.

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

Revert Template changes from css-modifications-branch. No Flavours. If someone wants that, it is easier to be done using a plugin.

Add flavours to template ini files. The template will now be checked for multiple ini files and inserts them as a custom flavours. The css.php can detect these flavours and reads the stylesheet + replacements from there. If the flavour is not the default one (style.ini), replacements are loaded from the default flavour first to ensure that the colours are available. Flavours can define their own set of replacements.

All script tags are now surrounded by conditional comments to tell
Internet Explorer 8 and lower to not even bother trying to load the
JavaScript.

This introduces a new dokuwiki\Ui namespace and refactors the Admin
screen into a Ui class. The ultimate goal is to split up the big,
complex functions in inc\html.php in better maintainable classes in the
Ui namespace. This is the first go at it. Others function->class
conversions should follow.

This also switches the icons for our base admin plugins to inline SVG.
(files and styling not included, yet).

We now have two CDNs available. code.jquery.com which is the more
popular one and CDNjs which is the faster one. Plugin authors can use a
plugin hook to easily implement their own preferred CDN. Authors might
even use this event to conditionally load additional JavaScript files.

jQuery (and UI and Migrate) are now loaded separately from the rest of
the JavaScript. This adds at least one HTTP request more but has some
advantages:

* browsers can cache it independently
* the cache is only invalidated when versions update
* we do not apply any transformations (replacements, minimizing, etc) on
  this code anymore which makes our dispatcher faster for the other JS
* browsers seem to load (not execut) both (jquery and other) parallel,
  which might increase download speed a bit

This split allowed for the introduction of a new config: jquerycdn. When
enabled the 3 jquery files are loaded from jQueries CDN. This adds
another two HTTP requests but:

* since it's another host those files do not apply to the 4 request per
  host limit and can be loaded (not executed) in paralell which might
  increase download speeds a bit
* the CDN is distributed worldwide which means files are requested from
  the closest location, increasing the download speeds
* since these files/CDN are very popular, chances are high that people
  already have them cached in their browsers, reducing the download time
  to 0 and effectiely halving the javascript needed to download

The option currently defaults to 'off', but I would argue 'on' would be
the better default.

@scrutinizer-notifier noticed that the $pageid might be false when
page_findnearest looks for it.

This is needed to accomodate for the change in page_findnearest()

This event handles both known core types and unknown types as default

re-add PR #470 again.