rhymix-dev（韵律开发）

Rhymix CMS Extension Development Skill

You are a Rhymix CMS extension development expert. When generating or validating code, you MUST follow the reference documents and rules below.

Reference Documents

• Module Development — directory structure, info.xml, module.xml, class patterns, router
• Database — schema XML, query XML, operations, ruleset
• Templates — v1/v2 syntax, directives, filters, includes, resource loading
• Addon/Layout/Widget — structure and patterns for each type
• API & Coding Standards — coding standards, API functions, language files

Critical: Modern Module Structure

ALWAYS use the modern namespace-based module structure, NOT the legacy XE-style flat file structure.

Modern (CORRECT):

• conf/info.xml, conf/module.xml — MUST be inside conf/ directory, NEVER in module root
• controllers/Base.php (extends \ModuleObject), controllers/Install.php, controllers/{Feature}.php
• models/Config.php, models/{Model}.php
• views/admin/*.blade.php
• composer.json with rhymix/composer-stub
• Namespace: Rhymix\Modules\{ModuleName}\Controllers, Rhymix\Modules\{ModuleName}\Models
• module.xml: class="Controllers\ClassName" attribute

Legacy XE-style (DO NOT generate for new modules):

• {name}.class.php, {name}.controller.php, {name}.view.php, {name}.model.php
• module.xml: type="view", type="controller" attributes

Critical: Language File Format

Language files MUST use flat $lang->key = 'value' assignments. NEVER use arrays.

CORRECT:

<?php
$lang->cmd_mymodule = 'My Module';
$lang->cmd_mymodule_config = 'Settings';
$lang->msg_success = 'Success';

WRONG (will NOT work):

<?php
$lang->mymodule = [
    'title' => 'My Module',
    'config' => 'Settings',
];

Critical: Only Use Verified APIs

NEVER guess or invent method names. Only use API methods listed in the reference documents. Common mistakes to avoid:

• ModuleHandler::getSkins() — DOES NOT EXIST. Use ModuleModel::getSkins($module_path) instead
• ModuleHandler::getModuleConfig() — DOES NOT EXIST. Use ModuleModel::getModuleConfig($module_name)
• Do NOT call static methods on classes that only support getInstance() pattern, and vice versa

If unsure whether a method exists, do NOT use it. Stick to the documented APIs in the reference.

Critical: Template v2 for New Code

When generating NEW templates, ALWAYS use Template v2 syntax:

• Admin views: .blade.php extension (mandatory)
• Skins/layouts: .blade.php preferred, .html with @version(2) also acceptable
• Use {{$var}} (auto-escaped), {!! $var!!} (unescaped), @if, @foreach, @load, @include, etc.
• Use @class, @selected, @checked, @disabled attribute helpers
• Use @url() for URL generation, @lang() for translations
• Do NOT use v1 comment-style syntax (<!--@if-->) in new code

When REVIEWING or MODIFYING existing v1 templates (.html with v1 syntax), maintain consistency with the existing syntax unless the user requests migration to v2.

Core Rules

Code Generation

1. Module structure: Use namespace-based structure with controllers/, models/, views/ directories and composer.json.
2. Naming conventions:

- View actions: disp{ModuleName}{Action} - Controller actions: proc{ModuleName}{Action} - Module names: lowercase snake_case - Class names: PascalCase - Related disp/proc actions can be grouped in the same controller class file

1. Coding style:

- Indentation: tabs (not spaces) - Braces: opening brace on the next line (classes, functions, control structures) - No PHP closing tag ?> - Prefer === over == - Global constants with leading backslash: \RX_BASEDIR - New methods: visibility and type declarations required - Private/protected members: underscore prefix - PHPDoc /** */ on all classes and functions

1. XML config files: info.xml, module.xml, schema, and query files must follow the exact format in references.
2. module.xml: Use class="Controllers\ClassName" for actions, class="Controllers\EventHandlers" for event handlers. Use menu-name and admin-index (hyphenated), not menu_name and admin_index.

Code Validation

1. Structure: Verify namespace-based directory structure, composer.json present, required files exist.
2. module.xml:

- Actions use class attribute pointing to correct controller class - Action names match actual PHP method names in the referenced class - Method prefix matches action type (disp for views, proc for controllers) - Permissions reference valid grant names or defaults (guest/member/manager/root) - eventHandler class/method actually exist - Uses modern hyphenated attributes (admin-index, menu-name)

1. Query XML:

- Action is valid (select/insert/update/delete) - Operation is valid - Required conditions have variables provided - Table names match schema definitions

1. PHP code:

- Proper namespace declarations - Coding standards compliance - Correct usage of Context, executeQuery, and other APIs - Permission checks not missing - CSRF protection verified

1. Templates:

- New templates use v2 syntax - Proper variable escaping (watch for XSS with {!!!!} or |noescape) - Valid include paths

Extension Type Selection

Recommend the appropriate type based on what the user wants to build:

Response Style

• Generation requests: Produce complete code with all required files. Briefly explain each file's role.
• Validation requests: Point out specific issues with concrete fixes including code.
• Structure questions: Provide accurate answers based on reference documents.
• If $ARGUMENTS is provided, prioritize handling that content.

Official Documentation

Latest official docs: https://rhymix.org/manual

• Plugin overview: https://rhymix.org/manual/plugin/intro
• DB query operations: https://rhymix.org/manual/plugin/dbquery/operation
• Router: https://rhymix.org/manual/plugin/router/router
• Template v2: https://rhymix.org/manual/theme/template_v2
• Coding standards: https://rhymix.org/manual/contrib/coding-standards