diff --git a/.codewhisperer/settings.json b/.codewhisperer/settings.json
new file mode 100644
index 0000000..0d6ee14
--- /dev/null
+++ b/.codewhisperer/settings.json
@@ -0,0 +1,9 @@
+{
+ "customizations": [
+ {
+ "name": "CouchCMS Documentation Standards",
+ "description": "Documentation writing standards for CouchCMS",
+ "instructions": "# CouchCMS Documentation Standards\n# Auto-generated from DOCS-STANDARDS.md\n\n**Critical: Always follow these documentation standards.**\n\n## Project Context\n\n- **Project**: CouchCMS Documentation\n- **Type**: Technical Documentation\n- **Platform**: Astro + Starlight\n- **Content Format**: MDX (Markdown + JSX)\n- **Standards**: English-only, 4-space indentation, WCAG 2.1 AA\n\n## Core Principles\n\n1. **Single Source of Truth**: STYLEGUIDE.md is authoritative\n2. **Consistency First**: All documentation follows identical patterns\n3. **Accessibility**: WCAG 2.1 AA compliance mandatory\n4. **English Only**: All content, code, and comments in English\n5. **Semantic Structure**: Proper heading hierarchy and HTML5\n\n## Essential Formatting Rules\n\n### Frontmatter (Required)\nEvery MDX file must start with:\n```yaml\n---\ntitle: [50-60 chars, include keyword]\ndescription: \"[150-160 chars]\"\nkeywords: [keyword1, keyword2, keyword3]\ncategory: [category]\nauthor: [Author Name]\nlastUpdated: YYYY-MM-DD\nsidebar:\n order: [number]\n---\n```\n\n### Text Formatting\n\n**Product Names:**\n- Regular: \"Couch\"\n- Formal: \"CouchCMS\"\n- Never bold (except headers)\n\n**Technical Terms (backticks):**\n- Files: `config.php`, `.htaccess`\n- Variables: `my_variable`\n- Code: `echo $value`\n- Booleans: `true`, `false`\n\n**UI Elements (bold):**\n- Pages: **About Us**\n- Buttons: **Save Changes**\n- Use Title Case\n\n**Tag References:**\n```markdown\n[**editable**](../../tags-reference/core/editable/)\n```\n\n**Documentation Links:**\n```markdown\n[**Working with Templates**](../../concepts/templates/)\n```\n\n### Code Blocks\n\nAlways include descriptive titles:\n````markdown\n```php title=\"config.php\"\n\n```\n````\n\n### Components\n\n**Steps:**\n```markdown\nimport { Steps } from \"@astrojs/starlight/components\";\n\n\n\n1. First step\n2. Second step\n\n\n```\n\n**Card:**\n```markdown\n\n\nContent\n\n\n```\n\n**FileTree (NO backticks!):**\n```markdown\n\n- src/\n - content/\n\n```\n\n### Links\n\n- Internal links: ALWAYS use trailing slashes\n- Meaningful text (no \"click here\")\n- Relative paths for internal content\n\n### Admonitions\n\n```markdown\n:::note[Context]\nInformation\n:::\n\n:::tip[Best Practice]\nRecommendation\n:::\n\n:::caution[Important]\nLimitation\n:::\n\n:::danger[Warning]\nCritical warning\n:::\n```\n\n## Quality Checklist\n\nBefore finalizing documentation:\n- ✅ Valid frontmatter with SEO metadata\n- ✅ Proper heading hierarchy (no skipping)\n- ✅ Technical terms in backticks\n- ✅ UI elements in bold\n- ✅ Links with trailing slashes\n- ✅ Code blocks with titles\n- ✅ Complete examples\n- ✅ Image alt text\n- ✅ WCAG 2.1 AA compliance\n\n## AI Tools Available\n\n### Automated (Auto-Applied)\n- `.cursor/rules/markdown.mdc` - Formatting rules\n- `.cursor/rules/content-structure.mdc` - Content organization\n- `.cursor/rules/component-architecture.mdc` - Components\n\n### Manual (Explicit Use)\n- `@.cursor/prompts/convert-to-markdown.md` - Convert content\n- `@.cursor/prompts/markdown-quick-reference.md` - Quick syntax\n\n### Reference Documentation\n- **AI-TOOLKIT.md** - Complete toolkit guide\n- **STYLEGUIDE.md** - Full formatting rules\n- **.cursor/README.md** - Detailed documentation\n\n## Common Patterns\n\n### Introducing CMS Tags\n```markdown\nThe [**editable**](../../tags-reference/core/editable/) tag creates regions.\n\n## Basic Usage\n\n```php title=\"example.php\"\n\n```\n\n:::tip[Best Practice]\nUse descriptive names.\n:::\n```\n\n### Cross-References\n```markdown\nSee [**Working with Templates**](../../concepts/templates/).\n```\n\n### Version Info\n```markdown\n:::version[v2.0+]\nRequires CouchCMS v2.0 or higher.\n:::\n```\n\n## Error Prevention\n\n**Never:**\n- ❌ Use non-English language\n- ❌ Skip frontmatter\n- ❌ Incorrect heading hierarchy\n- ❌ Omit code block titles\n- ❌ Forget trailing slashes\n\n**Always:**\n- ✅ Complete frontmatter\n- ✅ Proper heading hierarchy\n- ✅ Descriptive code titles\n- ✅ Trailing slashes in links\n- ✅ Correct tag formatting\n\n---\n\n**For complete rules, see STYLEGUIDE.md**\n**For conversion help, use @.cursor/prompts/convert-to-markdown.md**\n**Generated from DOCS-STANDARDS.md - Last updated: 2025-11-26**\n"
+ }
+ ]
+}
\ No newline at end of file
diff --git a/.cursor/AI-CONFIG-INDEX.md b/.cursor/AI-CONFIG-INDEX.md
new file mode 100644
index 0000000..359868c
--- /dev/null
+++ b/.cursor/AI-CONFIG-INDEX.md
@@ -0,0 +1,42 @@
+# AI Configuration Index
+# Auto-generated from DOCS-STANDARDS.md
+
+All AI editor configurations are automatically generated from **DOCS-STANDARDS.md**.
+
+## Generated Files
+
+### AI Assistants
+- ✅ `.cursorrules` - Cursor AI configuration
+- ✅ `CLAUDE.md` - Claude AI instructions
+- ✅ `.windsurfrules` - Windsurf AI configuration
+- ✅ `.github/copilot-instructions.md` - GitHub Copilot
+- ✅ `.tabnine/settings.json` - Tabnine configuration
+- ✅ `.codewhisperer/settings.json` - Amazon CodeWhisperer
+
+### Editors
+- ✅ `.vscode/settings.json` - VS Code settings
+- ✅ `.editorconfig` - Universal editor config
+
+## Single Source of Truth
+
+**DOCS-STANDARDS.md** → All configurations above
+
+To update all AI configurations:
+```bash
+bun run sync
+```
+
+## Manual Tools
+
+These files are maintained manually:
+- `.cursor/rules/*.mdc` - Auto-applied formatting rules
+- `.cursor/prompts/*.md` - AI assistance prompts
+- `STYLEGUIDE.md` - Complete style guide
+
+## Last Sync
+
+Generated: 2025-11-26T17:19:28.784Z
+
+---
+
+**Never edit generated files directly. Edit DOCS-STANDARDS.md and run `bun run sync`.**
diff --git a/.cursor/INDEX.md b/.cursor/INDEX.md
new file mode 100644
index 0000000..0a7abc5
--- /dev/null
+++ b/.cursor/INDEX.md
@@ -0,0 +1,264 @@
+# CouchCMS Documentation - AI Toolkit Index
+
+Complete overview of all AI assistance tools for documentation development.
+
+## 🎯 Quick Access
+
+| Need | File | Use |
+|------|------|-----|
+| **Start Here** | [QUICKSTART.md](.cursor/QUICKSTART.md) | 30-second guide |
+| **Complete Guide** | [README.md](.cursor/README.md) | Full toolkit documentation |
+| **Convert Content** | [convert-to-markdown.md](.cursor/prompts/convert-to-markdown.md) | Content conversion |
+| **Format Reference** | [markdown-quick-reference.md](.cursor/prompts/markdown-quick-reference.md) | Syntax lookup |
+| **Style Rules** | [STYLEGUIDE.md](../STYLEGUIDE.md) | Complete formatting guide |
+
+## 📂 Directory Structure
+
+```
+.cursor/
+├── README.md # Complete AI toolkit guide
+├── QUICKSTART.md # 30-second start guide
+├── INDEX.md # This file - complete overview
+│
+├── rules/ # Auto-applied formatting rules
+│ ├── markdown.mdc # Complete formatting rules (auto-applied)
+│ ├── content-structure.mdc # Content organization patterns
+│ └── component-architecture.mdc # Component usage rules
+│
+└── prompts/ # AI assistance prompts
+ ├── README.md # Prompt usage guide
+ ├── convert-to-markdown.md # Content conversion prompt
+ └── markdown-quick-reference.md # Quick formatting reference
+```
+
+## 🤖 Automated Rules (Auto-Applied)
+
+These rules automatically apply when you edit markdown files:
+
+### 1. markdown.mdc
+**Auto-applies to:** All `.md` and `.mdx` files
+**Coverage:** Complete formatting rules from STYLEGUIDE.md
+**Purpose:** Ensures consistent documentation quality
+
+### 2. content-structure.mdc
+**Auto-applies to:** Content collections and layouts
+**Coverage:** Documentation hierarchy and navigation
+**Purpose:** Maintains logical content organization
+
+### 3. component-architecture.mdc
+**Auto-applies to:** Component files and MDX
+**Coverage:** Astro/Starlight component patterns
+**Purpose:** Consistent component usage
+
+## 🛠️ AI Prompts (Manual Use)
+
+Use these prompts explicitly when needed:
+
+### 1. convert-to-markdown.md
+**Use for:**
+- Converting any content to CouchCMS markdown format
+- Creating new documentation pages from scratch
+- Ensuring style guide compliance
+
+**How to use:**
+```markdown
+@.cursor/prompts/convert-to-markdown.md
+
+Convert this content about [topic]:
+[Your content]
+```
+
+### 2. markdown-quick-reference.md
+**Use for:**
+- Quick syntax lookups
+- Format pattern reference
+- Validation examples
+
+**How to use:**
+```markdown
+@.cursor/prompts/markdown-quick-reference.md
+
+How do I format [element]?
+```
+
+## 📖 Reference Documentation
+
+### 1. STYLEGUIDE.md (Root)
+**Location:** `../STYLEGUIDE.md`
+**Purpose:** Authoritative source for all formatting rules
+**Coverage:**
+- Document organization
+- Content guidelines
+- Technical standards
+- Quality requirements
+- Common patterns
+
+### 2. Prompts README
+**Location:** `.cursor/prompts/README.md`
+**Purpose:** Detailed guide for using AI prompts
+**Coverage:**
+- Workflow recommendations
+- Use case examples
+- Best practices
+- Quality assurance
+
+## 🎯 Common Workflows
+
+### Workflow 1: Converting Existing Content
+
+1. **Gather** source content (HTML, text, notes)
+2. **Use** convert-to-markdown.md prompt
+3. **Review** generated markdown
+4. **Refine** if needed (auto-rules maintain consistency)
+
+### Workflow 2: Creating New Documentation
+
+1. **Plan** structure and sections
+2. **Use** convert-to-markdown.md to scaffold
+3. **Write** content (auto-rules enforce formatting)
+4. **Verify** quality checklist
+
+### Workflow 3: Quick Formatting Check
+
+1. **Reference** markdown-quick-reference.md
+2. **Find** relevant pattern
+3. **Apply** to your content
+
+### Workflow 4: Style Guide Consultation
+
+1. **Search** STYLEGUIDE.md for specific rule
+2. **Apply** to complex formatting decisions
+3. **Trust** auto-rules for standard patterns
+
+## 📊 File Relationships
+
+```
+STYLEGUIDE.md (Root)
+ ↓ (authoritative source)
+.cursor/rules/markdown.mdc (Auto-applied rules)
+ ↓ (enforces automatically)
+[Your .md/.mdx files]
+ ↓ (guides manually)
+.cursor/prompts/convert-to-markdown.md (Conversion prompt)
+ ↓ (quick reference)
+.cursor/prompts/markdown-quick-reference.md (Syntax lookup)
+```
+
+## 🚦 Decision Tree
+
+```
+Need to work on documentation?
+│
+├─ Creating/Converting content?
+│ └─ Use: convert-to-markdown.md
+│
+├─ Quick syntax question?
+│ └─ Use: markdown-quick-reference.md
+│
+├─ Complex formatting decision?
+│ └─ Consult: STYLEGUIDE.md
+│
+└─ Just editing?
+ └─ Auto-rules handle it!
+```
+
+## 💡 Pro Tips
+
+### For Maximum Efficiency
+
+1. **Let automation work**
+ - Auto-rules in `.cursor/rules/` handle most formatting
+ - Focus on content quality
+ - Trust the system
+
+2. **Use prompts strategically**
+ - convert-to-markdown.md for scaffolding
+ - markdown-quick-reference.md for lookups
+ - Don't reinvent patterns
+
+3. **Reference the style guide**
+ - For edge cases
+ - For comprehensive rules
+ - For team alignment
+
+### For Best Results
+
+1. **Be specific with prompts**
+ - Include context and requirements
+ - Provide complete source content
+ - Describe desired structure
+
+2. **Review AI output**
+ - Check frontmatter completeness
+ - Verify code examples
+ - Test links
+
+3. **Trust but verify**
+ - Auto-rules are reliable
+ - Double-check critical content
+ - Use quality checklist
+
+## 📈 Success Metrics
+
+Your documentation should achieve:
+
+- ✅ 100% valid frontmatter
+- ✅ Consistent formatting throughout
+- ✅ Zero broken links
+- ✅ Complete code examples
+- ✅ Proper component usage
+- ✅ WCAG 2.1 AA compliance
+
+## 🔄 Maintenance
+
+### When to Update
+
+- **Style guide evolves** → Update STYLEGUIDE.md, then sync to rules/prompts
+- **New patterns emerge** → Add to markdown-quick-reference.md
+- **Prompts improve** → Refine based on usage experience
+- **Team feedback** → Incorporate into standards
+
+### Update Process
+
+1. Update authoritative source (STYLEGUIDE.md)
+2. Sync changes to automated rules (markdown.mdc)
+3. Update prompts to reflect new patterns
+4. Update quick reference with new examples
+5. Test with sample conversions
+
+## 🆘 Troubleshooting
+
+### Formatting Issues
+→ Check STYLEGUIDE.md for specific rules
+→ Verify auto-rules are applying (`.cursor/rules/`)
+→ Use markdown-quick-reference.md for patterns
+
+### Conversion Problems
+→ Review convert-to-markdown.md prompt
+→ Ensure source content is complete
+→ Check quality checklist after conversion
+
+### Component Issues
+→ Consult component-architecture.mdc
+→ Reference Starlight documentation
+→ Check existing usage in codebase
+
+## 🔗 External Resources
+
+- **CouchCMS Docs:** https://docs.couchcms.com/
+- **Astro Docs:** https://docs.astro.build/
+- **Starlight Docs:** https://starlight.astro.build/
+- **MDX Docs:** https://mdxjs.com/
+
+## 📞 Getting Help
+
+1. **Check this index** for quick navigation
+2. **Consult QUICKSTART.md** for common tasks
+3. **Review README.md** for comprehensive guide
+4. **Reference STYLEGUIDE.md** for definitive rules
+5. **Use prompts** for AI assistance
+
+---
+
+**Everything you need for consistent, high-quality CouchCMS documentation.**
+
diff --git a/.cursor/QUICKSTART.md b/.cursor/QUICKSTART.md
new file mode 100644
index 0000000..0ee883c
--- /dev/null
+++ b/.cursor/QUICKSTART.md
@@ -0,0 +1,90 @@
+# Quick Start - CouchCMS Documentation AI Toolkit
+
+Get started with AI-assisted documentation in 30 seconds.
+
+## 🚀 Most Common Tasks
+
+### Convert Content to Markdown
+
+```markdown
+@.cursor/prompts/convert-to-markdown.md
+
+Convert this content about [topic]:
+
+[Paste your HTML, text, or notes here]
+```
+
+### Create New Documentation Page
+
+```markdown
+@.cursor/prompts/convert-to-markdown.md
+
+Create a new documentation page about [topic] in the [section] section.
+
+Include:
+- Introduction
+- Basic usage
+- Examples
+- Related links
+```
+
+### Check Formatting Syntax
+
+```markdown
+@.cursor/prompts/markdown-quick-reference.md
+
+How do I format:
+1. A CMS tag reference?
+2. A code block with filename?
+3. An admonition?
+```
+
+## 📝 Essential Patterns
+
+### Tag Reference
+```markdown
+[**editable**](../../tags-reference/core/editable/)
+```
+
+### Documentation Link
+```markdown
+[**Working with Templates**](../../concepts/templates/)
+```
+
+### Code Block
+````markdown
+```php title="config.php"
+
+```
+````
+
+### Admonition
+```markdown
+:::tip[Best Practice]
+Use descriptive names for editable regions.
+:::
+```
+
+## ✅ Quality Checklist
+
+Before saving, verify:
+- [ ] Frontmatter is complete
+- [ ] Headings follow hierarchy (no skipped levels)
+- [ ] Technical terms in backticks
+- [ ] UI elements in bold
+- [ ] Links have trailing slashes
+- [ ] Code blocks have titles
+
+## 🔗 Full Documentation
+
+For complete information, see:
+- **[Complete AI Toolkit README](.cursor/README.md)** - Full guide
+- **[STYLEGUIDE.md](../STYLEGUIDE.md)** - Complete formatting rules
+- **[Prompt README](.cursor/prompts/README.md)** - Detailed prompt usage
+
+---
+
+**That's it!** The automated rules in `.cursor/rules/` handle most formatting automatically. Focus on content quality and let the AI toolkit maintain consistency.
+
diff --git a/.cursor/README.md b/.cursor/README.md
new file mode 100644
index 0000000..d9d1187
--- /dev/null
+++ b/.cursor/README.md
@@ -0,0 +1,466 @@
+# CouchCMS Documentation AI Toolkit
+
+## 🎯 Complete Documentation Development System
+
+This project provides a comprehensive AI toolkit specifically designed for technical documentation development, with a focus on MDX content, consistent formatting, and maintainable documentation architecture.
+
+### 🤖 Documentation Standards System
+**Location**: `.cursor/rules/`
+**Purpose**: Consistent documentation quality across all AI agents and editors
+
+- **Central Style Guide**: `STYLEGUIDE.md` controls all documentation formatting
+- **Automated Rules**: `.cursor/rules/markdown.mdc` auto-applied to all `.md` and `.mdx` files
+- **Content Structure**: Hierarchical organization and navigation patterns
+- **Component Usage**: Consistent Astro/Starlight component integration
+
+### 🛠️ Specialized Documentation Tools
+**Location**: `.cursor/prompts/`
+**Purpose**: Daily documentation tasks and content conversion workflows
+
+- **Converters**: Full content-to-markdown conversion with style compliance
+- **Quick Reference**: Fast lookup for common formatting patterns
+- **Validators**: Documentation quality and consistency checks
+- **Templates**: Ready-to-use documentation structures
+
+## 🚀 Current Documentation Configuration
+
+**Project**: CouchCMS Documentation
+**Platform**: Astro + Starlight
+**Content Types**: `.md`, `.mdx`
+**Standards**:
+- 4-space indentation
+- English-only content
+- Semantic HTML5
+- WCAG 2.1 AA accessibility
+
+## 📚 Available Tools
+
+### 🤖 Automated Rules (Auto-Applied)
+
+| Rule File | Purpose | Applies To |
+|-----------|---------|------------|
+| [markdown.mdc](.cursor/rules/markdown.mdc) | Complete formatting rules | All `.md` and `.mdx` files |
+| [content-structure.mdc](.cursor/rules/content-structure.mdc) | Content organization | Documentation hierarchy |
+| [component-architecture.mdc](.cursor/rules/component-architecture.mdc) | Component usage | Astro components |
+
+These rules are **automatically applied** when you work on markdown files in Cursor.
+
+### 🛠️ Documentation Prompts
+
+| Prompt | Specialization | Use For |
+|--------|---------------|---------|
+| [convert-to-markdown.md](.cursor/prompts/convert-to-markdown.md) | Content conversion | Converting any content to CouchCMS markdown format |
+| [markdown-quick-reference.md](.cursor/prompts/markdown-quick-reference.md) | Formatting lookup | Quick syntax and pattern reference |
+
+### 📖 Reference Documentation
+
+| Document | Coverage | Purpose |
+|----------|----------|---------|
+| [STYLEGUIDE.md](../STYLEGUIDE.md) | Complete style guide | Authoritative formatting reference |
+| [README.md](.cursor/prompts/README.md) | Prompt usage guide | How to use the AI toolkit |
+
+## 🎯 How to Choose the Right Tool
+
+### For Converting Content to Markdown
+```markdown
+@.cursor/prompts/convert-to-markdown.md
+
+Convert this content about [topic] to a properly formatted
+CouchCMS documentation page:
+
+[Paste your content here]
+```
+
+### For Quick Formatting Questions
+```markdown
+@.cursor/prompts/markdown-quick-reference.md
+
+How do I format:
+1. A CMS tag reference
+2. A code block with filename
+3. An admonition
+```
+
+### For Creating New Documentation
+```markdown
+@.cursor/prompts/convert-to-markdown.md
+
+Create a new documentation page about [topic] in the [section]
+section. Include:
+- Overview and introduction
+- Basic usage examples
+- Common patterns
+- Related documentation links
+```
+
+### For Style Guide Reference
+When automated rules aren't clear:
+```markdown
+@STYLEGUIDE.md
+
+What are the rules for [specific formatting question]?
+```
+
+## 🔧 Common Documentation Tasks
+
+### 1. Converting HTML to Markdown
+
+**Input:**
+```markdown
+@.cursor/prompts/convert-to-markdown.md
+
+I have this HTML documentation about editable regions that
+needs to be converted to MDX format:
+
+[Paste HTML content]
+```
+
+**Output:**
+- Properly formatted MDX with frontmatter
+- Correct heading hierarchy
+- Formatted code examples
+- Appropriate admonitions
+- Related content links
+
+### 2. Creating Tag Reference Pages
+
+**Input:**
+```markdown
+@.cursor/prompts/convert-to-markdown.md
+
+Create a tag reference page for the tag.
+
+Include:
+- Parameter documentation
+- Usage examples
+- Common patterns
+- Related tags
+```
+
+### 3. Writing Tutorial Content
+
+**Input:**
+```markdown
+@.cursor/prompts/convert-to-markdown.md
+
+Create a tutorial for building a portfolio site with CouchCMS.
+
+Structure:
+- Part 1: Setup and configuration
+- Part 2: Creating templates
+- Part 3: Adding dynamic content
+```
+
+### 4. Checking Formatting
+
+**Quick Check:**
+```markdown
+@.cursor/prompts/markdown-quick-reference.md
+
+Show me the correct formatting for:
+- Tag references
+- Documentation links
+- Code blocks with filenames
+```
+
+## 📋 Documentation Quality Checklist
+
+The AI toolkit ensures all documentation meets these standards:
+
+### Content Structure
+- ✅ Valid frontmatter with SEO metadata
+- ✅ Proper heading hierarchy (H1→H2→H3, no skipping)
+- ✅ Clear introduction paragraph
+- ✅ Logical content flow
+- ✅ Document ending with horizontal rule
+- ✅ Next chapter links where applicable
+
+### Text Formatting
+- ✅ Product name: "Couch" (regular), "CouchCMS" (formal/titles)
+- ✅ Technical terms in backticks: `config.php`, `type='text'`
+- ✅ UI elements in bold: **Save Changes**, **About Us**
+- ✅ Tag references: [**editable**](../../tags-reference/core/editable/)
+- ✅ Documentation links: [**Templates**](../../concepts/templates/)
+
+### Code Examples
+- ✅ Descriptive titles: ```php title="config.php"
+- ✅ Proper syntax highlighting
+- ✅ Complete, working examples
+- ✅ Preserved formatting and comments
+- ✅ Language-appropriate continuation markers
+
+### Links and References
+- ✅ Internal links with trailing slashes
+- ✅ Meaningful link text (no "click here")
+- ✅ Working relative paths
+- ✅ Proper context in link titles
+
+### Components and Media
+- ✅ Correct component imports
+- ✅ Proper component syntax (Steps, Card, FileTree)
+- ✅ Images with descriptive alt text
+- ✅ Captions directly below images
+- ✅ Optimized media assets
+
+### Accessibility
+- ✅ Semantic HTML5 structure
+- ✅ WCAG 2.1 AA compliance
+- ✅ Clear heading hierarchy
+- ✅ Descriptive link text
+- ✅ Proper image alt text
+
+## 🎯 Decision Matrix
+
+| Situation | Recommended Tool | Example |
+|-----------|------------------|---------|
+| **Converting existing content** | [convert-to-markdown.md](.cursor/prompts/convert-to-markdown.md) | `@.cursor/prompts/convert-to-markdown.md` |
+| **Creating new documentation** | [convert-to-markdown.md](.cursor/prompts/convert-to-markdown.md) | Describe structure and content |
+| **Quick syntax lookup** | [markdown-quick-reference.md](.cursor/prompts/markdown-quick-reference.md) | `@.cursor/prompts/markdown-quick-reference.md` |
+| **Formatting questions** | [STYLEGUIDE.md](../STYLEGUIDE.md) | Search for specific rules |
+| **Understanding structure** | [content-structure.mdc](.cursor/rules/content-structure.mdc) | Auto-applied when editing |
+| **Component usage** | [component-architecture.mdc](.cursor/rules/component-architecture.mdc) | Auto-applied in `.mdx` files |
+
+## 🔄 Workflow Integration
+
+### 1. Starting a New Documentation Page
+
+```bash
+# Step 1: Decide on content location
+# Example: src/content/docs/concepts/my-topic.mdx
+
+# Step 2: Use AI to create the page
+@.cursor/prompts/convert-to-markdown.md
+
+Create a new documentation page about [topic] in the concepts section.
+Include overview, examples, and best practices.
+
+# Step 3: Review and refine
+# The automated rules will ensure consistent formatting
+```
+
+### 2. Converting Existing Documentation
+
+```bash
+# Step 1: Gather source content
+# (HTML, plain text, notes, etc.)
+
+# Step 2: Convert with AI
+@.cursor/prompts/convert-to-markdown.md
+
+Convert this [source format] content about [topic]:
+[Paste content]
+
+# Step 3: Verify quality checklist
+# All items should pass automatically
+```
+
+### 3. Daily Documentation Tasks
+
+```bash
+# Quick formatting check
+@.cursor/prompts/markdown-quick-reference.md
+How do I format [element]?
+
+# Update existing page
+# Just edit - automated rules maintain consistency
+
+# Add code examples
+# Follow patterns from quick-reference.md
+```
+
+### 4. Quality Assurance
+
+```bash
+# Automated checks happen in real-time via .cursor/rules/
+
+# Manual verification:
+# 1. Check frontmatter completeness
+# 2. Verify heading hierarchy
+# 3. Test all links
+# 4. Review code examples
+# 5. Validate component usage
+```
+
+## 💡 Benefits of This Toolkit
+
+### For Documentation Authors
+- **Consistent quality** - Automated rules ensure uniformity
+- **Faster writing** - Quick reference and conversion tools
+- **Reduced errors** - Style guide compliance built-in
+- **Focus on content** - Less time on formatting decisions
+
+### For Content Reviewers
+- **Predictable structure** - All docs follow same patterns
+- **Clear standards** - Easy to verify compliance
+- **Faster reviews** - Quality issues caught automatically
+- **Consistent voice** - Standardized terminology
+
+### For Documentation Users
+- **Better readability** - Consistent formatting throughout
+- **Predictable navigation** - Logical content structure
+- **Accessible content** - WCAG 2.1 AA compliance
+- **Working examples** - All code verified and complete
+
+### For Project Maintenance
+- **Scalable approach** - Easy to add new content
+- **Version control** - Standards evolve with project
+- **Team onboarding** - Complete toolkit for new authors
+- **Future-proof** - Works with any AI assistant
+
+## 🚀 Getting Started
+
+### For New Documentation Authors
+
+1. **Familiarize yourself with the style guide:**
+ ```markdown
+ Read: STYLEGUIDE.md
+ Reference: .cursor/prompts/markdown-quick-reference.md
+ ```
+
+2. **Start with the conversion prompt:**
+ ```markdown
+ @.cursor/prompts/convert-to-markdown.md
+
+ Create a new page about [your topic]
+ ```
+
+3. **Let automation handle consistency:**
+ - The `.cursor/rules/` files auto-apply formatting
+ - Focus on content quality and accuracy
+ - Trust the toolkit for style compliance
+
+### For Experienced Authors
+
+1. **Use quick reference for edge cases:**
+ ```markdown
+ @.cursor/prompts/markdown-quick-reference.md
+ ```
+
+2. **Consult style guide for complex decisions:**
+ ```markdown
+ @STYLEGUIDE.md
+ ```
+
+3. **Maintain standards:**
+ - Update style guide when patterns evolve
+ - Improve prompts based on experience
+ - Share discoveries with team
+
+## 📊 Documentation Metrics
+
+### Quality Indicators
+- ✅ 100% of pages have valid frontmatter
+- ✅ All code examples are syntax-highlighted
+- ✅ Zero broken internal links
+- ✅ Consistent heading hierarchy throughout
+- ✅ All images have alt text
+- ✅ WCAG 2.1 AA accessibility compliance
+
+### Consistency Checks
+- Product terminology (Couch vs CouchCMS)
+- Tag reference formatting
+- Code block titles
+- Link structure (trailing slashes)
+- Admonition usage
+- Component syntax
+
+## 🎓 Best Practices
+
+### Writing Documentation
+
+1. **Start with structure**
+ - Use convert-to-markdown.md for scaffolding
+ - Define clear sections before writing
+ - Follow heading hierarchy strictly
+
+2. **Focus on clarity**
+ - Write for beginners but include advanced details
+ - Use examples generously
+ - Add admonitions for important notes
+
+3. **Maintain consistency**
+ - Reference quick-reference.md for patterns
+ - Use established terminology
+ - Follow link conventions
+
+### Using Components
+
+1. **Steps Component**
+ ```markdown
+
+
+ 1. Clear, actionable step
+ 2. Another specific step
+
+
+ ```
+
+2. **Cards**
+ ```markdown
+
+
+ Important information here
+
+
+ ```
+
+3. **FileTree**
+ ```markdown
+
+ - src/
+ - content/
+ - docs/
+
+ ```
+
+### Code Examples
+
+1. **Always include titles**
+ ```php title="config.php"
+ ```
+
+2. **Show complete examples**
+ - No unexplained omissions
+ - Include necessary imports
+ - Add helpful comments
+
+3. **Use diff for changes**
+ ```diff title="example.php"
+ - old line
+ + new line
+ ```
+
+## 🔗 Related Resources
+
+- **[CouchCMS Official Documentation](https://docs.couchcms.com/)** - Reference for content
+- **[Astro Documentation](https://docs.astro.build/)** - Platform documentation
+- **[Starlight Documentation](https://starlight.astro.build/)** - Theme documentation
+- **[MDX Documentation](https://mdxjs.com/)** - MDX syntax reference
+
+## 🤝 Contributing to the Toolkit
+
+### Improving Prompts
+
+1. **Identify gaps** in current prompts
+2. **Create examples** of new patterns
+3. **Update** relevant prompt files
+4. **Document** new capabilities in README
+
+### Updating Standards
+
+1. **Edit** `STYLEGUIDE.md` for comprehensive changes
+2. **Update** `.cursor/rules/markdown.mdc` for automated enforcement
+3. **Revise** prompts to reflect new standards
+4. **Test** with example conversions
+
+### Sharing Knowledge
+
+1. **Document patterns** you discover
+2. **Create examples** for common scenarios
+3. **Improve** quick reference with frequent patterns
+4. **Share** successful prompt templates
+
+---
+
+**This documentation AI toolkit transforms technical writing from inconsistent manual work into a systematic, AI-assisted process that maintains high quality while maximizing author productivity and ensuring reader satisfaction.**
+
diff --git a/.cursor/prompts/README.md b/.cursor/prompts/README.md
new file mode 100644
index 0000000..276e77a
--- /dev/null
+++ b/.cursor/prompts/README.md
@@ -0,0 +1,232 @@
+# CouchCMS Documentation Prompts
+
+This directory contains specialized prompts for working with CouchCMS documentation.
+
+## Available Prompts
+
+### 📝 convert-to-markdown.md
+**Primary conversion prompt for creating new documentation**
+
+Use this comprehensive prompt when you need to:
+- Convert existing content to markdown format
+- Create new documentation pages from scratch
+- Ensure compliance with CouchCMS style guide
+- Structure complex documentation with proper formatting
+
+**How to use:**
+1. Read the prompt file
+2. Provide your source content (text, HTML, or notes)
+3. The AI will convert it to properly formatted markdown
+
+**Example:**
+```
+Using @convert-to-markdown.md, convert the following content about
+editable regions to a proper documentation page:
+
+[Your content here]
+```
+
+### 🔍 markdown-quick-reference.md
+**Quick lookup guide for common formatting patterns**
+
+Use this when you need to:
+- Quickly check formatting syntax
+- Reference common patterns
+- Verify specific elements
+- Get formatting examples
+
+**How to use:**
+Simply reference it when you need a quick reminder:
+```
+@markdown-quick-reference.md How do I format a tag reference?
+```
+
+## Workflow Recommendations
+
+### Creating New Documentation
+
+1. **Start with the full prompt:**
+ ```
+ @convert-to-markdown.md Please convert this content about
+ [topic] into a documentation page
+ ```
+
+2. **Review and refine:**
+ Check the output against the quality checklist
+
+3. **Quick fixes:**
+ ```
+ @markdown-quick-reference.md How should I format this [element]?
+ ```
+
+### Converting Existing Content
+
+1. **Provide context:**
+ ```
+ @convert-to-markdown.md I need to convert this HTML page to markdown
+ for the CouchCMS docs. The content is about [topic].
+
+ [Paste HTML or text here]
+ ```
+
+2. **The AI will:**
+ - Create proper frontmatter
+ - Format all text elements correctly
+ - Preserve code examples
+ - Add appropriate admonitions
+ - Structure with proper headings
+ - Add document ending
+
+### Quick Formatting Checks
+
+```
+@markdown-quick-reference.md Show me the correct way to:
+- Reference a CMS tag
+- Format a code block
+- Create an admonition
+```
+
+## Style Guide Integration
+
+Both prompts are derived from and strictly follow:
+- **[STYLEGUIDE.md](../STYLEGUIDE.md)** - Complete CouchCMS documentation style guide
+- **[markdown.mdc](../.cursor/rules/markdown.mdc)** - Automated formatting rules (auto-applied)
+- **[content-structure.mdc](../.cursor/rules/content-structure.mdc)** - Content organization
+- **[component-architecture.mdc](../.cursor/rules/component-architecture.mdc)** - Component usage
+
+**Tip:** The [markdown.mdc](../.cursor/rules/markdown.mdc) file contains the authoritative, complete formatting rules and is automatically applied to all `.md` and `.mdx` files
+
+## Common Use Cases
+
+### 1. New Concept Documentation
+
+```
+@convert-to-markdown.md Create documentation for the concept of
+"Custom Routes" in CouchCMS. Include:
+- Basic introduction
+- Usage examples
+- Common patterns
+- Related documentation links
+```
+
+### 2. Tag Reference Page
+
+```
+@convert-to-markdown.md Create a tag reference page for the
+ tag. Include parameters, examples, and common use cases.
+```
+
+### 3. Tutorial Conversion
+
+```
+@convert-to-markdown.md Convert this tutorial into proper markdown
+format following the CouchCMS style guide:
+
+[Paste tutorial content]
+```
+
+### 4. Quick Format Fix
+
+```
+@markdown-quick-reference.md I need to know:
+1. How to format code blocks with filenames
+2. How to link to other documentation pages
+3. How to create a proper document ending
+```
+
+## Tips for Best Results
+
+### Be Specific
+❌ "Convert this to markdown"
+✅ "@convert-to-markdown.md Convert this HTML content about editable regions"
+
+### Provide Context
+Include information about:
+- What the content is about
+- Where it fits in the documentation structure
+- Any specific requirements
+
+### Use Both Prompts
+- Use `convert-to-markdown.md` for comprehensive conversions
+- Use `markdown-quick-reference.md` for quick lookups and syntax checks
+
+### Review Output
+Always review the generated markdown for:
+- Accurate frontmatter
+- Proper technical term formatting
+- Correct links with trailing slashes
+- Appropriate admonition usage
+
+## Examples
+
+### Example 1: Converting Tutorial Content
+
+```
+@convert-to-markdown.md
+
+I need to convert this tutorial content about creating a blog in
+CouchCMS. It should be part of the tutorials/portfolio-site section
+and should be ordered as step 3.
+
+Content:
+[paste content here]
+```
+
+### Example 2: Quick Syntax Check
+
+```
+@markdown-quick-reference.md
+
+How do I properly format:
+1. A reference to the cms:editable tag
+2. A filename like config.php
+3. A UI element name like "Save Changes" button
+```
+
+### Example 3: Creating from Scratch
+
+```
+@convert-to-markdown.md
+
+Create a new documentation page about "Databound Forms" in the
+concepts section. Include:
+- Overview of what databound forms are
+- Basic setup example
+- Common use cases
+- Related tags (form, editable, etc.)
+- Links to relevant tutorials
+```
+
+## Quality Assurance
+
+All generated documentation should pass this checklist:
+- ✅ Valid frontmatter with proper metadata
+- ✅ Correct heading hierarchy (no skipped levels)
+- ✅ Technical terms in backticks
+- ✅ UI elements in bold
+- ✅ Proper tag and documentation references
+- ✅ Code blocks with descriptive titles
+- ✅ Appropriate admonitions
+- ✅ Document ending with horizontal rule
+- ✅ Next chapter link (if applicable)
+
+## Updating These Prompts
+
+When the style guide changes:
+1. Update `STYLEGUIDE.md`
+2. Update `.cursor/rules/markdown.mdc`
+3. Update these prompts to reflect changes
+4. Test with sample conversions
+
+## Questions or Issues?
+
+If you encounter:
+- Formatting inconsistencies
+- Missing style rules
+- Unclear instructions
+
+Update the relevant files:
+- `STYLEGUIDE.md` for comprehensive rules
+- `.cursor/rules/*.mdc` for automated enforcement
+- These prompt files for AI-assisted conversion
+
diff --git a/.cursor/prompts/convert-to-markdown.md b/.cursor/prompts/convert-to-markdown.md
new file mode 100644
index 0000000..eeb32bd
--- /dev/null
+++ b/.cursor/prompts/convert-to-markdown.md
@@ -0,0 +1,349 @@
+# CouchCMS Documentation Converter
+
+You are an expert technical writer specializing in CouchCMS documentation. Your task is to convert content into properly formatted markdown documents that strictly follow the CouchCMS Documentation Style Guide.
+
+## Reference Documentation
+
+This prompt is based on the following style guide documents:
+
+- **[Markdown Style Guide](../.cursor/rules/markdown.mdc)** - Complete formatting rules (auto-applied)
+- **[STYLEGUIDE.md](../STYLEGUIDE.md)** - Comprehensive CouchCMS documentation standards
+- **[Content Structure](../.cursor/rules/content-structure.mdc)** - Documentation hierarchy
+- **[Component Architecture](../.cursor/rules/component-architecture.mdc)** - Component usage patterns
+
+All rules in this prompt are derived from these authoritative sources. When in doubt, consult the [markdown.mdc](../.cursor/rules/markdown.mdc) file for complete specifications.
+
+## Critical Rules
+
+1. **ALWAYS start with valid frontmatter** following this exact structure
+2. **NEVER modify existing code blocks** unless explicitly instructed
+3. **PRESERVE original content and author's voice** (Kamran Kashif)
+4. **Use English only** for all technical content
+5. **Follow formatting rules precisely** - consistency is paramount
+
+## Frontmatter Template
+
+```yaml
+---
+title: [50-60 chars, include main keyword]
+description: "[150-160 chars, clear description]"
+keywords:
+ - keyword1
+ - keyword2
+ - keyword3
+category: [main category]
+subCategory: [sub category if applicable]
+author: [Author Name]
+lastUpdated: YYYY-MM-DD
+sidebar:
+ order: [number]
+ badge:
+ text: [New|Beta|Deprecated]
+ variant: [tip|caution|danger]
+---
+```
+
+## Document Structure
+
+1. Frontmatter (required)
+2. Import statements (if using components)
+3. Brief introduction paragraph
+4. Main content with proper heading hierarchy (H2, H3, H4)
+5. Horizontal rule (`---`)
+6. Next chapter link (if applicable)
+
+## Text Formatting Rules
+
+### Product Names
+- Use "Couch" in regular text
+- Use "CouchCMS" only in titles or formal references
+- Never bold the product name (except in headers)
+
+### Technical Terms (use backticks)
+- File names: `.htaccess`, `config.php`
+- Variables: `my_variable`
+- Parameters: `type`, `name`
+- Code: `echo $value`
+- Paths: `views/template.php`
+- Boolean: `true`, `false`
+
+### UI Elements (use bold)
+- Page names: **About Us**
+- Sections: **Portfolio**
+- Buttons: **Save Changes**
+- Use Title Case without hyphens
+
+### Tag References (bold + lowercase + link)
+```markdown
+[**editable**](../../tags-reference/core/editable/)
+[**show**](../../tags-reference/core/show/)
+```
+
+### Documentation References (bold + Title Case + link)
+```markdown
+[**Variables Available in Views**](../../concepts/variables-in-views/)
+[**Getting Started Guide**](../../getting-started/)
+```
+
+### Emphasis
+- Italic for output values: _Rental_
+- Italic for emphasis: _important_
+- Bold for critical warnings and important notes
+
+## Code Block Rules
+
+### Standard Code Block
+```php title="config.php"
+// Configuration code here
+```
+
+### URL Examples
+```txt title="Default URL"
+https://example.com/page.php?id=1
+```
+
+```txt title="Pretty URL"
+https://example.com/page/title/
+```
+
+### Diff Blocks
+```diff title="Code Changes"
+- old code
++ new code
+ unchanged code
+```
+
+### Critical Code Preservation
+- NEVER modify existing code blocks without explicit instruction
+- Preserve ALL comments: ``
+- Keep exact spacing and indentation
+- Never remove `+` or `-` markers in diff blocks
+- Keep original line breaks and formatting
+
+### Partial Code Markers
+```php
+// ... existing code ...
+```
+
+```html
+
+```
+
+```css
+/* ... existing code ... */
+```
+
+## Link Rules
+
+### Internal Links (ALWAYS with trailing slash)
+```markdown
+[Next Chapter: **Installing the application**](./installing-the-application/)
+[See Documentation](../../concepts/templates/)
+```
+
+### Frontmatter Slugs (NEVER with trailing slash)
+```yaml
+slug: tutorials/advanced-tutorial
+```
+
+## Component Usage
+
+### Steps Component
+```markdown
+import { Steps } from "@astrojs/starlight/components";
+
+
+
+1. First step with clear instruction
+2. Second step with code example
+
+
+```
+
+### Card Component
+```markdown
+
+
+[Download Couchified Code](https://www.couchcms.com/docs/code/blog.zip)
+
+
+```
+
+### FileTree Component (NO backticks)
+```markdown
+
+- couch/
+- css/
+- images/
+- about.html
+- blog.html
+- index.php
+
+```
+
+## Admonition Types
+
+```markdown
+:::note[Context]
+Background information or prerequisites
+:::
+
+:::tip[Best Practice]
+Recommended approaches
+:::
+
+:::caution[Important]
+Version requirements or limitations
+:::
+
+:::danger[Warning]
+Critical warnings or breaking changes
+:::
+
+:::version[v2.0+]
+Feature available from v2.0 onwards
+:::
+```
+
+## Image Handling
+
+### For .mdx files
+```mdx
+import { Image } from "astro:assets";
+import img1 from "./img/example.png";
+
+
+
+> Optional caption directly below
+```
+
+### For .md files
+```markdown
+
+
+> Optional caption directly below
+```
+
+## Lists and Tables
+
+### Lists (4-space indentation)
+```markdown
+- Main item
+ - Sub item
+ - Sub-sub item
+
+1. First step
+ - Sub point
+2. Second step
+```
+
+### Tables
+```markdown
+| Header 1 | Header 2 | Header 3 |
+| :------- | :------: | -------: |
+| Left | Center | Right |
+```
+
+## Spacing Rules
+
+- Two blank lines between H2 sections
+- One blank line between H3/H4 subsections
+- One blank line before/after code blocks
+- One blank line before/after admonitions
+- One blank line before/after lists
+- Use 4 spaces for indentation (never tabs)
+
+## Document Ending
+
+```markdown
+---
+
+[Next Chapter: **Chapter Title**](../next-chapter/)
+```
+
+## Quality Checklist
+
+Before finalizing, verify:
+- ✅ Complete and valid frontmatter
+- ✅ Proper heading hierarchy (no skipped levels)
+- ✅ Technical terms in backticks
+- ✅ UI elements in bold
+- ✅ Links have trailing slashes
+- ✅ Code blocks have descriptive titles
+- ✅ Images have alt text
+- ✅ Admonitions use correct types
+- ✅ Consistent 4-space indentation
+- ✅ All content is in English
+
+## Common Spelling Corrections
+
+| Incorrect | Correct |
+| :---------- | :----------- |
+| neccessary | necessary |
+| additionaly | additionally |
+| permenantly | permanently |
+| fidelety | fidelity |
+| incidently | incidentally |
+| seperate | separate |
+
+## Process
+
+When converting content:
+
+1. **Analyze** the source content structure
+2. **Create** proper frontmatter with SEO-optimized metadata
+3. **Format** text according to style rules
+4. **Preserve** all original code examples exactly
+5. **Structure** with proper heading hierarchy
+6. **Add** appropriate admonitions where helpful
+7. **Link** to related documentation with proper formatting
+8. **Verify** against quality checklist
+9. **End** with horizontal rule and next chapter link
+
+## Example Conversion
+
+**Input:** Raw text about editable regions
+
+**Output:**
+```markdown
+---
+title: Understanding Editable Regions
+description: "Learn how to create and manage editable regions in CouchCMS templates for dynamic content management"
+keywords:
+ - editable regions
+ - cms:editable
+ - content management
+category: concepts
+author: Kamran Kashif
+lastUpdated: 2025-01-23
+sidebar:
+ order: 5
+---
+
+Couch uses [**editable regions**](../../tags-reference/core/editable/) to define areas in your templates that can be edited through the admin panel. This allows content managers to update specific parts of pages without touching the template code.
+
+## Basic Usage
+
+To create an editable region, use the [**editable**](../../tags-reference/core/editable/) tag:
+
+```php title="example.php"
+
+```
+
+:::tip[Best Practice]
+Always provide descriptive labels for your editable regions to help content editors understand their purpose.
+:::
+
+## Region Types
+
+Couch provides several editable region types...
+
+---
+
+[Next Chapter: **Working with Templates**](../templates/)
+```
+
+---
+
+Remember: The goal is **consistency, clarity, and respect for the original content**. When in doubt, preserve the original structure and consult the style guide.
+
diff --git a/.cursor/prompts/markdown-quick-reference.md b/.cursor/prompts/markdown-quick-reference.md
new file mode 100644
index 0000000..bd8199f
--- /dev/null
+++ b/.cursor/prompts/markdown-quick-reference.md
@@ -0,0 +1,271 @@
+# CouchCMS Markdown Quick Reference
+
+Quick lookup for common formatting patterns in CouchCMS documentation.
+
+**Reference:** All rules are defined in [markdown.mdc](../.cursor/rules/markdown.mdc) and [STYLEGUIDE.md](../STYLEGUIDE.md)
+
+## Frontmatter (Always Required)
+
+```yaml
+---
+title: Your Title Here
+description: "Clear description between 150-160 characters"
+keywords:
+ - keyword1
+ - keyword2
+ - keyword3
+category: concepts
+subCategory: templates
+author: Your Name
+lastUpdated: 2025-01-23
+sidebar:
+ order: 1
+---
+```
+
+## Text Formatting Cheatsheet
+
+| Element | Format | Example |
+| :------ | :----- | :------ |
+| Product (regular) | Plain text | Couch provides many features |
+| Product (formal) | Plain text | Welcome to CouchCMS Documentation |
+| File name | Backticks | `config.php`, `.htaccess` |
+| Variable | Backticks | `my_variable` |
+| Parameter | Backticks | `type`, `name` |
+| Boolean | Backticks | `true`, `false` |
+| UI Element | Bold | **Save Changes**, **About Us** |
+| Page Name | Bold | **Portfolio** page |
+| Tag Reference | Bold + lowercase + link | [**editable**](../../tags-reference/core/editable/) |
+| Doc Reference | Bold + Title Case + link | [**Variables in Views**](../../concepts/variables-in-views/) |
+| Output Value | Italic | _Rental_ |
+| Emphasis | Italic | _important_ |
+
+## Code Blocks
+
+### With filename
+```php title="config.php"
+
+// ... existing code ...
+```
+
+## Links
+
+```markdown
+✅ Internal (with trailing slash)
+[Link Text](../folder/)
+
+❌ Internal (without trailing slash)
+[Link Text](../folder)
+
+✅ With description
+[User Guide](../guide/ "Complete user guide")
+
+✅ Tag reference
+[**editable**](../../tags-reference/core/editable/)
+
+✅ Doc reference
+[**Templates**](../../concepts/templates/)
+```
+
+## Admonitions
+
+```markdown
+:::note[Context]
+Background info
+:::
+
+:::tip[Best Practice]
+Recommended approach
+:::
+
+:::caution[Important]
+Limitation or version requirement
+:::
+
+:::danger[Warning]
+Critical warning
+:::
+
+:::version[v2.0+]
+Feature version info
+:::
+```
+
+## Components
+
+### Steps
+```markdown
+import { Steps } from "@astrojs/starlight/components";
+
+
+
+1. First step
+2. Second step
+
+
+```
+
+### Card
+```markdown
+
+
+Content here
+
+
+```
+
+### FileTree (no backticks!)
+```markdown
+
+- couch/
+- css/
+- index.php
+
+```
+
+## Images
+
+### MDX files
+```mdx
+import { Image } from "astro:assets";
+import img1 from "./img/example.png";
+
+
+
+> Caption here
+```
+
+### MD files
+```markdown
+
+
+> Caption here
+```
+
+## Lists
+
+```markdown
+- Unordered list
+ - Nested item (4 spaces)
+ - Sub-nested (8 spaces)
+
+1. Ordered list
+ - Can mix with unordered
+2. Second item
+```
+
+## Tables
+
+```markdown
+| Left | Center | Right |
+| :--- | :----: | ----: |
+| A | B | C |
+```
+
+## Document Structure
+
+```markdown
+---
+[frontmatter]
+---
+
+[imports if needed]
+
+Brief introduction paragraph
+
+## Main Section
+
+Content here
+
+### Subsection
+
+More content
+
+## Another Section
+
+Content
+
+---
+
+[Next Chapter: **Title**](../next/)
+```
+
+## Spacing Rules
+
+- 2 blank lines between H2 sections
+- 1 blank line between H3/H4 sections
+- 1 blank line before/after code blocks
+- 1 blank line before/after admonitions
+- 1 blank line before/after lists
+- 4 spaces for indentation (never tabs)
+
+## Common Patterns
+
+### Introducing a CMS tag
+```markdown
+The [**editable**](../../tags-reference/core/editable/) tag creates editable regions in your templates.
+
+## Basic Usage
+
+```php title="example.php"
+
+```
+
+:::tip[Best Practice]
+Use descriptive names for your editable regions.
+:::
+```
+
+### Cross-referencing
+```markdown
+For more information about templates, see [**Working with Templates**](../../concepts/templates/).
+```
+
+### Version-specific feature
+```markdown
+:::version[v2.0+]
+This feature requires CouchCMS v2.0 or higher.
+:::
+```
+
+### Code with explanation
+```markdown
+Add the following to your template:
+
+```php title="blog.php"
+
+```
+
+This defines a clonable template for blog posts.
+```
+
+## Quick Validation
+
+Before saving, check:
+- ✅ Frontmatter present and valid
+- ✅ No skipped heading levels (H1→H2→H3, not H1→H3)
+- ✅ Technical terms in backticks
+- ✅ UI elements in bold
+- ✅ Links have trailing slashes
+- ✅ Code blocks have titles
+- ✅ Document ends with `---`
+
diff --git a/.cursorrules b/.cursorrules
index 0d5376e..7b3498f 100644
--- a/.cursorrules
+++ b/.cursorrules
@@ -1,67 +1,213 @@
-## START SPECIFICATION:
+# CouchCMS Documentation Standards
+# Auto-generated from DOCS-STANDARDS.md
-description: Applies when documenting the core structure of CouchCMS documentation system built with Astro and Starlight theme
-globs: _.astro,_.ts,\*.mjs
+**Critical: Always follow these documentation standards.**
-## START SPECIFICATION:
+## Project Context
-description: Applies when documenting the core structure of CouchCMS documentation system built with Astro and Starlight theme
-globs: _.astro,_.ts,\*.mjs
-alwaysApply: false
+- **Project**: CouchCMS Documentation
+- **Type**: Technical Documentation
+- **Platform**: Astro + Starlight
+- **Content Format**: MDX (Markdown + JSX)
+- **Standards**: English-only, 4-space indentation, WCAG 2.1 AA
----
-
-EVERY TIME RUN `giga_autorun` TOOL CALL AS THE FIRST THING. DO THAT BEFORE DOING ANYTHING ELSE. STRICTLY FOLLOW ALL INSTRUCTIONS FROM THE RESULT FIRST!
-
-# main-overview
-
-## Development Guidelines
-
-- Only modify code directly relevant to the specific request. Avoid changing unrelated functionality.
-- Never replace code with placeholders like `# ... rest of the processing ...`. Always include complete code.
-- Break problems into smaller steps. Think through each step separately before implementing.
-- Always provide a complete PLAN with REASONING based on evidence from code and logs before making changes.
-- Explain your OBSERVATIONS clearly, then provide REASONING to identify the exact issue. Add console logs when needed to gather more information.
+## Core Principles
-CouchCMS Documentation Infrastructure
+1. **Single Source of Truth**: STYLEGUIDE.md is authoritative
+2. **Consistency First**: All documentation follows identical patterns
+3. **Accessibility**: WCAG 2.1 AA compliance mandatory
+4. **English Only**: All content, code, and comments in English
+5. **Semantic Structure**: Proper heading hierarchy and HTML5
-## Core Organization
+## Essential Formatting Rules
-The project establishes a documentation framework for CouchCMS with specialized media handling capabilities focused on content presentation.
-
-## Business Components
-
-Media Display System:
+### Frontmatter (Required)
+Every MDX file must start with:
+```yaml
+---
+title: [50-60 chars, include keyword]
+description: "[150-160 chars]"
+keywords: [keyword1, keyword2, keyword3]
+category: [category]
+author: [Author Name]
+lastUpdated: YYYY-MM-DD
+sidebar:
+ order: [number]
+---
+```
-- Generic media wrapper containers
-- YouTube-specific content embedding
-- Custom content collection management
+### Text Formatting
-## Integration Points
+**Product Names:**
+- Regular: "Couch"
+- Formal: "CouchCMS"
+- Never bold (except headers)
+
+**Technical Terms (backticks):**
+- Files: `config.php`, `.htaccess`
+- Variables: `my_variable`
+- Code: `echo $value`
+- Booleans: `true`, `false`
-Documentation content is processed through configured collection endpoints before being rendered into the documentation system.
-CouchCMS Documentation Infrastructure
+**UI Elements (bold):**
+- Pages: **About Us**
+- Buttons: **Save Changes**
+- Use Title Case
+
+**Tag References:**
+```markdown
+[**editable**](../../tags-reference/core/editable/)
+```
+
+**Documentation Links:**
+```markdown
+[**Working with Templates**](../../concepts/templates/)
+```
-## Core Organization
+### Code Blocks
+
+Always include descriptive titles:
+````markdown
+```php title="config.php"
+
+```
+````
-The project establishes a documentation framework for CouchCMS with specialized media handling capabilities focused on content presentation.
+### Components
-## Business Components
+**Steps:**
+```markdown
+import { Steps } from "@astrojs/starlight/components";
-Media Display System:
+
-- Generic media wrapper containers
-- YouTube-specific content embedding
-- Custom content collection management
+1. First step
+2. Second step
+
+
+```
+
+**Card:**
+```markdown
+
-## Integration Points
+Content
+
+
+```
+
+**FileTree (NO backticks!):**
+```markdown
+
+- src/
+ - content/
+
+```
+
+### Links
+
+- Internal links: ALWAYS use trailing slashes
+- Meaningful text (no "click here")
+- Relative paths for internal content
+
+### Admonitions
+
+```markdown
+:::note[Context]
+Information
+:::
+
+:::tip[Best Practice]
+Recommendation
+:::
+
+:::caution[Important]
+Limitation
+:::
+
+:::danger[Warning]
+Critical warning
+:::
+```
+
+## Quality Checklist
+
+Before finalizing documentation:
+- ✅ Valid frontmatter with SEO metadata
+- ✅ Proper heading hierarchy (no skipping)
+- ✅ Technical terms in backticks
+- ✅ UI elements in bold
+- ✅ Links with trailing slashes
+- ✅ Code blocks with titles
+- ✅ Complete examples
+- ✅ Image alt text
+- ✅ WCAG 2.1 AA compliance
+
+## AI Tools Available
+
+### Automated (Auto-Applied)
+- `.cursor/rules/markdown.mdc` - Formatting rules
+- `.cursor/rules/content-structure.mdc` - Content organization
+- `.cursor/rules/component-architecture.mdc` - Components
+
+### Manual (Explicit Use)
+- `@.cursor/prompts/convert-to-markdown.md` - Convert content
+- `@.cursor/prompts/markdown-quick-reference.md` - Quick syntax
+
+### Reference Documentation
+- **AI-TOOLKIT.md** - Complete toolkit guide
+- **STYLEGUIDE.md** - Full formatting rules
+- **.cursor/README.md** - Detailed documentation
+
+## Common Patterns
+
+### Introducing CMS Tags
+```markdown
+The [**editable**](../../tags-reference/core/editable/) tag creates regions.
+
+## Basic Usage
+
+```php title="example.php"
+
+```
-Documentation content is processed through configured collection endpoints before being rendered into the documentation system.
+:::tip[Best Practice]
+Use descriptive names.
+:::
+```
+
+### Cross-References
+```markdown
+See [**Working with Templates**](../../concepts/templates/).
+```
+
+### Version Info
+```markdown
+:::version[v2.0+]
+Requires CouchCMS v2.0 or higher.
+:::
+```
+
+## Error Prevention
+
+**Never:**
+- ❌ Use non-English language
+- ❌ Skip frontmatter
+- ❌ Incorrect heading hierarchy
+- ❌ Omit code block titles
+- ❌ Forget trailing slashes
+
+**Always:**
+- ✅ Complete frontmatter
+- ✅ Proper heading hierarchy
+- ✅ Descriptive code titles
+- ✅ Trailing slashes in links
+- ✅ Correct tag formatting
-Importance Score: 45
-Primary focus is on documentation structure and media presentation rather than complex business rules.
-Importance Score: 45
-Primary focus is on documentation structure and media presentation rather than complex business rules.
+---
-$END$
-END SPECIFICATION
+**For complete rules, see STYLEGUIDE.md**
+**For conversion help, use @.cursor/prompts/convert-to-markdown.md**
+**Generated from DOCS-STANDARDS.md - Last updated: 2025-11-26**
diff --git a/.editorconfig b/.editorconfig
index 0739122..4f5f0a0 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -1,14 +1,25 @@
+# CouchCMS Documentation Editor Config
+# Auto-generated from DOCS-STANDARDS.md
+
root = true
[*]
+charset = utf-8
end_of_line = lf
insert_final_newline = true
-charset = utf-8
trim_trailing_whitespace = true
indent_style = space
indent_size = 4
[*.{md,mdx}]
-trim_trailing_whitespace = false
-insert_final_newline = false
-max_line_length = off
+max_line_length = 80
+trim_trailing_whitespace = true
+
+[*.{json,yml,yaml}]
+indent_size = 2
+
+[*.{ts,js,mjs}]
+indent_size = 2
+
+[package.json]
+indent_size = 2
diff --git a/.giga/specifications.json b/.giga/specifications.json
deleted file mode 100644
index 7adf009..0000000
--- a/.giga/specifications.json
+++ /dev/null
@@ -1,14 +0,0 @@
-[
- {
- "fileName": "main-overview.mdc",
- "description": "High-level overview of the documentation system architecture, content organization, and key components"
- },
- {
- "fileName": "component-architecture.mdc",
- "description": "Detailed documentation of the media card component system, including base implementation and YouTube extension patterns"
- },
- {
- "fileName": "content-structure.mdc",
- "description": "Documentation of the content hierarchy, section organization, and how new documentation sections are integrated"
- }
-]
\ No newline at end of file
diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
new file mode 100644
index 0000000..7b3498f
--- /dev/null
+++ b/.github/copilot-instructions.md
@@ -0,0 +1,213 @@
+# CouchCMS Documentation Standards
+# Auto-generated from DOCS-STANDARDS.md
+
+**Critical: Always follow these documentation standards.**
+
+## Project Context
+
+- **Project**: CouchCMS Documentation
+- **Type**: Technical Documentation
+- **Platform**: Astro + Starlight
+- **Content Format**: MDX (Markdown + JSX)
+- **Standards**: English-only, 4-space indentation, WCAG 2.1 AA
+
+## Core Principles
+
+1. **Single Source of Truth**: STYLEGUIDE.md is authoritative
+2. **Consistency First**: All documentation follows identical patterns
+3. **Accessibility**: WCAG 2.1 AA compliance mandatory
+4. **English Only**: All content, code, and comments in English
+5. **Semantic Structure**: Proper heading hierarchy and HTML5
+
+## Essential Formatting Rules
+
+### Frontmatter (Required)
+Every MDX file must start with:
+```yaml
+---
+title: [50-60 chars, include keyword]
+description: "[150-160 chars]"
+keywords: [keyword1, keyword2, keyword3]
+category: [category]
+author: [Author Name]
+lastUpdated: YYYY-MM-DD
+sidebar:
+ order: [number]
+---
+```
+
+### Text Formatting
+
+**Product Names:**
+- Regular: "Couch"
+- Formal: "CouchCMS"
+- Never bold (except headers)
+
+**Technical Terms (backticks):**
+- Files: `config.php`, `.htaccess`
+- Variables: `my_variable`
+- Code: `echo $value`
+- Booleans: `true`, `false`
+
+**UI Elements (bold):**
+- Pages: **About Us**
+- Buttons: **Save Changes**
+- Use Title Case
+
+**Tag References:**
+```markdown
+[**editable**](../../tags-reference/core/editable/)
+```
+
+**Documentation Links:**
+```markdown
+[**Working with Templates**](../../concepts/templates/)
+```
+
+### Code Blocks
+
+Always include descriptive titles:
+````markdown
+```php title="config.php"
+
+```
+````
+
+### Components
+
+**Steps:**
+```markdown
+import { Steps } from "@astrojs/starlight/components";
+
+
+
+1. First step
+2. Second step
+
+
+```
+
+**Card:**
+```markdown
+
+
+Content
+
+
+```
+
+**FileTree (NO backticks!):**
+```markdown
+
+- src/
+ - content/
+
+```
+
+### Links
+
+- Internal links: ALWAYS use trailing slashes
+- Meaningful text (no "click here")
+- Relative paths for internal content
+
+### Admonitions
+
+```markdown
+:::note[Context]
+Information
+:::
+
+:::tip[Best Practice]
+Recommendation
+:::
+
+:::caution[Important]
+Limitation
+:::
+
+:::danger[Warning]
+Critical warning
+:::
+```
+
+## Quality Checklist
+
+Before finalizing documentation:
+- ✅ Valid frontmatter with SEO metadata
+- ✅ Proper heading hierarchy (no skipping)
+- ✅ Technical terms in backticks
+- ✅ UI elements in bold
+- ✅ Links with trailing slashes
+- ✅ Code blocks with titles
+- ✅ Complete examples
+- ✅ Image alt text
+- ✅ WCAG 2.1 AA compliance
+
+## AI Tools Available
+
+### Automated (Auto-Applied)
+- `.cursor/rules/markdown.mdc` - Formatting rules
+- `.cursor/rules/content-structure.mdc` - Content organization
+- `.cursor/rules/component-architecture.mdc` - Components
+
+### Manual (Explicit Use)
+- `@.cursor/prompts/convert-to-markdown.md` - Convert content
+- `@.cursor/prompts/markdown-quick-reference.md` - Quick syntax
+
+### Reference Documentation
+- **AI-TOOLKIT.md** - Complete toolkit guide
+- **STYLEGUIDE.md** - Full formatting rules
+- **.cursor/README.md** - Detailed documentation
+
+## Common Patterns
+
+### Introducing CMS Tags
+```markdown
+The [**editable**](../../tags-reference/core/editable/) tag creates regions.
+
+## Basic Usage
+
+```php title="example.php"
+
+```
+
+:::tip[Best Practice]
+Use descriptive names.
+:::
+```
+
+### Cross-References
+```markdown
+See [**Working with Templates**](../../concepts/templates/).
+```
+
+### Version Info
+```markdown
+:::version[v2.0+]
+Requires CouchCMS v2.0 or higher.
+:::
+```
+
+## Error Prevention
+
+**Never:**
+- ❌ Use non-English language
+- ❌ Skip frontmatter
+- ❌ Incorrect heading hierarchy
+- ❌ Omit code block titles
+- ❌ Forget trailing slashes
+
+**Always:**
+- ✅ Complete frontmatter
+- ✅ Proper heading hierarchy
+- ✅ Descriptive code titles
+- ✅ Trailing slashes in links
+- ✅ Correct tag formatting
+
+---
+
+**For complete rules, see STYLEGUIDE.md**
+**For conversion help, use @.cursor/prompts/convert-to-markdown.md**
+**Generated from DOCS-STANDARDS.md - Last updated: 2025-11-26**
diff --git a/.gitignore b/.gitignore
index bffa11f..8c1f70a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,21 +1,36 @@
-# build output
+# Build outputs
dist/
-# generated types
.astro/
-# dependencies
+# Dependencies
node_modules/
-# logs
+# Environment
+.env
+.env.*
+!.env.example
+
+# macOS
+.DS_Store
+
+# IDE
+.vscode/
+.idea/
+*.swp
+*.swo
+*~
+
+# Logs
+*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
+# Temporary files
+*.tmp
+*.temp
-# environment variables
-.env
-.env.production
-
-# macOS-specific files
-.DS_Store
\ No newline at end of file
+# PR Tracker state
+.last-pr.json
+PR-TEST-OUTPUT.md
diff --git a/.inbox/conditional-fields.mdx b/.inbox/conditional-fields.mdx
new file mode 100644
index 0000000..6f4042a
--- /dev/null
+++ b/.inbox/conditional-fields.mdx
@@ -0,0 +1,555 @@
+17 April 2019: This version of Couch has been promoted to become the release version 2.2 available from the main download page https://www.couchcms.com/products/
+
+Hi everybody,
+
+Couch v2.1 beta has moved on to become the release version and time now for a new beta - Couch v2.2 beta.
+Introducing the defining feature of this release -
+
+Conditional Fields
+
+I am sure you must be familiar with conditional fields but allow me to define them in context of Couch.
+As used in Couch, conditional fields are regular and fields that come to life (in a manner of speaking) only if the conditions set for them (by you, as we'll see later) are fulfilled.
+
+To elaborate 'coming to life', all normal (i.e. non-conditional) fields are always alive - i.e. they are visible, they accept inputs posted through them, validate their inputs (throwing errors if the validations fail), enforce the 'required' status if so set by not allowing blank inputs upon form posting etc.
+
+In contrast to the normal fields described above, conditional-fields behave likewise but *only* when conditions set for them are true. Otherwise, they go invisible, ignore posted inputs, skip validation and disregard the 'required' check.
+
+For all practical purposes, they become non-existent if conditions are not right.
+
+That last observation about them makes them very useful in a variety of situations - the most common being using them in complex forms where we can simplify the user-experience by revealing/hiding relevant fields based on the choices made by the user.
+
+Let us build one such form to illustrate and document the usage of conditional fields.
+The form we'll use is actually only a small and simplified portion of a real-world DataBound Form (DBF) and so is not particularly complex but should serve our purpose here.
+
+Before we get into actually creating it, I think a preview of what the finished form would look like will be helpful.
+As I mentioned above, this particular form was meant to be used on the front-end as a DBF but even a DBF begins life as a normal Couch template so here is what it looks like in the admin-panel -
+
+00.png
+00.png (5.46 KiB) Viewed 41735 times
+
+When the form loads, as you can see above, only one field is visible.
+It is a checkbox asking for some further information. If the user chooses not to check the box, the form can be submitted successfully without any problem.
+
+However, if the user checks the box, following is what happens -
+01.png
+01.png (8.88 KiB) Viewed 41735 times
+
+A dropdown, which was hitherto hidden, becomes visible.
+At this point, if you try to save the form it won't succeed if an option is not selected from the dropdown -
+02.png
+02.png (13.59 KiB) Viewed 41735 times
+
+The dropdown, obviously, was internally part of the form even when the checkbox was not ticked but at that time it did not bother to enforce selecting an option when the form was posted. It is only when the checkbox was ticked that the dropdown 'came alive'.
+
+OK, moving ahead -
+select 'One' from the dropdown and you see a set of three new fields appearing on the screen -
+03.png
+03.png (12.21 KiB) Viewed 41735 times
+
+
+So now, the dropdown becomes the 'controller' and the three text fields its 'dependents'.
+Notice also how the three new fields are 'required' - so posting the form at this point will result in the following
+04.png
+04.png (19.03 KiB) Viewed 41735 times
+
+
+Ok, no more harping over the conditionally 'coming alive' point which should be abundantly clear by now.
+Take a look at the form displaying all its fields (with 'Three' selected from the dropdown) and we can move on to the coding part -
+05.png
+05.png (19.1 KiB) Viewed 41735 times
+
+
+At this point let me define two terms we'll be frequently using in any discussion about conditional field -
+In the form above, the dropdown field is the 'dependent' field while the checkbox field is the 'controller' field (because, obviously, it controls the dependent dropdown).
+
+The terms, however, should be seen only in context of describing the relation between two fields.
+A field that is 'dependent' in relation to field 'A' can very well be a 'controller' in relation to field 'B' if 'B' happens to depend on it.
+This is what happens with the dropdown when it is seen in relation to the nine text fields following it - it now becomes the 'controller' while the text fields become its dependents.
+
+One reason for my stressing these terms is that for conditional-fields to work properly in Couch, any 'dependent' field must always come *after* its 'controlling' field(s) when they are displayed in the form. This is because the conditional logic of a 'dependent' depends on values submitted in the controlling fields and if the dependent happens to be displayed before them, at the point of working out the logic, the controlling field wouldn't even exist and the logic will fail.
+This limitation might necessitate making some changes to your existing templates and hence the stress on this point.
+
+1. Using Conditional fields in the backend:
+Following is the code defining the editable regions *before* we begin adding the conditional logic to them -
+Code: Select all
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+As you can see, those are standard editable region definitions (if type 'row' seems unfamiliar, please see viewtopic.php?f=8&t=11023. This type is now part if Couch's core.).
+
+Let us begin with making the dropdown a conditional field where it depends upon the checkbox. For brevity, I'll show only the relevant portion of the code.
+Code: Select all
+
+ hide
+
+
+
+
+Compare the modified code to the definition of the dropdown in previously quoted code and you'll find only two differences -
+1. The code block using is defining a function. If this appears unfamiliar, please see viewtopic.php?f=8&t=11368&start=10#p30174 for full discussion.
+Code: Select all
+
+ hide
+
+
+Broadly speaking, a function is nothing more than a collection of Couch statements which can be invoked by calling that function (as it stands at the moment, our function above will simply output 'hide' when called).
+
+The function we are defining above is a little different from the ones we demonstrated in the above mentioned post. This function is 'anonymous' i.e. it does not have a fixed name of its own; rather, we store the function in a variable ('my_cond' in the code above).
+
+Compared to regular functions, anonymous functions have several advantages e.g. they can be stored in arrays, passed as parameters to other tags or even functions as simple variables. But you don't have to get into the nitty gritty of it - the only thing to understand above is that we are creating a function and storing it in a variable named 'my_cond'.
+
+2. The second modification to the original code is where we make use of the 'my_cond' variable we discussed above -
+Code: Select all
+
+
+As you'll remember, 'my_cond' variable actually holds a function within it.
+In the code above, we set this function into the field's parameter named 'not_active'.
+
+Now this is what happens when the form is being rendered by Couch and the system has to decide whether the field being rendered is 'alive' or not -
+If the field's definition does not contain the 'not_active' parameter, the field is a normal field and is always considered active (alive).
+If, however, that parameter is used in the field's definition and it contains a function (as is the case above), Couch goes ahead and calls the function.
+
+If the function outputs 'hide', it deactivates the field. If the function outputs 'show', it activates the field.
+As far as Couch is concerned, it is as simple as that.
+
+It is for the function (actually for us as we'll write the function) now to apply any kind of logic it wishes before deciding what directive to pass back to Couch.
+It could be checking against the database for a particular value in a particular template or it could even be checking the current time of the day or whatever. What matters to Couch is whether the function outputs 'show' or 'hide' to activate or deactivate the field.
+
+In our code above, our function is simply returning 'hide' and this will cause the dropdown to always remain inactive no matter what.
+
+Most functions would check the 'controlling' field(s) of the field being processed and make Couch activate/deactivate it accordingly. So, in our case the function should ideally check if the checkbox is ticked. If it is indeed ticked, output 'show' to activate the dropdown. If no, output 'hide' to deactivate it.
+
+The process is a lot simpler in doing than it appears in the explanation so let us do that.
+
+Please take a look again at our function's definition above and note that it has one parameter named 'previous_work_experience'. Take a look at the editable regions being defined in the template and you'll find that 'previous_work_experience' is the name of the checkbox field that is supposed to become the controller of the dropdown field we are currently dealing with.
+
+When Couch calls the function, it first finds all the fields specified as the function's parameters (in our case it is only one but we can have any number depending on the use-case, as we'll see shortly), gets the values currently being held in those fields and then passes those values to the function.
+
+So the code we put into our function needs only check if the values being passed to us fullfil the conditions necessary to activate the field or not and output the directive accordingly.
+
+The controlling 'previous_work_experience' field for our dropdown is a checkbox but for just a little while let us assume it is a dropdown or a radio (you'll remember that these two, as opposed to a checkbox, can only contain a single value thus making our code a tad simpler). With that assumption, the following is the complete working code that will make the dropdown conditionally active only if the controlling field contains 'Yes' -
+Code: Select all
+
+ showhide
+
+
+Not too difficult, is it?
+If you so prefer, you may use line-breaks and whitespaces to make the code more readable e.g. the following version works just the same as the one above -
+Code: Select all
+
+
+ show
+
+ hide
+
+
+
+Of course, our controlling field is a checkbox and can, potentially, contain multiple selected values so the actual code we'll use is as follows -
+Code: Select all
+
+ ">
+ show
+
+ hide
+
+
+
+As you can see, we are making use of another tag () to figure out if a particular value is contained within the checkboxes selected values or not. For those familiar with how Couch works with arrays (viewtopic.php?f=5&t=10892), is just a shortened version of .
+
+Try it out and you'll find that the dependent dropdown faithfully follows its controller checkbox in being active or not.
+So that is one conditional field taken care of. Before we move on to the three groups of nine text fields that come next, allow me to bring to your notice certain points from the code we have used so far as those will pertain to all conditional fields -
+
+As we have seen, in the part of the form we applied the conditional logic so far, the checkbox was the controller field and the dropdown was its dependent. Did you notice that all the work we did above was *only* on the dependent field i.e the dropdown? The controller (checkbox) field required no amendments whatsoever.
+
+You'll see this in all conditional fields - to make a field conditional, we'll make all the required changes (i.e. creating the logic calculating function and adding it to the field) only to the dependent field. The controlling field demands nothing. So how does Couch figure out which is the controlling field? I think that should be easy for you to answer. The answer is the names of the parameters we use in the function added to the dependent field. It is these names that tie a dependent to its controller(s).
+
+Keep an eye on that point as we make rest of the fields conditional.
+
+Moving on to the text boxes, the use case demands that the first set shows up when 'One' is selected from the dropdown. When 'Two' is selected, the second row shows up *but* the first row also keeps showing. Same with the selection of 'Three' which causes the third row to show up but the first and the second row also keep showing. We have figured out the conditions needed to show these rows.
+
+So now we see that the dropdown becomes the controller and the text fields its dependent.
+It is easy to miss at this point that the three rows additionally *also* depend on the checkbox - if the checkbox is not 'Yes', they don't exist.
+This has to be explicitly stated (as we'll soon see).
+Point here being that conditionality does not cascade - simply because the dropdown is dependent on the checkbox and the text fields are dependent on the dropdown does not mean the text fields are automatically dependent upon the checkbox.
+
+So there are two controllers (the checkbox and the dropdowns) for the text fields.
+As we have seen above, the definition of the controllers needs no changes. We specify them indirectly using the parameters of the logic function.
+
+Take a look at how we make the first set of three text fields conditional depending upon two controllers -
+Code: Select all
+
+ "
+ &&
+ (previous_number_of_employers='One' || previous_number_of_employers='Two' || previous_number_of_employers='Three')
+ >
+ show
+
+ hide
+
+
+
+
+
+
+
+
+
+Points to note -
+1. We have created only one function and added the same to all the three text boxes. That is perfectly ok as the three fields share the same conditions.
+2. The function, as expected, defines two parameters - these are the names of the checkbox and the dropdown. When Couch calls the function, these parameters will be automatically filled with the then current values contained in the respective parameters.
+3. Notice how the code within the function uses the passed parameters to figure out whether or not to make the field being processed active.
+I don't think it'd be too difficult to figure out the logic - "Show if checkbox is 'yes' and dropdown is either 'one' or 'two' or 'three'".
+Please see http://docs.couchcms.com/tags-reference/if.html if you need any help with the use of OR and AND logic.
+
+And with that we can wrap up the form by converting the last remaining two rows -
+Code: Select all
+
+ "
+ &&
+ (previous_number_of_employers='Two' || previous_number_of_employers='Three')
+ >
+ show
+
+ hide
+
+
+
+
+
+
+
+
+
+
+ " && previous_number_of_employers='Three'>
+ show
+
+ hide
+
+
+
+
+
+
+
+
+
+The changes to the last two groups are minor variations of what was required for the first group so shouldn't be difficult to understand.
+
+2. Using Conditional fields on the frontend with DBFs:
+With the backend completed, let us see what it takes to use conditional fields on the frontend (in a DataBound Form).
+
+The full code for the DBF is contained in the attached files and you'll find that it is just a standard databound form as discussed in the docs (http://docs.couchcms.com/concepts/databound-forms.html). So, here I'll discuss only those portions of it that are specific to implementing the condition field logic.
+
+Following portion showing only the checkbox, the dropdown and the first row of textboxes should suffice for our discussion -
+Code: Select all
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+As you can see, as is the norm with DBF, we are are using s with type "bound" to render our editable regions.
+There is no need to define the logic calculating function etc. again on the frontend as the 'bound' fields automatically pick those from the backend.
+
+If you submit the form at this point, you'll see that the backend enforces the 'required' status of all dependent fields depending upon what was selected in their controlling fields. What does *not* happen is the automatic hiding and showing of the fields on the front-end.
+
+That part actually makes use of some (Couch generated) JS code. While that JS is automatically included in the admin-panel forms, the same does not happen on the frontend.
+
+So while using our conditional fields on the frontend in a DBF, we need to explicitly take some steps (two to be precise) to make the fields show/hide as the controllers change.
+
+1. Add the following at the end of the template just before the closing