redaxo-core

Building and maintaining custom REDAXO addons – package.yml, boot.php, install/update/uninstall, lang files, fragments, backend pages, the assets pipeline (and the reinstall-to-sync rule), cache-busting on asset URLs, vendor dependencies, and the common-pitfalls checklist. Use when the user creates a new addon, edits package.yml, sets up backend pages, ships frontend assets from an addon, integrates Composer dependencies, or asks how to package functionality as a reusable addon.

Building HTTP/AJAX endpoints in REDAXO using rex_api_function – the lib/ class location, naming convention, $published flag for frontend access, JSON responses, CORS for cross-domain widgets, and the rex-api-call URL. Use when the user adds an AJAX/HTTP endpoint to a custom addon, builds a JSON API for a frontend widget, or asks how to expose data via /index.php?rex-api-call=. Distinct from the FriendsOfRedaxo/api addon (covered by the redaxo-api-addon plugin).

REDAXO project structure, request lifecycle, and core classes. Use when the user works on a REDAXO codebase, mentions REDAXO directory layout, asks about rex_addon/rex_config/rex_path/rex_url/rex_clang/rex_request, or when files under redaxo/src/, redaxo/data/, or redaxo/cache/ appear in the conversation.

Building CLI / diagnostic / maintenance commands for REDAXO addons using Symfony Console (rex_console_command). Covers the required class location, naming convention, package.yml registration, and SymfonyStyle helpers. Use when the user adds a CLI tool to an addon, wants a cronjob entry point, builds a diagnostic command, or asks "how do I run X from the command line in REDAXO". Replaces the anti-pattern of writing standalone bootstrap scripts in bin/.

REDAXO Extension Points – the hook system for modifying core/addon behavior without patching files. Use when the user mentions rex_extension::register, hooks into events like ART_PRE_VIEW / OUTPUT_FILTER / PACKAGES_INCLUDED, or wants to extend backend pages and content.