fix: framework type casing

[konradmichalik]

Summary by CodeRabbit

• Documentation
  • Standardized framework names to proper case across guides and examples (e.g., Symfony, Drupal, WordPress, Laravel; TYPO3 unchanged).
• Bug Fixes
  • Corrected CLI/help and example strings to use proper-cased framework names.
• User impact
  • Please update any config files or examples to use the new casing for framework type values.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds internal normalization for framework type values (maps common lowercase/uppercase variants to canonical casing: TYPO3, Symfony, Drupal, WordPress, Laravel), invokes it during configuration construction and before validation, and updates documentation, CLI help text, parser constant, validation enum, and a test fixture to use the canonical casing.

Changes

Cohort / File(s)	Summary
Framework Type Normalization db_sync_tool/utility/system.py	Adds _FRAMEWORK_TYPE_MAP and _normalize_framework_type(); normalization invoked after build_config(args) and in get_configuration() prior to validation.
Parser / Validation / Tests db_sync_tool/utility/parser.py, db_sync_tool/utility/validation.py, tests/integration/configs/wordpress/sync-www1-to-local.json	Renames framework constant/value to WordPress, updates allowed enum values in validation schema, and updates test fixture type value to WordPress.
CLI & Recipes db_sync_tool/cli.py, db_sync_tool/recipes/wordpress.py	Fixes capitalization in CLI help string and module docstring to WordPress (no behavior changes).
Documentation — Configuration & Reference docs/configuration/index.md, docs/configuration/reference.md, docs/reference/cli.md	Adjusts examples and comments to use proper-cased framework names: Symfony, Drupal, WordPress, Laravel (TYPO3 unchanged).
Documentation — Getting Started docs/getting-started/drupal.md, docs/getting-started/laravel.md, docs/getting-started/wordpress.md	Replaces all-caps type values with proper-cased identifiers in CLI examples, YAML samples, and complete examples.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 I hopped through configs, tidy and spry,
Changed casing gently, one dot at a time.
Symfony, Drupal, Laravel, WordPress too,
Normalized names — a neat little clue.
Hooray for configs that now all agree!

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix: framework type casing' directly and accurately summarizes the primary change of standardizing framework type identifiers to proper casing across code and documentation.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/type-casing

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@db_sync_tool/utility/system.py`:
- Around line 118-124: Update the incorrect "Wordpress" capitalization to the
official "WordPress" in all referenced places: change the value in the
_FRAMEWORK_TYPE_MAP mapping (key 'wordpress') to 'WordPress', update the
Framework enum member label/value in db_sync_tool/utility/validation.py to use
"WordPress", adjust the Framework.WORDPRESS constant/representation in
db_sync_tool/utility/parser.py to "WordPress", and revise any CLI help text in
db_sync_tool/cli.py that currently shows "Wordpress" so it reads "WordPress";
preserve existing enum/member names (e.g., Framework.WORDPRESS) but correct only
the displayed/returned string capitalization.

🧹 Nitpick comments (1)

db_sync_tool/utility/system.py (1)

225-225: set_framework_type() already receives properly-cased values; normalization isn't bypassed in practice.

The detected_type values in automatic_type_detection() come from the mapping dictionary keys, which are Framework enum constants ('TYPO3', 'Symfony', etc.)—already in canonical form. Additionally, automatic_type_detection() returns early if the type is already set (line 8), preventing set_framework_type() from being called after get_configuration() completes in the current codebase. However, for defensive design, consider adding normalization to set_framework_type() to prevent potential issues if the function is called elsewhere with unnormalized input.