Update content to call the new template for event definitions

content/client-server-api/_index.md

@@ -1111,7 +1111,7 @@ which has no `m.identity_server` account data event should not end up
 with the client's default identity server in their account data, unless
 the user first visits their account settings to set the identity server.
 
-{{m\_identity\_server\_event}}
+{{% event event="m.identity_server" %}}
 
 ## Capabilities negotiation
 
@@ -1385,14 +1385,12 @@ available room versions.
 
 Room events are split into two categories:
 
-State Events  
-These are events which update the metadata state of the room (e.g. room
+* **State events**: These are events which update the metadata state of the room (e.g. room
 topic, room membership etc). State is keyed by a tuple of event `type`
 and a `state_key`. State in the room with the same key-tuple will be
 overwritten.
 
-Message events  
-These are events which describe transient "once-off" activity in a room:
+* **Message events**: These are events which describe transient "once-off" activity in a room:
 typically communication such as sending an instant message or setting up
 a VoIP call.
 
@@ -1416,11 +1414,15 @@ assuming the client has access to the `com.example` namespace.
 Note that the structure of these events may be different than those in
 the server-server API.
 
-{{common\_event\_fields}}
+#### Event fields
 
-{{common\_room\_event\_fields}}
+{{% event-fields event_type="event" %}}
 
-#### State Event Fields
+#### Room event fields
+
+{{% event-fields event_type="room_event" %}}
+
+#### State event fields
 
 In addition to the fields of a Room Event, State Events have the
 following fields.
@@ -1460,15 +1462,15 @@ This section is a work in progress.
 This specification outlines several standard event types, all of which
 are prefixed with `m.`
 
-{{m\_room\_canonical\_alias\_event}}
+{{% event event="m.room.canonical_alias" %}}
 
-{{m\_room\_create\_event}}
+{{% event event="m.room.create" %}}
 
-{{m\_room\_join\_rules\_event}}
+{{% event event="m.room.join_rules" %}}
 
-{{m\_room\_member\_event}}
+{{% event event="m.room.member" %}}
 
-{{m\_room\_power\_levels\_event}}
+{{% event event="m.room.power_levels" %}}
 
 #### Historical events
 
@@ -1682,7 +1684,7 @@ the topic to be removed from the room.
 
 #### Events
 
-{{m\_room\_redaction\_event}}
+{{% event event="m.room.redaction" %}}
 
 #### Client behaviour
 

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

@@ -19,7 +19,7 @@ whether a chat is 'direct' to an invitee.
 
 #### Events
 
-{{m\_direct\_event}}
+{{% event event="m.direct" %}}
 
 #### Client behaviour
 

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

@@ -466,11 +466,11 @@ process.
 
 After the handshake, the verification process begins.
 
-{{m\_key\_verification\_request\_event}}
+{{% event event="m.key.verification.request" %}}
 
-{{m\_key\_verification\_start\_event}}
+{{% event event="m.key.verification.start" %}}
 
-{{m\_key\_verification\_cancel\_event}}
+{{% event event="m.key.verification.cancel" %}}
 
 ##### Short Authentication String (SAS) verification
 
@@ -634,13 +634,13 @@ following error codes are used in addition to those already specified:
 -   `m.mismatched_commitment`: The hash commitment did not match.
 -   `m.mismatched_sas`: The SAS did not match.
 
-{{m\_key\_verification\_start\_m\_sas\_v1\_event}}
+{{% event event="m.key.verification.start$m.sas.v1" %}}
 
-{{m\_key\_verification\_accept\_event}}
+{{% event event="m.key.verification.accept" %}}
 
-{{m\_key\_verification\_key\_event}}
+{{% event event="m.key.verification.key" %}}
 
-{{m\_key\_verification\_mac\_event}}
+{{% event event="m.key.verification.mac" %}}
 
 ###### HKDF calculation
 
@@ -1355,17 +1355,17 @@ messages.
 
 ##### Events
 
-{{m\_room\_encryption\_event}}
+{{% event event="m.room.encryption" %}}
 
-{{m\_room\_encrypted\_event}}
+{{% event event="m.room.encrypted" %}}
 
-{{m\_room\_key\_event}}
+{{% event event="m.room_key" %}}
 
-{{m\_room\_key\_request\_event}}
+{{% event event="m.room_key_request" %}}
 
-{{m\_forwarded\_room\_key\_event}}
+{{% event event="m.room_key" %}}
 
-{{m\_dummy\_event}}
+{{% event event="m.dummy" %}}
 
 ##### Key management API
 
@@ -1451,4 +1451,4 @@ by including a `withheld` property in the `m.forwarded_room_key` message
 that is an object with the `code` and `reason` properties from the
 `m.room_key.withheld` message.
 
-{{m\_room\_key\_withheld\_event}}
+{{% event event="m.room_key.withheld" %}}

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

@@ -32,7 +32,7 @@ rather than allowing all homeservers to enforce the rules on each other.
 
 #### Events
 
-{{m\_room\_guest\_access\_event}}
+{{% event event="m.room.guest_access" %}}
 
 #### Client behaviour
 

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

@@ -43,7 +43,7 @@ setting at that time was more restrictive.
 
 #### Events
 
-{{m\_room\_history\_visibility\_event}}
+{{% event event="m.room.history_visibility" %}}
 
 #### Client behaviour
 

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

@@ -11,7 +11,7 @@ and servers can implement the ignoring of users.
 
 #### Events
 
-{{m\_ignored\_user\_list\_event}}
+{{% event event="m.ignored_user_list" %}}
 
 #### Client behaviour
 

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

@@ -11,9 +11,9 @@ room itself such as a room name and topic.
 
 #### Events
 
-{{m\_room\_message\_event}}
+{{% event event="m.room.message" %}}
 
-{{m\_room\_message\_feedback\_event}}
+{{% event event="m.room.message.feedback" %}}
 
 Usage of this event is discouraged for several reasons:  
 -   The number of feedback events will grow very quickly with the number
@@ -24,13 +24,13 @@ Usage of this event is discouraged for several reasons:
 -   There are no guarantees that the client has seen the event ID being
     acknowledged.
 
-{{m\_room\_name\_event}}
+{{% event event="m.room.name" %}}
 
-{{m\_room\_topic\_event}}
+{{% event event="m.room.topic" %}}
 
-{{m\_room\_avatar\_event}}
+{{% event event="m.room.avatar" %}}
 
-{{m\_room\_pinned\_events\_event}}
+{{% event event="m.room.pinned_events" %}}
 
 ##### m.room.message msgtypes
 
@@ -116,7 +116,7 @@ extensible message formatting options, such as the proposal
 [MSC1767](https://github.com/matrix-org/matrix-doc/pull/1767).
 {{% /boxes/note %}}
 
-{{msgtype\_events}}
+{{% msgtypes %}}
 
 #### Client behaviour
 

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

@@ -97,11 +97,11 @@ rules against rooms can describe a room ID or room alias - the
 subscriber is responsible for resolving the alias to a room ID if
 desired.
 
-{{m\_policy\_rule\_user\_event}}
+{{% event event="m.policy.rule.user" %}}
 
-{{m\_policy\_rule\_room\_event}}
+{{% event event="m.policy.rule.room" %}}
 
-{{m\_policy\_rule\_server\_event}}
+{{% event event="m.policy.rule.server" %}}
 
 #### Client behaviour
 

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

@@ -30,7 +30,7 @@ enum of one of the following:
 
 #### Events
 
-{{presence\_events}}
+{{% event-group group_name="m.presence" %}}
 
 #### Client behaviour
 

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

@@ -666,7 +666,7 @@ When a user changes their push rules a `m.push_rules` event is sent to
 all clients in the `account_data` section of their next `/sync` request.
 The content of the event is the current push rules for the user.
 
-{{m\_push\_rules\_event}}
+{{% event event="m.push_rules" %}}
 
 ###### Examples
 

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

@@ -24,7 +24,7 @@ The fully read marker is kept under an `m.fully_read` event. If the
 event does not exist on the user's account data, the fully read marker
 should be considered to be the user's read receipt location.
 
-{{m\_fully\_read\_event}}
+{{% event event="m.fully_read" %}}
 
 #### Client behaviour
 

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

@@ -24,7 +24,7 @@ information on how read receipts affect notification counts.
 Each `user_id`, `receipt_type` pair must be associated with only a
 single `event_id`.
 
-{{m\_receipt\_event}}
+{{% event event="m.receipt" %}}
 
 #### Client behaviour
 

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

@@ -11,7 +11,7 @@ to upgrade to a different room version when needed.
 
 #### Events
 
-{{m\_room\_tombstone\_event}}
+{{% event event="m.room.tombstone" %}}
 
 #### Client behaviour
 

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

@@ -16,7 +16,7 @@ set of servers, or retroactively make the room no longer federate with
 any other server, similar to setting the `m.federate` value on the
 [m.room.create](#mroomcreate) event.
 
-{{m\_room\_server\_acl\_event}}
+{{% event event="m.room.server_acl" %}}
 
 {{% boxes/note %}}
 Port numbers are not supported because it is unclear to parsers whether

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

@@ -36,7 +36,7 @@ maximum. New connections are being refused by the server. What defines
 "active" is left as an implementation detail, however servers are
 encouraged to treat syncing users as "active".
 
-{{m\_room\_message\_m\_server\_notice\_event}}
+{{% event event="m.room.message$m.server_notice" %}}
 
 #### Client behaviour
 

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

@@ -22,7 +22,7 @@ when the sticker image is clicked.
 Sticker events are received as a single `m.sticker` event in the
 `timeline` section of a room, in a `/sync`.
 
-{{m\_sticker\_event}}
+{{% event event="m.sticker" %}}
 
 #### Client behaviour
 

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

@@ -59,7 +59,7 @@ tags are defined in the `m.*` namespace:
 -   `m.server_notice`: Used to identify [Server Notice
     Rooms](#server-notices).
 
-{{m\_tag\_event}}
+{{% event event="m.tag" %}}
 
 #### Client Behaviour
 

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

@@ -31,7 +31,7 @@ invitee does indeed own that third party identifier. See the
 
 #### Events
 
-{{m\_room\_third\_party\_invite\_event}}
+{{% event event="m.room.third_party_invite" %}}
 
 #### Client behaviour
 

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

@@ -12,7 +12,7 @@ events scoped to a `room_id`. This means they do not form part of the
 
 #### Events
 
-{{m\_typing\_event}}
+{{% event event="m.typing" %}}
 
 #### Client behaviour
 

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

@@ -15,7 +15,7 @@ send call events to rooms with exactly two participants.
 
 #### Events
 
-{{voip\_events}}
+{{% event-group group_name="m.call" %}}
 
 #### Client behaviour
 

content/identity-service-api.md

@@ -196,7 +196,7 @@ the client should not expect that the server will not respond with
 another `M_TERMS_NOT_SIGNED` on their next request. The terms the user
 has just accepted are appended to `m.accepted_terms`.
 
-{{m\_accepted\_terms\_event}}
+{{% event event="m.accepted_terms" %}}
 
 {{% http-api spec="identity" api="v2_terms" %}}
 

content/rooms/v1.md

@@ -276,7 +276,7 @@ Some consequences of these rules:
 
 Events in version 1 rooms have the following structure:
 
-{{definition\_ss\_pdu}}
+{{% definition path="api/server-server/definitions/pdu" %}}
 
 ### Canonical JSON
 

content/rooms/v3.md

@@ -60,7 +60,7 @@ Additionally, the `auth_events` and `prev_events` have had a format
 change compared to other room versions to make it easier to handle.
 Instead of a tuple of values, they are now plain lists of events.
 
-{{definition\_ss\_pdu\_v3}}
+{{% definition path="api/server-server/definitions/pdu_v3" %}}
 
 ### Changes to APIs
 

content/rooms/v4.md

@@ -58,4 +58,4 @@ receiving end of an event, the server should compute the relevant event
 ID for itself. Room version 3 also changes the format of `auth_events`
 and `prev_events` in a PDU.
 
-{{definition\_ss\_pdu\_v4}}
+{{% definition path="api/server-server/definitions/pdu_v4" %}}

content/server-server-api.md

@@ -567,7 +567,7 @@ EDUs, by comparison to PDUs, do not have an ID, a room ID, or a list of
 "previous" IDs. They are intended to be non-persistent data such as user
 presence, typing notifications, etc.
 
-{{definition\_ss\_edu}}
+{{% definition path="api/server-server/definitions/edu" %}}
 
 ## Room State Resolution
 
@@ -850,7 +850,7 @@ need to be sent to other servers in the room so their users are aware of
 the same state. Receiving servers should verify that the user is in the
 room, and is a user belonging to the sending server.
 
-{{definition\_ss\_event\_schemas\_m\_typing}}
+{{% definition path="api/server-server/definitions/event-schemas/m.typing" %}}
 
 ## Presence
 
@@ -861,7 +861,7 @@ Servers should only send presence updates for users that the receiving
 server would be interested in. Such as the receiving server sharing a
 room with a given user.
 
-{{definition\_ss\_event\_schemas\_m\_presence}}
+{{% definition path="api/server-server/definitions/event-schemas/m.presence" %}}
 
 ## Receipts
 
@@ -872,7 +872,7 @@ where in the event graph the user has read up to.
 Read receipts for events that a user sent do not need to be sent. It is
 implied that by sending the event the user has read up to the event.
 
-{{definition\_ss\_event\_schemas\_m\_receipt}}
+{{% definition path="api/server-server/definitions/event-schemas/m.receipt" %}}
 
 ## Querying for information
 
@@ -945,7 +945,7 @@ recognise, it must resynchronise its list by calling the
 
 {{% http-api spec="server-server" api="user_devices" %}}
 
-{{definition\_ss\_event\_schemas\_m\_device\_list\_update}}
+{{% definition path="api/server-server/definitions/event-schemas/m.device_list_update" %}}
 
 ## End-to-End Encryption
 
@@ -960,7 +960,7 @@ proxied through to the client.
 
 {{% http-api spec="server-server" api="user_keys" %}}
 
-{{definition\_ss\_event\_schemas\_m\_signing\_key\_update}}
+{{% definition path="api/server-server/definitions/event-schemas/m.signing_key_update" %}}
 
 ## Send-to-device messaging
 
@@ -971,7 +971,7 @@ involved.
 Each send-to-device message should be sent to the destination server
 using the following EDU:
 
-{{definition\_ss\_event\_schemas\_m\_direct\_to\_device}}
+{{% definition path="api/server-server/definitions/event-schemas/m.direct_to_device" %}}
 
 ## Content Repository