Document optgroup for backend forms dropdown field

backend/forms.md

@@ -440,6 +440,27 @@ status_type:
         draft: [Draft, icon-clock-o]
 ```
 
+#### Add option grouping (optgroup) to dropdown options
+
+In order to add option grouping, use a multidimensional array like below:
+
+```yaml
+status_type:
+    type: dropdown
+    label: Blog Post Status
+    options:
+        Group1:
+            opt1: Option 1
+            opt2: Option 2
+            opt3: Option 3
+        Group2:
+            opt4: Option 4
+            opt5: [Option 5, icon-check-circle]
+            opt6: Option 6
+```
+
+>**NOTE:** individual items in the groups can also use icons or images as shown in "Option 5" above.
+
 To define the behavior when there is no selection, you may specify an `emptyOption` value to include an empty option that can be reselected.
 
 ```yaml

cms/themes.md

@@ -307,6 +307,7 @@ themes/
 ```
 
 In this example, when `my-custom-theme` is active:
+
 - `theme.css` and `logo.png` load from the child theme
 - `header.htm` loads from the child theme
 - `footer.htm` loads from the parent theme (inherited)
@@ -349,49 +350,54 @@ When [database templates](#database-driven-themes) are enabled, you can:
 3. Inherit all other files from the parent theme's filesystem
 
 This approach allows you to:
+
 - Manage hundreds of similar themes without duplicating files
 - Update the parent theme and have changes cascade to all child themes automatically
 - Store tenant-specific customizations in the database while sharing a common codebase
 
-**Example: Creating a virtual child theme**
+**Example:** Creating a virtual child theme
 
 1. Enable database templates in `config/cms.php`:
 
 ```php
 'databaseTemplates' => true,
 ```
 
-2. Create a theme record in the database with just the `theme.yaml` content:
+1. Create a theme record in the database with just the `theme.yaml` content:
 
 ```yaml
 name: "Client A Custom Theme"
 parent: base-theme
 ```
 
-3. Customize only the templates that need to differ from the parent by saving them to the database
+1. Customize only the templates that need to differ from the parent by saving them to the database
 
 The child theme will now function without any physical directory, inheriting everything from `themes/base-theme` except for the database-stored customizations.
 
 ### Best Practices
 
 **When to use child themes:**
+
 - Customizing a third-party theme while preserving the ability to update it
 - Creating multiple branded variations of a base theme
 - Building a multi-tenant application where each tenant needs minor customizations
 - Developing a theme framework where a base theme provides core functionality
 
 **When to create a new theme instead:**
+
 - Making extensive changes that affect most templates and assets
 - Building something significantly different from the original design
 - When you need to modify the theme structure itself
 
 **Organization tips:**
+
 - Keep child themes minimal - only override what's necessary
 - Document which files are overridden and why
 - Use clear, descriptive names for child themes (e.g., `mytheme-client-a`, `mytheme-blue-variant`)
 - Consider using [theme customization](../themes/development#theme-customization) for simple configuration changes before creating a child theme
 
 **Performance considerations:**
+
 - Child themes have minimal performance impact - file resolution is cached
 - Avoid deep nesting (grandparent/parent/child) - only one level of inheritance is supported
 - Database-driven templates are cached, so virtual child themes perform well