Fix relative links in docs

arcusfelis · arcusfelis · commit d86b9f01a7e7 · 2024-09-12T12:59:18.000+02:00
diff --git a/doc/configuration/configuration-files.md b/doc/configuration/configuration-files.md
@@ -30,7 +30,7 @@ The section names above are links to the detailed documentation of each section.
 !!! Warning
     It is recommended to use the same configuration file for all nodes in the cluster, but there is no protection against using different option values for each node, because it can happen in two cases:
 
-    * During a [rolling upgrade](../../operation-and-maintenance/Rolling-upgrade) procedure, when nodes are restarted one by one with new configuration.
+    * During a [rolling upgrade](../operation-and-maintenance/Rolling-upgrade.md) procedure, when nodes are restarted one by one with new configuration.
     * When you need different network-specific parameters (e.g. listening IP addresses) for each node.
 
 ## vm.args
diff --git a/doc/configuration/general.md b/doc/configuration/general.md
@@ -44,7 +44,7 @@ In order to configure these hosts independently, use the [`host_config` section]
 
 This is the list of names for the types of hosts that will serve dynamic XMPP domains.
 Each host type can be seen as a label for a group of independent domains that use the same server configuration.
-In order to configure these host types independently, use the [`host_config` section](./host_config.md). The domains can be added or removed dynamically with the [command line interface](../../developers-guide/domain_management#command-line-interface) or using the [API](../../developers-guide/domain_management#api).
+In order to configure these host types independently, use the [`host_config` section](./host_config.md). The domains can be added or removed dynamically with the [command line interface](../developers-guide/domain_management.md#command-line-interface) or using the [API](../developers-guide/domain_management.md#api).
 
 If you use the host type mechanism, make sure you only configure modules which support dynamic domains in the [`modules`](./Modules.md) or [`host_config.modules`](./host_config.md#host_configmodules) sections.
 MongooseIM will **not** start otherwise.
@@ -170,7 +170,7 @@ If a stanza is addressed to a subdomain of the served domain and this option is
 * **Default:** `["mongoose_router_global", "mongoose_router_localdomain", "mongoose_router_external_localnode", "mongoose_router_external", "mongoose_router_dynamic_domains", "ejabberd_s2s"]`
 * **Example:** `routing_modules = ["mongoose_router_global", "mongoose_router_localdomain"]`
 
-Provides an ordered list of modules used for routing messages. All available modules are enabled by default, and you can change their order or disable some of them by providing your own list. See the [Message routing](../../developers-guide/Stanza-routing/#3-message-routing) section of the developer's guide for more information.
+Provides an ordered list of modules used for routing messages. All available modules are enabled by default, and you can change their order or disable some of them by providing your own list. See the [Message routing](../developers-guide/Stanza-routing.md#3-message-routing) section of the developer's guide for more information.
 
 ## Miscellaneous
 
diff --git a/doc/developers-guide/Stanza-routing.md b/doc/developers-guide/Stanza-routing.md
@@ -19,7 +19,7 @@ Next, depending on the type of the stanza, one of the following hooks is called:
 * `user_send_iq` for IQ (info/query) stanzas,
 * `user_send_xmlel` for other XML elements.
 
-Each hook can be handled by multiple modules subscribed to it. Those modules do various complementary tasks, like storing the message in an archive, sending carbon copies, checking the stanza against privacy lists etc. It is possible for a handler to immediately stop routing at this point, preventing execution of any subsequent handlers or hooks. See [hooks description](../hooks_description/#hooks-called-for-session_established) for more information.
+Each hook can be handled by multiple modules subscribed to it. Those modules do various complementary tasks, like storing the message in an archive, sending carbon copies, checking the stanza against privacy lists etc. It is possible for a handler to immediately stop routing at this point, preventing execution of any subsequent handlers or hooks. See [hooks description](hooks_description.md#hooks-called-for-session_established) for more information.
 
 ## 3. Message routing
 
@@ -28,7 +28,7 @@ The stanza is routed by `ejabberd_router:route/3`, which passes it through a cha
 1. `Mod:filter/3`, which either drops the stanza, stopping the routing chain, or returns it for further processing, modifying it if necessary.
 2. `Mod:route/3`, which either handles the stanza, stopping the routing chain, or returns it for further processing, modifying it if necessary.
 
-A list of routing modules can be set in the [`routing_modules`](../../configuration/general#generalrouting_modules) option.
+A list of routing modules can be set in the [`routing_modules`](../configuration/general.md#generalrouting_modules) option.
 The default behaviour is the following:
 
 * `mongoose_router_global`: runs a global `filter_packet` hook.
diff --git a/doc/developers-guide/domain_management.md b/doc/developers-guide/domain_management.md
@@ -146,5 +146,5 @@ Run `./mongooseimctl domain` to get more information about all supported operati
 
 You can manage domains with one of our API's:
 
-* The [GraphQL API](../../graphql-api/Admin-GraphQL) has the same funtionality as the command line interface. The <a href="../../graphql-api/admin-graphql-doc.html#query-domain">queries</a> and <a href="../../graphql-api/admin-graphql-doc.html#mutation-domain">mutations</a> for domains are grouped under the `domain` category.
-* The [REST API](../../rest-api/Administration-backend) (deprecated) supports domain management as well. See <a href="../../swagger/index.html#/Dynamic_domains">Dynamic Domains</a> for details.
+* The [GraphQL API](../graphql-api/Admin-GraphQL.md) has the same funtionality as the command line interface. The <a href="../../graphql-api/admin-graphql-doc.html#query-domain">queries</a> and <a href="../../graphql-api/admin-graphql-doc.html#mutation-domain">mutations</a> for domains are grouped under the `domain` category.
+* The [REST API](../rest-api/Administration-backend.md) (deprecated) supports domain management as well. See <a href="../../swagger/index.html#/Dynamic_domains">Dynamic Domains</a> for details.
diff --git a/doc/developers-guide/hooks_description.md b/doc/developers-guide/hooks_description.md
@@ -65,7 +65,7 @@ mongoose_hooks:filter_packet({From, To, Acc, Packet})
 mongoose_hooks:filter_local_packet({From, To, Acc, Packet})
 ```
 
-These hooks are run when the packet is being [routed](../Stanza-routing/#3-message-routing) by `ejaberd_router:route/4`, which is the most general function used to route stanzas across the entire cluster. For example, `mongoose_c2s` calls it after calling the `user_send_message` or `user_send_iq` hook, and multiple modules use it for sending replies and errors.
+These hooks are run when the packet is being [routed](Stanza-routing.md#3-message-routing) by `ejaberd_router:route/4`, which is the most general function used to route stanzas across the entire cluster. For example, `mongoose_c2s` calls it after calling the `user_send_message` or `user_send_iq` hook, and multiple modules use it for sending replies and errors.
 
 * `filter_packet` is run by `mongoose_router_global` for all routed packets. It is called at the start of the routing procedure.
 * `filter_local_packet` is run by `mongoose_local_delivery` when the packet is being routed to a domain hosted by the local server.
diff --git a/doc/developers-guide/xep_tool.md b/doc/developers-guide/xep_tool.md
@@ -90,5 +90,5 @@ make xeplist
 
 ## Examples of generated content
 
-* [Markdown table](../../user-guide/Supported-XEPs/)
+* [Markdown table](../user-guide/Supported-XEPs.md)
 * [DOAP file](https://raw.githubusercontent.com/esl/MongooseDocs/gh-pages/latest/mongooseim.doap)
diff --git a/doc/getting-started/Quick-setup.md b/doc/getting-started/Quick-setup.md
@@ -413,7 +413,7 @@ You know `mongooseimctl`, with basic server management commands such as:
 * `start`, `restart`, `stop`, `status`, `live`, `foreground`
 * `get_loglevel`
 
-Other commands shown above correspond to the [GraphQL Admin API](../../graphql-api/Admin-GraphQL/) operations, and they are grouped into the following categories:
+Other commands shown above correspond to the [GraphQL Admin API](../graphql-api/Admin-GraphQL.md) operations, and they are grouped into the following categories:
 
 * `account` contains `registerUser`, `checkUser`, `listUsers`, `removeUser`
 * `roster` contains `addContact`, `subscription`, `listContacts`, `setMutualSubscription`
diff --git a/doc/migrations/6.0.0_6.1.0.md b/doc/migrations/6.0.0_6.1.0.md
@@ -4,17 +4,17 @@ With the new implementation of the client-to-server (C2S) state machine, `mongoo
 
 * The `zlib` option for supporting [stream compression](https://xmpp.org/extensions/xep-0138.html), which was present in the default configuration file, is removed, and **you need to delete it** from your listener configuration unless you have already done so. The extension is [obsolete due to security vulnerability](https://xmpp.org/extensions/xep-0138.html#revision-history-v2.1), and the [CRIME](https://en.wikipedia.org/wiki/CRIME) vulnerability has been found [a long time ago](https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/).
 * Support for [`listen.http.handlers.mod_websockets.service`] has been removed, the component connection over WebSockets did not correspond to any XEP/RFC, and neither it was properly described anywhere in the MIM documentation. It was present in the default configuration file, and **you need to delete it** from your listener configuration unless you have already done so.
-* The `max_fsm_queue` option is no longer supported for C2S listeners. It is incompatible with the new `gen_statem` state machine, and if you need to limit incoming traffic, you should use [traffic shapers](../../configuration/shaper) instead. You need to remove this option from your C2S configuration if you are using it.
+* The `max_fsm_queue` option is no longer supported for C2S listeners. It is incompatible with the new `gen_statem` state machine, and if you need to limit incoming traffic, you should use [traffic shapers](../configuration/shaper.md) instead. You need to remove this option from your C2S configuration if you are using it.
 * The default value of the [`backlog`](../configuration/listen.md#listenbacklog) option for all XMPP listeners has been increased from 100 to 1024 for performance reasons.
 * You might be interested in the new C2S listener options: [`max_connections`](../listeners/listen-c2s.md#listenc2smax_connections), [`c2s_state_timeout`](../listeners/listen-c2s.md#listenc2sstate_timeout), [`reuse_port`](../listeners/listen-c2s.md#listenc2sreuse_port) and [`backwards_compatible_session`](../listeners/listen-c2s.md#listenc2sbackwards_compatible_session). The first two options can be set for [websockets](../listeners/listen-http.md#handler-types-websockets-mod_websockets) as well.
 
 ## Module configuration
 
 The `mongoose_c2s` module, which provides the core XMPP features, is now separated from modules which used to have their parts hardcoded into the old C2S implementation:
 
-* Presence handling has been exported to a separate module [`mod_presence`](../../modules/mod_presence), which is enabled in the default configuration file. **Enable `mod_presence` in your configuration file** unless you are sure that you don't need server-side presence handling, in which case you could gain some performance by not using this module.
-* Stream management is now handled completely by [`mod_stream_management`](../../modules/mod_stream_management), and if you don't need it, you can now gain more performance than before by disabling it.
-* Client state indication is now handled completely by [`mod_csi`](../../modules/mod_csi), and if you don't need it, you can now gain more performance than before by disabling it.
+* Presence handling has been exported to a separate module [`mod_presence`](../modules/mod_presence.md), which is enabled in the default configuration file. **Enable `mod_presence` in your configuration file** unless you are sure that you don't need server-side presence handling, in which case you could gain some performance by not using this module.
+* Stream management is now handled completely by [`mod_stream_management`](../modules/mod_stream_management.md), and if you don't need it, you can now gain more performance than before by disabling it.
+* Client state indication is now handled completely by [`mod_csi`](../modules/mod_csi.md), and if you don't need it, you can now gain more performance than before by disabling it.
 
 ## Database migration
 
@@ -30,26 +30,26 @@ Since we don't know whether a compressed/encrypted packet contains a single stan
     * `global.data.xmpp.received.encrypted_size` - impractical, has no value but consumes calculation resources.
     * `global.data.xmpp.sent.encrypted_size` - impractical, has no value but consumes calculation resources.
 
-A set of `global.data.xmpp.received.**` and `global.data.xmpp.sent.**` spiral [data metrics](../../operation-and-maintenance/MongooseIM-metrics#data-metrics) has been introduced instead.
+A set of `global.data.xmpp.received.**` and `global.data.xmpp.sent.**` spiral [data metrics](../operation-and-maintenance/MongooseIM-metrics.md#data-metrics) has been introduced instead.
 
 ## Hooks
 
-Multiple hooks have been added, removed or changed because of the introduction of `mongoose_c2s` - the most important change is the increased granularity of the `user_send_*` and `user_receive_*` hooks. If you have some custom modules (e.g. that implement some XMPP extensions) using the hooks mechanism, please refactor your handlers to be compliant with the new hooks. Refer to [Hooks Description](../../developers-guide/hooks_description) and [Message routing](../../developers-guide/Stanza-routing) for more details.
+Multiple hooks have been added, removed or changed because of the introduction of `mongoose_c2s` - the most important change is the increased granularity of the `user_send_*` and `user_receive_*` hooks. If you have some custom modules (e.g. that implement some XMPP extensions) using the hooks mechanism, please refactor your handlers to be compliant with the new hooks. Refer to [Hooks Description](../developers-guide/hooks_description.md) and [Message routing](../developers-guide/Stanza-routing.md) for more details.
 
 ## Upgrade procedure
 
-As long as you are not using Mnesia for persistent storage (it is not recommended to do so), the safest option would be to prepare a new cluster with version 6.1.0, and switch the traffic to it on a load balancer. The only downside is that clients connected to different clusters would see each other as offline. If you are limited to one cluster, it is recommended to do a split-cluster rolling upgrade by [removing](../../operation-and-maintenance/Cluster-configuration-and-node-management/#leaving-cluster) each node from the cluster before stopping and upgrading it, and gradually forming a **new separate cluster** from the upgraded nodes. This means that for each newly started node except the first one, you should [join](../../operation-and-maintenance/Cluster-configuration-and-node-management/#new-node-joining-cluster) one of the previously started nodes.
+As long as you are not using Mnesia for persistent storage (it is not recommended to do so), the safest option would be to prepare a new cluster with version 6.1.0, and switch the traffic to it on a load balancer. The only downside is that clients connected to different clusters would see each other as offline. If you are limited to one cluster, it is recommended to do a split-cluster rolling upgrade by [removing](../operation-and-maintenance/Cluster-configuration-and-node-management.md#leaving-cluster) each node from the cluster before stopping and upgrading it, and gradually forming a **new separate cluster** from the upgraded nodes. This means that for each newly started node except the first one, you should [join](../operation-and-maintenance/Cluster-configuration-and-node-management.md#new-node-joining-cluster) one of the previously started nodes.
 
 ### Rolling upgrade issues
 
-If you want to perform a typical [rolling upgrade](../../operation-and-maintenance/Rolling-upgrade) instead, there are a few potential issues caused by the introduction of `mongoose_c2s`. When a node is stopped, upgraded and started again, it reconnects to the cluster. When a stanza is routed between users connected to different nodes of the cluster, an internal message is sent between the nodes. In version 6.1.0 that message has a different format, and routing a stanza between nodes with versions 6.0.0 and 6.1.0 would fail, resulting in a warning message for each stanza. This means that after upgrading the first node you might get a huge amount of warning messages on all nodes, causing a performance drop. What is more, the sender's node would still assume that the recipient is online, and some actions (e.g. responding with the `service-unavailable` error) would be omitted.
+If you want to perform a typical [rolling upgrade](../operation-and-maintenance/Rolling-upgrade.md) instead, there are a few potential issues caused by the introduction of `mongoose_c2s`. When a node is stopped, upgraded and started again, it reconnects to the cluster. When a stanza is routed between users connected to different nodes of the cluster, an internal message is sent between the nodes. In version 6.1.0 that message has a different format, and routing a stanza between nodes with versions 6.0.0 and 6.1.0 would fail, resulting in a warning message for each stanza. This means that after upgrading the first node you might get a huge amount of warning messages on all nodes, causing a performance drop. What is more, the sender's node would still assume that the recipient is online, and some actions (e.g. responding with the `service-unavailable` error) would be omitted.
 
 !!! Info "Changing the log level"
     You can set the log level to `error` during the upgrade to silence the excess warnings.
     Before the upgrade, set the log level on all nodes:
     ```bash
     mongooseimctl server setLoglevel --level ERROR
     ```
-    Before starting the upgraded node, set the [`loglevel`](../../configuration/general/#generalloglevel) option to `error` in the configuration file.
+    Before starting the upgraded node, set the [`loglevel`](../configuration/general.md#generalloglevel) option to `error` in the configuration file.
     After the whole upgrade procedure, use `mongooseimctl` to change the log level back to the previous value (`warning` by default).
     Change the values in the configuration files as well to make the setting permanent.
diff --git a/doc/modules/mod_inbox.md b/doc/modules/mod_inbox.md
@@ -32,7 +32,7 @@ A list of supported inbox boxes by the server. This can be used by clients to cl
 !!! note
     `inbox`, `archive`, and `bin` are reserved box names and are always enabled, therefore they don't need to –and must not– be specified in this section. `all` has a special meaning in the box query and therefore is also not allowed as a box name.
 
-    If the asynchronous backend is configured, automatic removals become moves to the `bin` box, also called "Trash bin". This is to ensure eventual consistency. Then the bin can be emptied, either on a [user request](../open-extensions/inbox.md#examples-emptying-the-trash-bin), with the `mongooseimctl inbox` command, through the [GraphQL API](../../graphql-api/Admin-GraphQL), or through the [REST API](../../rest-api/Administration-backend).
+    If the asynchronous backend is configured, automatic removals become moves to the `bin` box, also called "Trash bin". This is to ensure eventual consistency. Then the bin can be emptied, either on a [user request](../open-extensions/inbox.md#examples-emptying-the-trash-bin), with the `mongooseimctl inbox` command, through the [GraphQL API](../graphql-api/Admin-GraphQL.md), or through the [REST API](../rest-api/Administration-backend.md).
 
 #### `modules.mod_inbox.bin_ttl`
 * **Syntax:** non-negative integer, expressed in days.
diff --git a/doc/tutorials/ICE_tutorial.md b/doc/tutorials/ICE_tutorial.md
@@ -60,7 +60,7 @@ In order to enable signalling we need an instance of [MongooseIM] running with t
 ### Configuration
 
 You can find MongooseIM installation instructions on [this page](../getting-started/Quick-setup.md).
-Once you have it installed, you need to modify the [`mongooseim.toml`](../../configuration/configuration-files/#mongooseimtoml) config file:
+Once you have it installed, you need to modify the [`mongooseim.toml`](../configuration/configuration-files.md#mongooseimtoml) config file:
 ```toml
 [general]
   hosts = ["localhost", "myxmpp.com"]
