Fix Markdown pages wrt. linking

All labels need to be unique globally, so that we can reference them.

Author: cmb69

cmsimple/classes/CSRFProtection.php

@@ -9,7 +9,7 @@
  * @copyright 2013-2021 The CMSimple_XH developers <http://cmsimple-xh.org/?The_Team>
  * @copyright GNU GPLv3 <http://www.gnu.org/licenses/gpl-3.0.en.html>
  * @since     1.6
- * @tutorial  XH/CSRFProtection.cls
+ * @see       @ref csrf
  */
 class CSRFProtection
 {

cmsimple/cms.php

@@ -874,7 +874,7 @@
  *
  * @public
  *
- * @tutorial CSRFProtection.cls
+ * @see @ref csrf
  */
 $_XH_csrfProtection = null;
 if (isset($_COOKIE['status']) && $_COOKIE['status'] == 'adm'

tutorials/XH/CSRFProtection.md

@@ -1,8 +1,6 @@
-CSRF Protection
+CSRF Protection {#csrf}
 ===============
 
-[TOC]
-
 According to [Wikipedia](http://en.wikipedia.org/wiki/Cross-site_request_forgery):
 > CSRF (Cross-site request forgery) is a type of malicious exploit
 > of a website whereby unauthorized commands are transmitted from a user
@@ -28,8 +26,8 @@ For now, the CSRF protection functionality is made available as a
 global object, @ref $_XH_csrfProtection; this is
 quite likely to change in a future version.
 
-Usage {#usage}
-=====
+Usage {#csrf_usage}
+-----
 
 Every form which has to be protected against CSRF attacks has to
 be extended by a hidden input element which can be inserted by calling
@@ -69,8 +67,8 @@ CMSimple_XH and the administration forms of plugins, which are handled
 by `plugin_admin_common()`. Other forms
 require to add CSRF protection in the way described above.
 
-Stronger Protection {#stronger-protection}
-===================
+Stronger Protection {#csrf_stronger_protection}
+-------------------
 
 While a common token for each session gives reasonable protection
 againgst CSRF attacks, a new token for each request is even more secure.
@@ -104,8 +102,8 @@ if (!isset($_POST[...])) {
 }
 ````
 
-External Scripts {#external-scripts}
-================
+External Scripts {#csrf_external_scripts}
+----------------
 
 Sometimes a plugin requests an "external" script, i.e. does
 not request an index.php of the CMSimple_XH installation. In this

tutorials/XH/FileEdit.md

@@ -1,24 +1,19 @@
-The FileEdit Class Hierarchy
+The FileEdit Class Hierarchy {#file_editor}
 ============================
 
-[TOC]
-
-Introduction {#intro}
-=====================
-
 The FileEdit class hierarchie is responsible for the handling of the
 editing of files in the back-end. Its implementation makes heavy use
 of the [template method pattern](http://en.wikipedia.org/wiki/Template_method_pattern).
 The two main branches are TextFileEdit and ArrayFileEdit.
 
-TextFileEdit {#textfileedit}
-----------------------------
+TextFileEdit {#file_editor_text}
+------------
 
 The predefined concrete subclasses of TextFileEdit offer a
 simple textarea to edit the content of a text file.
 
-ArrayFileEdit {#arrayfileedit}
-------------------------------
+ArrayFileEdit {#file_editor_array}
+-------------
 
 This branch offers editing of files storing data in an array
 structure. The predefined subclasses handle two- dimensional PHP
@@ -42,8 +37,8 @@ As of CMSimple_XH 1.7.0 it is also possible to mark configuration as advanced
 options by prepending a `+`, for instance `+bool` or `+string`. Such options are
 only displayed if the user presses the `More …` button in the configuration.
 
-Usage {#usage}
-==============
+Usage {#file_editor_usage}
+-----
 
 To display the edit form XH::FileEdit::form() has to be called; to handle the
 form submission XH::FileEdit::submit() has to be called. For instance:

tutorials/XH/JavaScript.md

@@ -1,6 +1,5 @@
-# JavaScript
-
-[TOC]
+JavaScript {#javascript}
+==========
 
 CMSimple_XH is mainly developed in PHP. To improve the user
 experience browser-side scripting is necessary; this is done
@@ -9,7 +8,8 @@ no precompiled language such as CoffeeScript or TypeScript is used).
 This is documented in the separate
 [JavaScript Documentation](../js/index.html).
 
-# jQuery {#jquery}
+jQuery {#javascript_jquery}
+------
 
 Due to the fact that several major JavaScript frameworks may not be
 compatible with each other and the popularity of

tutorials/XH/XH.md

@@ -1,23 +1,22 @@
-# Developer Documentation for CMSimple_XH
-
-[TOC]
-
-# Introduction {#intro}
+Developer Documentation for CMSimple_XH {#mainpage}
+=======================================
 
 This documentation is meant for core and plugin developers as well
 as template designers. It documents the core and the standard
 plugins which are not developed externally (currently Filebrowser,
 Meta_tags and Page_params).
 
-# System Architecture {#architecture}
+System Architecture {#mainpage_architecture}
+-------------------
 
 All requests to the website are directed to index.php in the root
 folder of the installation or to index.php in a language folder.
 These index.php files are just thin wrappers for including
 {@link cms.php} which defines variables and constants and
 includes necessary files according to the individual request.
 
-## Plugins {#plugins}
+Plugins {#mainpage_plugins}
+-------
 
 Plugins are handled by the "plugin loader". This term stems from
 the past, where it was an external component that had to be
@@ -47,7 +46,8 @@ register an appropriate callback.
 More developer information about plugins can be found in the
 [Wiki](http://www.cmsimple-xh.org/wiki/doku.php/developers_manual).
 
-## Templates {#templates}
+Templates {#mainpage_templates}
+---------
 
 At the end of usual page requests the file template.htm of the
 active template is included. That is an HTML file with embedded
@@ -57,7 +57,8 @@ PHP, the so-called template tags, which are defined in
 More developer information about templates can be found in the
 [Wiki](http://www.cmsimple-xh.org/wiki/doku.php/developers_manual).
 
-# API {#api}
+API {#mainpage_api}
+---
 
 An important part of the API of CMSimple_XH consists of global
 variables which are documented in {@link cms.php}. Not all global

tutorials/XH/autoloading.md

@@ -1,8 +1,6 @@
-Class Autoloading
+Class Autoloading {#autoloading}
 =================
 
-[TOC]
-
 As of CMSimple_XH 1.7.0 the core uses [class
 autoloading](http://php.net/manual/en/language.oop5.autoload.php), and the
 autoloader (`XH_autoload()`) can also be used by plugins. It works very similar
@@ -11,8 +9,8 @@ to better suite the tradionational folder structure of CMSimple_XH, namely that
 the `<Vendor Name>` has actually to be the `<Plugin Name>` (or `XH` in case of
 core classes), which maps to the `classes/` folder of the plugin.
 
-Example {#example}
-==================
+Example {#autoloading_example}
+-------
 
 Let's consider a fictious plugin named Foo with the following filesystem
 structure (irrelevant files and folders ommitted for brevity):
@@ -30,8 +28,8 @@ classes you can use the fully qualified class name, i.e. `\Foo\Bar\Baz` and
 `\Foo\Qux`, respectively, or any short form which resolves to these fully
 qualified class names.
 
-Underscores in Namespaces and Class Names {#underscores}
-========================================================
+Underscores in Namespaces and Class Names {#autoloading_underscores}
+-----------------------------------------
 
 Note that the class loader also supports old style pseudo namespacing with
 underscores (`_`), which are treated identical to proper namespace separators,
@@ -41,8 +39,8 @@ This is meant for backward compatibility purposes, most notably for core classes
 which didn't use namespaces in CMSimple_XH 1.6. For new developments proper
 namespacing is recommended.
 
-Case {#case}
-============
+Case {#autoloading_case}
+----
 
 To avoid issues regarding the case (in)sensitivity of different file systems,
 you have to write all class names exactly like the name of the file they're