mnocon · Sep 29, 2026 · Sep 22, 2026 · Sep 23, 2026 · Sep 23, 2026 · Sep 23, 2026
diff --git a/.github/workflows/yaml_samples.yaml b/.github/workflows/yaml_samples.yaml
diff --git a/.gitignore b/.gitignore
@@ -14,7 +14,6 @@ docs/css/*.map
 lychee.toml
 /repositories/
 lychee-report.md
-.phpunit.result.cache
 /build/
 *.egg-info/
 /doc/

diff --git a/README.md b/README.md
@@ -44,19 +44,6 @@ of the command.
 
 ## Testing the documentation
 
-### YAML configuration
-
-The YAML snippets in the Markdown pages are validated against the
-Symfony configuration trees of the installed Ibexa bundles. To run the validation, use:
-
-``` bash
-composer update
-composer check-yaml
-```
-
-To add an error into a baseline, run `composer yaml-update-baseline` and commit the result.
-Error added to the baseline are not reported again.
-
 ### markdownlint
 
 This repository uses [markdownlint-cli2](https://github.com/DavidAnson/markdownlint-cli2) to check Markdown formatting, including table syntax.

diff --git a/composer.json b/composer.json
@@ -4,11 +4,6 @@
     "type": "library",
     "keywords": ["ibexa", "cohesivo", "documentation", "markdown", "llm", "ai", "agents"],
     "license": "GNU General Public License v2.0",
-    "autoload-dev": {
-        "psr-4": {
-            "Ibexa\\Tests\\Documentation\\": "tests/"
-        }
-    },
     "repositories": [
         {
             "type": "composer",
@@ -19,8 +14,6 @@
         "php": "^8.3"
     },
     "require-dev": {
-        "phpunit/phpunit": "^11.0",
-        "symfony/yaml": "^7.0",
         "ibexa/connector-gemini": "6.0.x-dev",
         "ibexa/doctrine-schema": "6.0.x-dev",
         "ibexa/search": "6.0.x-dev",
@@ -89,10 +82,6 @@
         "ibexa/design-system-twig": "~6.0.x-dev"
     },
     "scripts": {
-        "check-yaml": "phpunit --group yaml",
-        "phpunit": "phpunit --exclude-group=yaml",
-        "yaml-update-baseline": "php tests/generate-yaml-baseline.php",
-        "composer-update": "[ -d vendor ] || composer update",
         "yarn-install": "[ -d node_modules ] || yarn install",
         "markdownlint": [
             "@yarn-install",
@@ -103,27 +92,18 @@
             "yarn markdownlint --fix"
         ],
         "test": [
-            "@composer-update",
-            "EXIT=0; FAILED=''; { composer markdownlint; } || { EXIT=1; FAILED=\"$FAILED markdownlint\"; }; { composer check-yaml; } || { EXIT=1;  FAILED=\"$FAILED check-yaml\"; }; if [ 1 -eq $EXIT ]; then echo \"Failed:$FAILED\"; fi; exit $EXIT;"
+            "@markdownlint"
         ],
         "fix": [
             "@composer fix-markdownlint"
-        ],
-        "baseline": [
-            "@composer-update",
-            "@composer yaml-update-baseline"
         ]
     },
     "scripts-descriptions": {
-        "check-yaml": "Run PHPUnit tests (YAML validation)",
-        "yaml-update-baseline": "Regenerate tests/yaml-validation-baseline.yaml from current failures",
-        "composer-update": "Install composer dependencies if not already installed",
         "yarn-install": "Install yarn dependencies if not already installed",
         "markdownlint": "Run Markdownlint on all documentation files",
         "fix-markdownlint": "Automatically fixes Markdownlint issues in all documentation files",
-        "test": "Run all checks (Markdownlint, YAML checks), continuing past failures and reporting failure overall if any check failed",
-        "fix": "Run all automatic fixes (Markdownlint)",
-        "baseline": "Regenerate the YAML validation baseline from current failures"
+        "test": "Run all checks (Markdownlint)",
+        "fix": "Run all automatic fixes (Markdownlint)"
     },
     "config": {
         "allow-plugins": false

diff --git a/docs/administration/admin_panel/admin_panel.md b/docs/administration/admin_panel/admin_panel.md
@@ -6,9 +6,9 @@ page_type: landing_page
 # Admin panel
 
 Once you set up your environment you can start your work as an administrator.
-You can find key tools in **Admin** panel.
+You can find key tools in **Administration** panel.
 
-To access **Admin** panel, click the icon: ![Admin panel Icon](admin_panel_icon.png){.inline-image}.
+To access **Administration** panel, click the icon: ![Admin panel Icon](admin_panel_icon.png){.inline-image}.
 
 [[= cards([
     "administration/admin_panel/users_admin_panel",
@@ -19,4 +19,5 @@ To access **Admin** panel, click the icon: ![Admin panel Icon](admin_panel_icon.
     "administration/admin_panel/workflow_admin_panel",
     "administration/admin_panel/recent_activity_admin_panel",
     "administration/admin_panel/system_information_admin_panel",
+    "administration/configuration/configuration",
 ], columns=4) =]]
diff --git a/docs/administration/admin_panel/recent_activity_admin_panel.md b/docs/administration/admin_panel/recent_activity_admin_panel.md
@@ -1,5 +1,5 @@
 ---
-description: Log and monitor activity through UI, PHP API and REST API.
+description: Log and monitor activity through UI and REST API.
 month_change: false
 ---
 
@@ -13,7 +13,7 @@ To learn more about its back office usage and the actions logged by default, see
 
 ## Permission and security
 
-The [`activity_log/read`](policies.md#activity-log) policy gives a role the access to the **Admin** -> **Activity list**, the dashboard's **Recent activity** block, and the user profile's **Recent activity**.
+The [`activity_log/read`](policies.md#activity-log) policy gives a role the access to the **Administration** -> **Activity list**, the dashboard's **Recent activity** block, and the user profile's **Recent activity**.
 It can be limited to "Only own logs" ([`ActivityLogOwner`](limitation_reference.md#activity-log-owner-limitation)).
 
 The policy should be given to every roles having access to the back office, at least with the `ActivityLogOwner` owner limitation, to allow them to use the "Recent activity" block in the dashboard.
@@ -23,17 +23,6 @@ This policy is required to view [activity log in user profile]([[= user_doc =]]/
 
     Don't assign `activity_log/read` permission to the Anonymous role, even with the owner limitation, because this role is shared among all unauthenticated users.
 
-## User privacy
-
-!!! caution
-
-    A username of the User who performs the action is logged.
-    When acting through the web server, the User's IP address is also logged.
-    Other access, such as console commands, doesn't log an IP.
-    Your Data Protection Officer or GDPR representative should be aware of this, so they can ensure users are informed if needed, depending on your use case, jurisdiction, and company policy.
-
-    For example, if a content edition feature, such as reader's comments, is available in the front office, the recent activity log records the front users' IPs.
-
 ## REST API
 
 You can browse activity logs with REST API.

diff --git a/docs/administration/admin_panel/roles_admin_panel.md b/docs/administration/admin_panel/roles_admin_panel.md
@@ -4,7 +4,7 @@ description: To give users an access to your website you need to assign them rol
 
 # Roles
 
-To give users an access to your website you need to assign them roles in the **Admin** panel.
+To give users an access to your website you need to assign them roles in the **Administration** panel.
 
 ![Roles](admin_panel_roles.png "Roles")
 

diff --git a/docs/administration/admin_panel/system_information_admin_panel.md b/docs/administration/admin_panel/system_information_admin_panel.md
@@ -4,7 +4,6 @@
 
 # System Information
 
-The System Information panel in the back office is sourced in the [`ibexa/system-info` repository](https://github.com/ibexa/system-info).
-There you can also find basic system information such as versions of all installed packages.
+The System Information panel in the back office displays information about your content repository, for example, the number of publish content objects or the number of users in the system.
 
 ![System Information](admin_panel_system_info.png "System Information")
diff --git a/docs/administration/admin_panel/url_management_admin_panel.md b/docs/administration/admin_panel/url_management_admin_panel.md
@@ -1,10 +1,10 @@
 ---
-description: URL Management lets you manage external URL addresses and URL wildcards.
+description: URL Management lets you manage external URL addresses.
 ---
 
 # URL Management
 
-You can manage external URL addresses and URL wildcards in the **Admin** panel.
+You can manage external URL addresses in the **Administration** panel.
 Configure URL aliases to have human-readable URL addresses throughout your system.
 
 For more information, see [URL management](url_management.md).

diff --git a/docs/administration/admin_panel/users_admin_panel.md b/docs/administration/admin_panel/users_admin_panel.md
@@ -6,11 +6,32 @@
 
 [Users](users.md) in [[= product_name =]] are treated the same way as content items.
 They're organized in groups such as *Guests*, *Editors*, *Anonymous*, which makes it easier to manage them and their permissions.
-You can access all users and user groups in the **Admin** panel by selecting **Users**.
+You can access all users and user groups in the **Administration** panel by selecting **Users**.
 
 ![Users and user groups](admin_panel_users.png "Users and user groups")
 
 !!! caution
 
     Be careful not to delete an existing user account.
     If you do this, content created by this user can be broken and the application can face malfunction.
+
+## Built-in users
+
+Built-in roles and users control the behavior of the system:
+
+### Anonymous user
+
+The Anonymous user, in the **Anonymous users** group, is a special user that controls what data can be seen by unauthenticated users and visitors.
+It applies both to the UI and [API](rest_api_authentication.md#anonymous-access).
+
+### Service Account user
+
+The `REST Service Account` user, in the **SSO users** user group, is used when authenticating to the REST API or MCP Server with [client credentials](rest_api_authentication.md#client-credentials).
+
+You can:
+
+- change the permissions assigned to this user
+- assign new roles to it
+- move it between user groups
+
+**If you modify or delete this user, authentication with client credentials won't be possible.**
diff --git a/docs/administration/configuration/configuration.md b/docs/administration/configuration/configuration.md
@@ -1,13 +1,30 @@
 ---
-description: In Cohesivo you store and manage configuration in project files, typically in YAML format.
+description: Manage your Cohesivo configuration.
 ---
 
 # Configuration
 
-TODO: Rework this to describe the SiteAccess UI, and siteacces-aware settings.
+To manage the configuration of your [[= product_name =]] sites, go to the **SiteAccess Configuration** screen in the **Administration** tab.
+It exposes settings that you can change directly in the back office, without deploying any code.
 
-Merge the content from docs/multisite/siteaccess/siteaccess_aware_configuration.md
+!!! note "On-premise configuration"
 
-## `admin` SiteAccess
+    The Configuration UI replaces the [YAML configuration layer]([[= on_premise_doc =]]/administration/configuration/configuration/) you know from on-premise version of [[= product_name =]].
 
-The predefined `admin` SiteAccess in `admin_group` serves the back office.
+## Configuration scopes
+
+Configuration is [SiteAccess](siteaccess.md)-aware, so the same setting can have a different value on each of your sites.
+
+![SiteAccess Configuration screen](siteaccess_configuration.png "SiteAccess Configuration screen")
+
+You can set the default configuration, or choose a SiteAccess to configure a specific one:
+
+- To edit the default values, don't select any SiteAccess from the list. Values you set apply for all SiteAccesses unless a SiteAccess overrides them.
+- To edit the values for one SiteAccess, select its SiteAccess first. Values saved for a SiteAccess override the default values.
+
+## Editing configuration
+
+After you choose an available configuration, follow the displayed instructions to learn more about the given setting and how to configure it.
+Once you're done, use the "Generated Parameters" section to verify your configuration is correct.
+
+![Page Builder block overrides](siteaccess_configuration_blocks.png "Page Builder block overrides")
diff --git a/docs/administration/configuration/img/siteaccess_configuration.png b/docs/administration/configuration/img/siteaccess_configuration.png
diff --git a/docs/administration/configuration/img/siteaccess_configuration_blocks.png b/docs/administration/configuration/img/siteaccess_configuration_blocks.png
diff --git a/docs/administration/content_organization/content_types.md b/docs/administration/content_organization/content_types.md
@@ -32,7 +32,7 @@
 
     Even if your content type defines a field intended as a name for the content item (for example, a title of an article or product name), don't confuse it with this Name, which is a piece of metadata, not a field.
 
-**Identifier** – an identifier for internal use in configuration, for example, files, templates, or PHP code.
+**Identifier** – an identifier for internal use in configuration, for example, website templates.
 It must be unique, can only contain lowercase letters, digits, and underscores (it's mandatory and the maximum length is 50 characters).
 
 **Description** – a detailed description of the content type (optional).
@@ -56,7 +56,7 @@
 
     The old URL aliases continue to redirect to the same content items.
 
-**Container** – a flag which indicates if content items based on this content type are allowed to have sub-items or not (mainly relevant for actions via the UI, not validated by every PHP API).
+**Container** – a flag which indicates if content items based on this content type are allowed to have sub-items or not (mainly relevant for actions via the UI, not validated by every API).
 
 !!! note
 
@@ -91,7 +91,7 @@
 
     In case of content types containing many field types you should be aware of possible memory-related issues with publishing/editing.
     You may also experience performance problems with such large content types, in particular when you have many content items.
-    If you're experincing too many issues, consider rearranging your project to avoid them.
+    If you're experiencing too many issues, consider rearranging your project to avoid them.
 
 ## Modifying content types
 

diff --git a/docs/administration/content_organization/sections.md b/docs/administration/content_organization/sections.md
@@ -30,7 +30,7 @@ Other references to the section remain and thus the system most likely loses con
 
 !!! caution
 
-    Removing sections may corrupt permission settings, template output and other things in the system.
+    Removing sections may corrupt permission settings or other things in the system.
 
 Section ID numbers aren't recycled.
 If a section is removed, its ID number cannot be reused when a new section is created.
diff --git a/docs/ai/ai_actions/ai_actions_guide.md b/docs/ai/ai_actions/ai_actions_guide.md
@@ -65,23 +65,23 @@
 #### AI action configuration
 
 AI action configurations store detailed parameters needed to generate AI actions based on AI action types.
-Website administrators manage AI action configurations in the [**Admin** panel](admin_panel.md), where they customize and fine-tune the behavior of each AI action.
+Website administrators manage AI action configurations in the [**Administration** panel](admin_panel.md), where they customize and fine-tune the behavior of each AI action.
 It might involve setting specific parameters used by the AI service, a response length, an expense limit, or configuring how the output should be handled.
 By making such adjustments, administrators can ensure that the actions are tailored to meet the needs of your organization.
 
 #### Model
 
 Once an AI action is defined and configured, it must be executed, and this is where models come into play.
 Each model is designed to work with a specific AI service and AI action type pair.
-Pieces of PHP code that are responsible for resolving a model are called handlers.
+Pieces of code that are responsible for resolving a model are called handlers.
 They may include hardcoded prompts for conversational AI services like ChatGPT, or operate without prompts in the case of other types of AI.
 Handlers take parameters defined in the AI action type and configuration, combine it with user input and any predefined settings or prompts, and pass this information to the AI service for processing.
 
 ### Triggering actions from the UI
 
 Among other elements, AI Actions include UI components that are used in:
 
-- AI action management in the **Admin** panel
+- AI action management in the **Administration** panel
 - text modification in online editor
 - alt-text generation in the image management modal
 
@@ -104,7 +104,7 @@
 
 ![Configurations management screen](img/ai_actions_list.png)
 
-An intuitive AI Actions interface within the **Admin** panel displays a list of all available AI actions.
+An intuitive AI Actions interface within the **Administration** panel displays a list of all available AI actions.
 Here, you can search for specific actions and filter them by type or status.
 By accessing the detailed view of individual AI actions, you can quickly review all their parameters.
-Original file line number
+Diff line change
@@ Expand Up @@
     # Roles
-    To give users an access to your website you need to assign them roles in the **Admin** panel.
+    To give users an access to your website you need to assign them roles in the **Administration** panel.
     ![Roles](admin_panel_roles.png "Roles")
@@ Expand Down @@