Stop rendering CS modules and room version fragments as standalone pa…

…ges (matrix-org#1317)

This is actually doing two things:

 * creating `{fragments,modules}/index.md` turns the fragments and modules into
   page resources, rather than pages in their own right. We have to update the
   shortcodes to match.

 * adding `headless: true` means that we don't render the pages.

The net effect is that we don't render pages like
https://spec.matrix.org/v1.4/rooms/fragments/v1-auth-rules/ and
https://spec.matrix.org/v1.4/client-server-api/modules/account_data/.

changelogs/internal/newsfragments/1317.clarification

@@ -0,0 +1 @@
+Stop rendering the subsections of the Client-Server API and Room Versions specs as their own separate pages.

content/client-server-api/modules/account_data.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Client Config
 

content/client-server-api/modules/admin.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Server Administration
 

content/client-server-api/modules/content_repo.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Content repository
 

content/client-server-api/modules/device_management.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Device Management
 

content/client-server-api/modules/dm.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Direct Messaging
 

content/client-server-api/modules/end_to_end_encryption.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### End-to-End Encryption
 

content/client-server-api/modules/event_context.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Event Context
 

content/client-server-api/modules/event_replacements.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Event replacements
 

content/client-server-api/modules/guest_access.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Guest Access
 

content/client-server-api/modules/history_visibility.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Room History Visibility
 

content/client-server-api/modules/ignore_users.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Ignoring Users
 

content/client-server-api/modules/index.md

@@ -0,0 +1,3 @@
+---
+headless: true
+---

content/client-server-api/modules/instant_messaging.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Instant Messaging
 

content/client-server-api/modules/mentions.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### User and room mentions
 

content/client-server-api/modules/moderation_policies.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Moderation policy lists
 

content/client-server-api/modules/openid.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### OpenID
 

content/client-server-api/modules/presence.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Presence
 

content/client-server-api/modules/push.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Push Notifications
 

content/client-server-api/modules/read_markers.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Fully read markers
 

content/client-server-api/modules/receipts.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Receipts
 

content/client-server-api/modules/reference_relations.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Reference relations
 

content/client-server-api/modules/report_content.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Reporting Content
 

content/client-server-api/modules/rich_replies.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Rich replies
 

content/client-server-api/modules/room_previews.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Room Previews
 

content/client-server-api/modules/room_upgrades.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Room Upgrades
 

content/client-server-api/modules/search.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Server Side Search
 

content/client-server-api/modules/secrets.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Secrets
 

content/client-server-api/modules/send_to_device.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Send-to-Device messaging
 

content/client-server-api/modules/server_acls.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Server Access Control Lists (ACLs) for rooms
 

content/client-server-api/modules/server_notices.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Server Notices
 

content/client-server-api/modules/spaces.md

@@ -1,7 +1,4 @@
----
-type: module
 weight: 340
----
 
 ### Spaces
 

content/client-server-api/modules/sso_login.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### SSO client login/authentication
 

content/client-server-api/modules/stickers.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Sticker Messages
 

content/client-server-api/modules/tags.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Room Tagging
 

content/client-server-api/modules/third_party_invites.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Third party invites
 

content/client-server-api/modules/third_party_networks.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Third Party Networks
 

content/client-server-api/modules/threading.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Threading
 

content/client-server-api/modules/typing_notifications.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Typing Notifications
 

content/client-server-api/modules/voip_events.md

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Voice over IP
 

content/rooms/fragments/index.md

@@ -0,0 +1,3 @@
+---
+headless: true
+---

content/rooms/fragments/v1-auth-rules.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 The types of state events that affect authorization are:
 

content/rooms/fragments/v1-canonical-json.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Servers MUST NOT strictly enforce the JSON format specified in the
 [appendices](/appendices#canonical-json) for the reasons

content/rooms/fragments/v1-deprecated-formatting-off-spec.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Events sent into rooms of this version can have formats which are different
 from their normal schema. Those cases are documented here.

content/rooms/fragments/v1-redactions.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Upon receipt of a redaction event, the server must strip off any keys
 not in the following list:

content/rooms/fragments/v1-stringy-power-levels.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 ##### `m.room.power_levels` events accept values as strings
 

content/rooms/fragments/v2-state-res.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 The room state *S′(E)* after an event *E* is defined in terms of the
 room state *S(E)* before *E*, and depends on whether *E* is a state

content/rooms/fragments/v3-auth-rules.md

@@ -1,7 +1,5 @@
 ---
-toc_hide: true
 ---
-
 {{< added-in this=true >}} In room versions 1 and 2, events need a
 signature from the domain of the `event_id` in order to be considered
 valid. This room version does not include an `event_id` over federation

content/rooms/fragments/v3-handling-redactions.md

@@ -1,7 +1,5 @@
 ---
-toc_hide: true
 ---
-
 {{% added-in this=true %}} In room versions 1 and 2, redactions were
 explicitly part of the [authorization rules](/rooms/v1/#authorization-rules)
 under Rule 11. As of room version 3, these conditions no longer exist as

content/rooms/fragments/v4-event-format.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Events in rooms of this version have the following structure:
 

content/rooms/fragments/v4-event-ids.md

@@ -1,7 +1,5 @@
 ---
-toc_hide: true
 ---
-
 {{% added-in this=true %}} The event ID is the [reference
 hash](/server-server-api#calculating-the-reference-hash-for-an-event) of
 the event encoded using a variation of [Unpadded

content/rooms/fragments/v5-signing-requirements.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 When validating event signatures, servers MUST enforce the
 `valid_until_ts` property from a key request is at least as large as the

content/rooms/fragments/v6-canonical-json.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Servers MUST strictly enforce the JSON format specified in the
 [appendices](/appendices#canonical-json). This translates to a

content/rooms/fragments/v6-redactions.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Upon receipt of a redaction event, the server must strip off any keys
 not in the following list:

content/rooms/fragments/v8-auth-rules.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Events must be signed by the server denoted by the `sender` property.
 

content/rooms/fragments/v9-redactions.md

@@ -1,5 +1,4 @@
 ---
-toc_hide: true
 ---
 
 {{% added-in this=true %}} `m.room.member` events now keep `join_authorised_via_users_server`