Fix missing headings everywhere

src/routes/docs/advanced/platform/permissions/+page.markdoc

@@ -63,7 +63,7 @@ The examples below will show you how you can use the different Appwrite permissi
 
 The following examples are using the [Appwrite Web SDK](https://github.com/appwrite/sdk-for-web) but can be applied similarly to any of the other [Appwrite SDKs](/docs/sdks).
 
-## Example #1 - Basic usage
+## Example 1 - Basic usage {% #example-1 %}
 
 In the following example, we are creating a document that can be read by anyone, edited by writers or admins, and deleted by administrators or a user with the user ID `user:5c1f88b42259e`.
 
@@ -96,7 +96,7 @@ promise.then(function (response) {
 });
 ```
 
-## Example #2 - Team roles
+## Example 2 - Team roles  {% #example-2 %}
 
 In the following example, we are creating a document that can be read by members of the team with ID `5c1f88b87435e` and can only be edited or deleted by members of the same team that possess the team role `owner`.
 

src/routes/docs/advanced/self-hosting/tls-certificates/+page.markdoc

@@ -11,21 +11,21 @@ Appwrite uses Let's Encrypt to auto-generate TLS certificates for your Appwrite
 3. You need to ensure you have a valid email address set on `_APP_SYSTEM_SECURITY_EMAIL_ADDRESS`. The default setup comes with `certs@appwrite.io` as the default value. While this address will work, it's recommended to change it to your own email.
 4. Currently, Appwrite is using the [ACME](https://letsencrypt.org/docs/client-options/) HTTP challenge to issue an TLS certificate. This forces us to generate certificates for port 443 when the challenge itself is performed on port 80. At this point, other ports will not work. To overcome this limit, you can set Appwrite on a separate sub-domain or use your own certificate or proxy server in front of Appwrite.
 
-# Debugging
+# Debugging  {% #debugging %}
 
 If you're still struggling with your certificates, check the Appwrite certificates worker log. You can do that with the following command:
 
 ```bash
 docker compose logs appwrite-worker-certificates
 ```
 
-# Generation cycle
+# Generation cycle {% #generation-cycle %}
 
 Appwrite auto-generates a certificate for your main domain when you first visit it. If your browser shows an insecure connection warning, you must proceed to trigger certificate generation. The domain in environment variable `_APP_DOMAIN` is considered your main domain. If you didn't set this variable, the first domain you visit would be marked as the main domain for your Appwrite instance. Appwrite follows this concept of the main domain to prevent generating certificates for domains you don't own. Keep in mind that you can always add additional domains as **Custom Domains** in your project settings to enable certificate generation for any domain.
 
 Certificate renewal is done as a part of the Appwrite maintenance task. Unless modified with environment variable `_APP_MAINTENANCE_INTERVAL`, this task runs every 24 hours. During this task, Appwrite looks for certificates due for renewal and renews them. One maintenance cycle only attempts to renew up to 200 certificates to respect the Let's Encrypt API limit. Every Let's Encrypt certificate is valid for 90 days, but Appwrite starts to renew them 30 days before the expiration.
 
-# Manual generation
+# Manual generation  {% #manual-generation %}
 
 Since Appwrite generates and renews certificates automatically, a manual generation is seldom required. A manual generation can be useful when you hit the API limit and don't want to wait for the next maintenance cycle to renew the certificate. Use the following command to generate a certificate for your main domain:
 
@@ -39,7 +39,7 @@ If you want to generate a certificate for a specific domain, pass it as a parame
 docker compose exec appwrite ssl domain="api.myapp.com"
 ```
 
-# Development environment and localhost
+# Development and localhost {% #development %}
 
 You can't issue a [signed certificate for localhost](https://letsencrypt.org/docs/certificates-for-localhost/). This is because nobody uniquely owns that hostname and not an Appwrite specific limitation, just the way the internet works. By default, Appwrite will issue a self-signed certificate that is good enough for development.
 

src/routes/docs/apis/realtime/+page.markdoc

@@ -109,7 +109,7 @@ More information and examples of authenticating users can be found in the dedica
 # Examples {% #examples %}
 The examples below will show you how you can use Realtime in various ways.
 
-## Subscribe to a Channel
+## Subscribe to a Channel {% #subscribe-to-one-channel %}
 In this example we are subscribing to all updates related to our account by using the `account` channel. This will be triggered by any update related to the authenticated user, like updating the user's name or e-mail address.
 
 {% multicode %}
@@ -177,7 +177,7 @@ val subscription = realtime.subscribe("account") {
 
 {% /multicode %}
 
-## Subscribe to Multiple Channels
+## Subscribe to Multiple Channels  {% #subscribe-to-multiple-channel %}
 
 You can also listen to multiple channels at once by passing an array of channels. This will trigger the callback for any events for all channels passed.
 
@@ -247,7 +247,7 @@ realtime.subscribe("databases.A.collections.A.documents.A", "files") {
 
 {% /multicode %}
 
-## Unsubscribe
+## Unsubscribe {% #unsubscribe %}
 
 If you no longer want to receive updates from a subscription, you can unsubscribe so that your callbacks are no longer called. Leaving old subscriptions alive and resubscribing can result in duplicate subscriptions and cause race conditions.
 
@@ -503,10 +503,13 @@ client.setEndpointRealtime("wss://cloud.appwrite.io/v1/realtime")
 
 While the Realtime API offers robust capabilities, there are currently some limitations to be aware of in its implementation.
 
-## Subscriptions changes
+## Subscription changes {% #subscription-changes %}
 
-The SDK creates a single WebSocket connection for all subscribed channels. Each time a channel is added or unsubscribed - the SDK currently creates a completely new connection and terminates the old one. Therefore, subscriptions to channels should always be done in conjunction with state management so as not to be unnecessarily built up several times by multiple components' life cycles.
+The SDK creates a single WebSocket connection for all subscribed channels. 
+Each time a channel is added or unsubscribed, the SDK currently creates a completely new connection and terminates the old one. 
+Therefore, subscriptions to channels should always be done in conjunction with state management so as not to be unnecessarily 
+built up several times by multiple components' life cycles.
 
-## Server-side SDKs
+## Server SDKs {% #server-sdk %}
 
 We currently are not offering access to realtime with Server SDKs and an API key.

src/routes/docs/apis/rest/+page.markdoc

@@ -45,7 +45,7 @@ Appwrite's REST APIs expect certain headers to be included with each request:
 
 Appwrite supports multiple authentication methods, including account sessions, API keys, and JWTs. The authentication method you use depends on your use case. Below are examples showing how you can authenticate using the REST API.
 
-## Client side
+## Client integrations {% #client-integration %}
 
 You can create account sessions with POST requests to the Account API. Sessions are persisted using secured cookies. You can learn more about session persistence in the Authentication Guide.
 
@@ -78,7 +78,7 @@ Content-Type: application/json
 X-Appwrite-Project: [PROJECT_ID]
 ```
 
-## Server side
+## Server integrations {% #server-integrations %}
 
 Server integrations use API keys to authenticate and are typically used for backend applications.
 
@@ -91,7 +91,7 @@ X-Appwrite-Project: [PROJECT_ID]
 X-Appwrite-Key: [API_KEY]
 ```
 
-## JWT
+## JWT {% #jwt %}
 
 JWT authentication is frequently used by server applications to act on behalf of a user. Users generate tokens using the [Create JWT](/docs/references/cloud/client-web/account#createJWT) endpoint. When issuing requests authenticated with a JWT, Appwrite will treat the request like it is from the authenticated user.
 
@@ -224,7 +224,7 @@ Appwrite SDKs have helpers to generate permission string formats, but when using
 ---
 {% /table %}
 
-## Roles
+## Roles {% #roles %}
 
 Appwrite SDKs have helpers to generate roles string formats, but when using Appwrite without SDKs, you'd need to create the strings yourself.
 

src/routes/docs/products/auth/quick-start/+page.markdoc

@@ -168,7 +168,7 @@ mutation {
 ```
 {% /multicode %}
 
-# More ways to Authenticate
+# More ways to authenticate {% #more-authentication %}
 You can signup and login a user with an account create through 
 [email password](/docs/products/auth/email-password),
 [phone (SMS)](/docs/products/auth/phone-sms),

src/routes/docs/products/auth/security/+page.markdoc

@@ -6,7 +6,7 @@ description: Prioritize security in your applications with Appwrite. Discover be
 
 Appwrite provides many security features to keep both your Appwrite project and your user's information secure.
 
-# Persistence 
+# Persistence {% #persistence %}
 
 Appwrite handles the persistence of the session in a consistent way across SDKs. After authenticating with an SDK, the SDK will persist the session so that the user will not need to log in again the next time they open the app. The mechanism for persistence depends on the SDK.
 
@@ -21,31 +21,31 @@ Only keep user sessions active as long as needed and maintain exactly **one** in
 | {% only_dark %}{% icon_image src="/images/platforms/dark/apple.svg" alt="Javascript logo" size="m" /%}{% /only_dark %}{% only_light %}{% icon_image src="/images/platforms/apple.svg" alt="Javascript logo" size="m" /%}{% /only_light %}  | Apple | Uses a session cookie stored in **UserDefaults**. |
 | {% only_dark %}{% icon_image src="/images/platforms/dark/android.svg" alt="Javascript logo" size="m" /%}{% /only_dark %}{% only_light %}{% icon_image src="/images/platforms/android.svg" alt="Javascript logo" size="m" /%}{% /only_light %}  | Android | Uses a session cookie stored in **SharedPreferences**. |
 
-# Session limits
+# Session limits {% #session-limits %}
 In Appwrite versions 1.2 and above, you can limit the number of active sessions created per user to prevent the accumulation of unused but active sessions. New sessions created by the same user past the session limit delete the oldest session.
 
 You can change the session limit in the **Security** tab of the Auth Service in your Appwrite Console. The default session limit is 10 with a maximum configurable limit of 100.
 
-# Permissions
+# Permissions {% #permissions %}
 
 Security is very important to protect users' data and privacy.
 Appwrite uses a [permissions model](/docs/advanced/platform/permissions) coupled with user sessions to ensure users need correct permissions to access resources.
 With all Appwrite services, including databases and storage, access is granted at the collection, bucket, document, or file level.
 These permissions are enforced for client SDKs and server SDKs when using JWT, but are ignored when using a server SDK with an API key.
 
-# Password history
+# Password history  {% #password-history %}
 
 Password history prevents users from reusing recent passwords. This protects user accounts from security risks by enforcing a new password every time it's changed.
 
 Password history can be enabled in the Auth service's **Security** tab on the Appwrite Console. You can choose how many previous passwords to remember up to a maximum of 20 and block users from reusing them.
 
-# Password dictionary
+# Password dictionary {% #password-dictionary %}
 
 Password dictionary protects users from using bad passwords. It compares the user's password to the [10,000 most common passwords](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10k-most-common.txt) and throws an error if there's a match. Together with [rate limits](/docs/advanced/platform/rate-limits), password dictionary will significantly reduce the chance of a malicious actor from guessing user passwords.
 
 Password dictionary can be enabled in the Auth service's **Security** tab on the Appwrite Console.
 
-# Personal data
+# Personal data  {% #personal-data %}
 
 Encourage passwords that are hard to guess by disallowing users to pick passwords that contain personal data.
 Personal data includes the user's name, email, and phone number.

src/routes/docs/products/databases/collections/+page.markdoc

@@ -8,7 +8,7 @@ The terms collections and documents are used because the Appwrite JSON REST API
 
 That said, Appwrite is designed to support both SQL and NoSQL database adapters like MariaDB, MySQL, or MongoDB in future versions. 
 
-# Create collection
+# Create collection {% #create-collection %}
 You can create collections using the Appwrite Console or a [Server SDK](/docs/sdks#server).
 {% tabs %}
 {% tabsitem #console title="Console" %}

src/routes/docs/products/databases/databases/+page.markdoc

@@ -7,13 +7,13 @@ Databases are the largest organizational unit in Appwrite.
 Each database contains a group [collections](/docs/products/databases/collections).
 In future versions, different databases may be backed by a different database technology of your choosing.
 
-# Create a database in Console
+# Create in Console {% #create-db-in-console %}
 The easiest way to create a database using the Appwrite Console.
 You can create a database by navigating to the **Databases** page and clicking **Create database**.
 
 
 
-# Create a database using Server SDKs
+# Create using Server SDKs {% #create-db-in-sdk %}
 You can programmatically create databases using a [Server SDK](/docs/sdks#server). Appwrite [Server SDKs](/docs/sdks#server) require an [API key](/docs/advanced/platform/api-keys).
 
 {% multicode %}

src/routes/docs/products/databases/relationships/+page.markdoc

@@ -398,7 +398,7 @@ databases.createDocument(
 ```
 {% /multicode %}
 
-## Edge case behaviors
+## Edge case behaviors {% #edge-case %}
 - If a nested child document is included and **no child document ID** is provided, the child document will be given a unique ID.
 - If a nested child document is included and **no conflicting child document ID** exists, the child document will be **created**.
 - If a nested child document is included and the **child document ID already exists**, the child document will be **updated**.

src/routes/docs/products/functions/development/+page.markdoc

@@ -1977,7 +1977,7 @@ public class Main {
 ```
 {% /multicode %}
 
-# Code splitting
+# Code splitting {% #code-splitting %}
 
 As your functions grow, you may find yourself needing to split your code into multiple files. This helps you keep your codebase maintainable and easy to read. Here's how you can accomplish code splitting.
 
@@ -2185,7 +2185,7 @@ public class Main {
 {% /tabsitem %}
 {% /tabs %}
 
-# Upgrade
+# Upgrade {% #upgrade %}
 
 Appwrite Functions received major updates in Appwrite version 1.4. 
 If you still have functions from previous versions, they will be **read-only** in Appwrite 1.4. 

src/routes/docs/products/functions/quick-start/+page.markdoc

@@ -43,7 +43,7 @@ The easiest way to execute your first function is to use the Appwrite Console.
 1. Wait for the execution to be marked **completed** and click to view the execution logs.
 
 
-# Explore
+# Explore {% #explore %}
 Use this your first function as a springboard to explore the flexible and powerful features of Appwrite Functions.
 
 | Explore                                                                 |                                                    |

src/routes/docs/products/storage/buckets/+page.markdoc

@@ -7,7 +7,7 @@ description: Organize and manage your files effectively with Appwrite Storage Bu
 Storage buckets are a group of files, similar to collections in Appwrite Databases.
 Buckets let you limit file size and extensions, whether or not to encrypt the files, and more. 
 
-# Create Bucket
+# Create Bucket {% #create-bucket %}
 You can create your bucket from the Appwrite Console or a [Server SDK](/docs/sdks#server). 
 
 {% tabs %}

src/routes/docs/products/storage/upload-download/+page.markdoc

@@ -130,7 +130,7 @@ If you're not using an SDK, you can [learn more about REST API file handling](/d
 # InputFile {% #input-file %}
 Every language and platform handles file inputs differently. This section documents the expected input type of each SDK. Where applicable, Appwrite provides an `InputFile` class to accept multiple file sources, like paths, buffers, streams, or plain text.
 
-# Client SDKs
+# Client SDKs {% #client-sdk %}
 
 {% tabs %}
 {% tabsitem #web title="Web" %}
@@ -180,7 +180,7 @@ The Appwrite Apple SDK expects an `InputFile` class for file inputs.
 {% /tabsitem %}
 {% /tabs %}
 
-# Server SDK
+# Server SDK {% #server-sdk %}
 
 {% tabs %}
 {% tabsitem #nodejs title="Node.js" %}

src/routes/docs/tooling/command-line/commands/+page.markdoc

@@ -74,7 +74,7 @@ appwrite users list --verbose
 
 # Examples {% #examples %}
 
-## Create user
+## Create user {% #create-user %}
 
 To create a new user in your project, you can use the create command.
 
@@ -84,15 +84,15 @@ appwrite users create --userId "unique()" \
     --password very_strong_password
 ```
 
-## List Users
+## List users {% #list-users %}
 
 To get a list of all your project users, you can use the list command.
 
 ```sh
 appwrite users list
 ```
 
-## List collections
+## List collections {% #list-collections %}
 
 To get a list of all your collections, you can use the listCollections command.
 
@@ -106,15 +106,15 @@ If you wish to parse the output from the CLI, you can request the CLI output in
 appwrite databases listCollections --databaseId [DATABASE_ID]--json
 ```
 
-## Get collection
+## Get collection {% #get-collection %}
 
 To get more information on a particular collection, you can make use of the getCollection command and pass in the collectionId.
 
 ```sh
 appwrite databases getCollection --databaseId [DATABASE_ID] --collectionId [COLLECTION_ID]
 ```
 
-## Create document
+## Create document {% #create-document %}
 
 To create a new document in an existing collection, use the `createDocument` command.
 

src/routes/docs/tooling/command-line/deployment/+page.markdoc

@@ -104,7 +104,7 @@ Here's a complete list of all configurable options in `appwrite.json`:
 | `teams` | array of teams | Configuration of teams in your project. |
 | `buckets` | array of buckets | Configuration of teams in your project. |
 
-### Function options
+### Function options {% #function-options %}
 
 | Option | Type | Description |
 | --- | --- | --- |
@@ -120,14 +120,14 @@ Here's a complete list of all configurable options in `appwrite.json`:
 | `timeout` | int | Execution timeout of the function in seconds, with a maximum configurable limit of 900 seconds. |
 | `variables` | JSON object | Variables provided to the function on execution stored as a key-value JSON object. |
 
-### Databases options
+### Databases options {% #database-options %}
 
 | Option | Type | Description |
 | --- | --- | --- |
 | `$id` | string | Database ID. |
 | `name` | string | Database Name. |
 
-### Collection options
+### Collection options {% #collection-options %}
 
 | Option | Type | Description |
 | --- | --- | --- |
@@ -140,7 +140,7 @@ Here's a complete list of all configurable options in `appwrite.json`:
 | `attributes` | array of objects | Defines a list of attributes in the collection. [Learn more about the Attributes List Object](/docs/references/cloud/models/attributeList). |
 | `indexes` | array of objects | Defines a list of indexes in the collection. [Learn more about the Indexes List Object](/docs/references/cloud/models/indexList). |
 
-### Buckets options
+### Buckets options {% #bucket-options %}
 
 | Option | Type | Description |
 | --- | --- | --- |
@@ -155,7 +155,7 @@ Here's a complete list of all configurable options in `appwrite.json`:
 | `encryption` | boolean | Whether the bucket's content is encrypted. |
 | `antivirus` | boolean | Whether virus scanning is enabled for the bucket's content. |
 
-### Teams options
+### Teams options {% #team-options %}
 
 | Option | Type | Description |
 | --- | --- | --- |

src/routes/docs/tutorials/react/step-6/+page.markdoc

@@ -4,7 +4,7 @@ title: Add database
 description: Add a database to your React application using Appwrite Web SDK.
 step: 6
 ---
-# Create collection
+# Create collection {% #create-collection %}
 In Appwrite, data is stored as a collection of documents. Create a collection in the [Appwrite Console](https://cloud.appwrite.io/) to store our ideas.
 
 {% only_dark %}
@@ -21,7 +21,7 @@ Create a new collection with the following attributes:
 | title       | String | Yes      |
 | description | String | No       |
 
-# Ideas context
+# Ideas context {% #idea-context %}
 
 Now that you have a collection to hold ideas, we can read and write to it from our app. Like we did with the user data, we will create a React context to hold our ideas.
 Create a new file `src/lib/context/ideas.jsx` and add the following code to it.