Fix docs site homepage width, unreadable bold text, and deploy-k8s / icon UI bugs (#37681)

* Fix homepage width, card-title weight, and deploy-k8s code block clutter

The homepage's hide_table_of_contents:true dropped the usual 75% width
cap DocItem/Layout applies via docItemCol, so prose read much wider
than every other doc page. Restore the cap unconditionally.

CardGrid's card titles ("For End Users", etc.) used Archivo Black at
900 weight, the same too-heavy/shouty treatment already fixed for
h1-h4 — switch to the sans face at 700 to match.

On the Kubernetes Operator deploy page, strip inline "# comment"
annotations out of the YAML/shell snippets (moving anything useful
into surrounding prose), and replace nested blockquotes used purely
for list indentation with plain nested lists, since the blockquotes
were triggering the site's yellow-bordered blockquote styling at
every nesting level for no reason.

* Fix oversized Restore icon on the Send messages doc page

restore_F099B.svg was the only icon under docs/site/static/img/ui
missing explicit width/height attributes (every sibling icon sets
width="24" height="24"). Without them, the browser falls back to its
default SVG replaced-element size instead of the 24x24 the inline
.theme-icon usage expects, rendering it many times larger than the
surrounding text.

---------

Co-authored-by: Hanzo Dev <[email protected]>
This commit is contained in:
Eva Sarafianou
2026-07-28 08:44:34 +03:00
committed by GitHub
co-authored by Hanzo Dev
parent c5340635e7
commit 0100726431
4 changed files with 151 additions and 127 deletions
@@ -32,34 +32,34 @@ The Mattermost Kubernetes Operator can be installed using Helm.
1. Install Helm (version 3.13.0 or later). See the [Helm quickstart documentation](https://helm.sh/docs/using_helm/) for installation instructions.
2. Add the Mattermost Helm repository:
> ``` sh
> helm repo add mattermost https://helm.mattermost.com
> ```
``` sh
helm repo add mattermost https://helm.mattermost.com
```
3. Create a file named `config.yaml` and populate it with the contents of the [Mattermost operator values file](https://github.com/mattermost/mattermost-helm/blob/master/charts/mattermost-operator/values.yaml). This file allows for customization of the operator.
4. Create a namespace for the Mattermost Operator:
> ``` sh
> kubectl create ns mattermost-operator
> ```
``` sh
kubectl create ns mattermost-operator
```
5. Install the Mattermost Operator. If you don't specify a version, the latest version of the Mattermost Operator will be installed. We recommend using the latest version of the Mattermost Operator.
> ``` sh
> helm install &lt;your-release-name&gt; mattermost/mattermost-operator -n <namespace_name>
> ```
>
> For example:
>
> ``` sh
> helm install mattermost-operator mattermost/mattermost-operator -n mattermost-operator
> ```
>
> To use your custom `config.yaml` file:
>
> ``` sh
> helm install mattermost-operator mattermost/mattermost-operator -n mattermost-operator -f config.yaml
> ```
``` sh
helm install <your-release-name> mattermost/mattermost-operator -n <namespace_name>
```
For example:
``` sh
helm install mattermost-operator mattermost/mattermost-operator -n mattermost-operator
```
To use your custom `config.yaml` file:
``` sh
helm install mattermost-operator mattermost/mattermost-operator -n mattermost-operator -f config.yaml
```
### Step 3: Deploy Mattermost
@@ -72,71 +72,71 @@ The Mattermost Kubernetes Operator can be installed using Helm.
1. **(Mattermost Enterprise only)** Create a Mattermost license secret. Create a file named `mattermost-license-secret.yaml` with the following content, replacing `[LICENSE_FILE_CONTENTS]` with your actual license:
> ``` yaml
> apiVersion: v1
> kind: Secret
> metadata:
> name: my-mattermost-license
> type: Opaque
> stringData:
> license: <LICENSE_FILE_CONTENTS>
> ```
``` yaml
apiVersion: v1
kind: Secret
metadata:
name: my-mattermost-license
type: Opaque
stringData:
license: <LICENSE_FILE_CONTENTS>
```
2. Create a Mattermost installation manifest file named `mattermost-installation.yaml`. File names in this guide are suggestions; you can use different names. Use the following template, adjusting the values as needed:
> ``` yaml
> apiVersion: installation.mattermost.com/v1beta1
> kind: Mattermost
> metadata:
> name: <INSTALLATION_NAME_HERE> # Example: mm-example-full
> spec:
> size: <SIZE_VALUE_HERE> # Example: 5000users
> ingress:
> enabled: true
> host: <FULL_DOMAIN_NAME_HERE> # Example: example.mattermost-example.com
> annotations:
> kubernetes.io/ingress.class: nginx
> version: <VERSION_HERE> # Example: 9.3.0
> licenseSecret: "" # If you created a license secret, put the name here
> ```
>
> Key fields in the manifest include:
>
> - `metadata.name`: The name of your Mattermost deployment in Kubernetes.
> - `spec.size`: The size of your installation (e.g., "100users", "1000users", etc.).
> - `spec.ingress.host`: The DNS name for your Mattermost installation.
> - `spec.version`: The Mattermost version. See the [server version archive](/product-overview/version-archive) for available versions. You should use a [supported version](/product-overview/release-policy) of Mattermost in conjunction with the latest version of the Mattermost Operator.
> - `spec.licenseSecret`: The name of the Kubernetes secret containing your license (required for Enterprise).
>
> For a full list of configurable fields, see the [example manifest](https://github.com/mattermost/mattermost-operator/blob/master/docs/examples/mattermost_full.yaml) and the [Custom Resource Definition](https://github.com/mattermost/mattermost-operator/blob/master/config/crd/bases/installation.mattermost.com_mattermosts.yaml).
``` yaml
apiVersion: installation.mattermost.com/v1beta1
kind: Mattermost
metadata:
name: <INSTALLATION_NAME_HERE>
spec:
size: <SIZE_VALUE_HERE>
ingress:
enabled: true
host: <FULL_DOMAIN_NAME_HERE>
annotations:
kubernetes.io/ingress.class: nginx
version: <VERSION_HERE>
licenseSecret: ""
```
Key fields in the manifest include:
- `metadata.name`: The name of your Mattermost deployment in Kubernetes.
- `spec.size`: The size of your installation (e.g., "100users", "1000users", etc.).
- `spec.ingress.host`: The DNS name for your Mattermost installation.
- `spec.version`: The Mattermost version. See the [server version archive](/product-overview/version-archive) for available versions. You should use a [supported version](/product-overview/release-policy) of Mattermost in conjunction with the latest version of the Mattermost Operator.
- `spec.licenseSecret`: The name of the Kubernetes secret containing your license (required for Enterprise).
For a full list of configurable fields, see the [example manifest](https://github.com/mattermost/mattermost-operator/blob/master/docs/examples/mattermost_full.yaml) and the [Custom Resource Definition](https://github.com/mattermost/mattermost-operator/blob/master/config/crd/bases/installation.mattermost.com_mattermosts.yaml).
3. Create a file named `mattermost-database-secret.yaml` for database credentials. This secret must be in the same namespace as the Mattermost installation.
> ``` yaml
> apiVersion: v1
> data:
> DB_CONNECTION_CHECK_URL: <DB_CONNECTION_CHECK_URL>
> DB_CONNECTION_STRING: <DB_CONNECTION_STRING>
> MM_SQLSETTINGS_DATASOURCEREPLICAS: <MM_SQLSETTINGS_DATASOURCEREPLICAS>
> kind: Secret
> metadata:
> name: my-postgres-connection
> type: Opaque
> ```
>
> Example for AWS Aurora with PostgreSQL (`DB_CONNECTION_CHECK_URL`, `DB_CONNECTION_STRING`, and `MM_SQLSETTINGS_DATASOURCEREPLICAS` are the base64-encoded form of your Aurora connection URL, e.g. `postgres://user:password@host:5432/mattermost`):
>
> ``` yaml
> apiVersion: v1
> data:
> DB_CONNECTION_CHECK_URL: cG9zdGdyZXM6Ly91c2Vy... # base64-encoded connection URL
> DB_CONNECTION_STRING: cG9zdGdyZXM6Ly91c2Vy... # base64-encoded connection URL
> MM_SQLSETTINGS_DATASOURCEREPLICAS: cG9zdGdyZXM6... # base64-encoded replica URL
> kind: Secret
> metadata:
> name: my-postgres-connection
> type: Opaque
> ```
``` yaml
apiVersion: v1
data:
DB_CONNECTION_CHECK_URL: <DB_CONNECTION_CHECK_URL>
DB_CONNECTION_STRING: <DB_CONNECTION_STRING>
MM_SQLSETTINGS_DATASOURCEREPLICAS: <MM_SQLSETTINGS_DATASOURCEREPLICAS>
kind: Secret
metadata:
name: my-postgres-connection
type: Opaque
```
Example for AWS Aurora with PostgreSQL (`DB_CONNECTION_CHECK_URL`, `DB_CONNECTION_STRING`, and `MM_SQLSETTINGS_DATASOURCEREPLICAS` are the base64-encoded form of your Aurora connection URL, e.g. `postgres://user:password@host:5432/mattermost`):
``` yaml
apiVersion: v1
data:
DB_CONNECTION_CHECK_URL: cG9zdGdyZXM6Ly91c2Vy...
DB_CONNECTION_STRING: cG9zdGdyZXM6Ly91c2Vy...
MM_SQLSETTINGS_DATASOURCEREPLICAS: cG9zdGdyZXM6...
kind: Secret
metadata:
name: my-postgres-connection
type: Opaque
```
<Note>
@@ -152,7 +152,7 @@ Create a file named `mattermost-filestore-secret.yaml` to store the credentials
apiVersion: v1
kind: Secret
metadata:
name: <secret-name> # Choose a descriptive name (e.g., my-s3-credentials)
name: <secret-name>
type: Opaque
data:
accesskey: <base64-encoded-access-key>
@@ -199,10 +199,12 @@ metadata:
name: my-s3-credentials
type: Opaque
data:
accesskey: QUNDRVNTX0tFWQo= # Example: Replace with your actual encoded key
secretkey: U1VQRVJfU0VDUkVUX0tFWQo= # Example: Replace with your actual encoded key
accesskey: QUNDRVNTX0tFWQo=
secretkey: U1VQRVJfU0VDUkVUX0tFWQo=
```
Replace both values with your own base64-encoded keys.
</Important>
### Step 5: Configure the Mattermost Installation Manifest
@@ -210,52 +212,58 @@ data:
1. Modify the `mattermost-installation.yaml` file (created in step 2) to connect Mattermost to your external database and object storage. Refer to the supported fields for guidance on where to add these configurations within the YAML structure.
2. Connect to the database:
> 1. Add the following to the `spec` section of your manifest:
>
> > ``` yaml
> > spec:
> > database:
> > external:
> > secret: &lt;database-secret-name&gt; # The name of the database secret (e.g., my-postgres-connection)
> > ```
>
> 2. **(Recommended)** Configure the database-readiness init container to use the in-image `mattermost db ping` command instead of the legacy `postgres:13` + `pg_isready` flow. This avoids the need to pull a separate `postgres:13` image (the primary motivation for air-gapped clusters that can't mirror it) and keeps your readiness check in sync with the Mattermost release you're running.
>
> > ``` yaml
> > spec:
> > database:
> > external:
> > secret: <database-secret-name>
> > readinessCheck:
> > mode: builtin
> > timeout: 5m # optional; default is 5m
> > ```
>
> Using `builtin` mode requires a Mattermost release that ships the `mattermost db ping` command (see the [Mattermost server pull request](https://github.com/mattermost/mattermost/pull/36406) for availability).
>
> Omitting `readinessCheck` (or setting `mode: external`) preserves the legacy `postgres:13` + `pg_isready` behavior. The legacy mode is the current default for backward compatibility and will be deprecated in a future operator release. See the [Mattermost CRD reference](https://github.com/mattermost/mattermost-operator/blob/master/docs/mattermost_v1beta1_crd.md) for the full `readinessCheck` field schema.
1. Add the following to the `spec` section of your manifest:
``` yaml
spec:
database:
external:
secret: <database-secret-name>
```
Replace `<database-secret-name>` with the name of the database secret you created (e.g., `my-postgres-connection`).
2. **(Recommended)** Configure the database-readiness init container to use the in-image `mattermost db ping` command instead of the legacy `postgres:13` + `pg_isready` flow. This avoids the need to pull a separate `postgres:13` image (the primary motivation for air-gapped clusters that can't mirror it) and keeps your readiness check in sync with the Mattermost release you're running.
``` yaml
spec:
database:
external:
secret: <database-secret-name>
readinessCheck:
mode: builtin
timeout: 5m
```
`timeout` is optional and defaults to `5m`.
Using `builtin` mode requires a Mattermost release that ships the `mattermost db ping` command (see the [Mattermost server pull request](https://github.com/mattermost/mattermost/pull/36406) for availability).
Omitting `readinessCheck` (or setting `mode: external`) preserves the legacy `postgres:13` + `pg_isready` behavior. The legacy mode is the current default for backward compatibility and will be deprecated in a future operator release. See the [Mattermost CRD reference](https://github.com/mattermost/mattermost-operator/blob/master/docs/mattermost_v1beta1_crd.md) for the full `readinessCheck` field schema.
3. Connect to Object Storage:
> 1. Add the following to the `spec` section of your manifest:
>
> > ``` yaml
> > spec:
> > fileStore:
> > external:
> > url: &lt;storage-service-url&gt; # The URL of your storage service (e.g., s3.amazonaws.com)
> > bucket: &lt;bucket-name&gt; # The name of your storage bucket
> > secret: &lt;filestore-secret-name&gt; # The name of the filestore secret (e.g., my-s3-credentials)
> > ```
1. Add the following to the `spec` section of your manifest:
``` yaml
spec:
fileStore:
external:
url: <storage-service-url>
bucket: <bucket-name>
secret: <filestore-secret-name>
```
Replace `<storage-service-url>` with the URL of your storage service (e.g., `s3.amazonaws.com`), `<bucket-name>` with the name of your storage bucket, and `<filestore-secret-name>` with the name of the filestore secret you created (e.g., `my-s3-credentials`).
4. If you are using Amazon S3, it's recommended to enable server-side encryption (SSE) and SSL. Add the following environment variables to the `mattermostEnv` section:
> ``` yaml
> spec:
> mattermostEnv:
> MM_FILESETTINGS_AMAZONS3SSL: true
> MM_FILESETTINGS_AMAZONS3SSE: true
> ```
``` yaml
spec:
mattermostEnv:
MM_FILESETTINGS_AMAZONS3SSL: true
MM_FILESETTINGS_AMAZONS3SSE: true
```
## Review Mattermost Resource Status
@@ -86,10 +86,13 @@
}
.title {
font-family: var(--mm-font-heading);
font-weight: 900;
/* Mixed-case, multi-word labels (e.g. "For End Users") read as too
* heavy/shouty in Archivo Black at 900 — same issue already fixed for
* h1-h4 — so use the sans face at a lighter bold weight instead. */
font-family: var(--mm-font-sans);
font-weight: 700;
font-size: 1.05rem;
letter-spacing: 0.01em;
letter-spacing: -0.01em;
margin-bottom: 0.35rem;
color: var(--mm-text-primary);
}
+13
View File
@@ -599,6 +599,19 @@ blockquote {
padding-right: clamp(1rem, 2vw, 2rem);
}
/* theme-classic's DocItem/Layout only caps the article column at 75% via
* its own `docItemCol` class when a TOC renders alongside it — pages with
* `hide_table_of_contents: true` (e.g. the homepage) get a lone full-width
* `.col` instead, so prose reads much wider than on every other doc page.
* Recreate the same 75% cap here, keyed off the `<article>` that's always
* a descendant of the doc content column, regardless of TOC presence. */
@media (min-width: 997px) {
.docMainContainer_TBSr .col:has(> div > article),
[class*='docMainContainer'] .col:has(> div > article) {
max-width: 75%;
}
}
/* Without max-width, the doc content flex column no longer has an upper
* bound to shrink against, so a wide code block (long lines, e.g. inline
* YAML comments) inflates its own intrinsic min-content size and drags the
+1 -1
View File
@@ -1 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13,3A9,9 0 0,0 4,12H1L4.89,15.89L4.96,16.03L9,12H6A7,7 0 0,1 13,5A7,7 0 0,1 20,12A7,7 0 0,1 13,19C11.07,19 9.32,18.21 8.06,16.94L6.64,18.36C8.27,20 10.5,21 13,21A9,9 0 0,0 22,12A9,9 0 0,0 13,3Z" /></svg>
<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24"><path d="M13,3A9,9 0 0,0 4,12H1L4.89,15.89L4.96,16.03L9,12H6A7,7 0 0,1 13,5A7,7 0 0,1 20,12A7,7 0 0,1 13,19C11.07,19 9.32,18.21 8.06,16.94L6.64,18.36C8.27,20 10.5,21 13,21A9,9 0 0,0 22,12A9,9 0 0,0 13,3Z" /></svg>

Before

Width:  |  Height:  |  Size: 273 B

After

Width:  |  Height:  |  Size: 296 B