Docs Navigation Open
Creating an Extra
Create an Evolution CMS extra as a real package with composer metadata, a service provider, config, migrations, views, assets, and optional classic elements.
Recommended Starting Point
For Evo 3, the correct default is a package, not a loose collection of files. Use a package when the extra needs classes, config, views, routes, migrations, demo data, manager modules, or frontend assets.
php core/artisan package:create example
Minimum Package Parts
composer.jsonwith package name, PSR-4 namespace, and provider registrationsrc/ExampleServiceProvider.phpconfig/example.phpviews/for package templates- optional
migrations/,lang/,resources/,public/assets/
Composer Example
{
"name": "evolution-cms/example-package",
"type": "EvolutionCMS-Package",
"autoload": {
"psr-4": {
"EvolutionCMS\\Example\\": "src"
}
},
"extra": {
"laravel": {
"providers": [
"EvolutionCMS\\Example\\ExampleServiceProvider"
]
}
}
}
Service Provider Responsibilities
The provider is the center of the package. A typical provider should:
- merge package config
- register Artisan commands
- load migrations
- load package views
- publish assets, config, views, and optional migrations
- load chunks and plugins when the package ships classic assets
- register a manager module if needed
Classic Elements Inside the Package
example-package keeps classic Evolution assets inside the package so they can be loaded by the provider:
assets/chunks/
assets/snippets/
assets/plugins/
assets/tvs/
assets/modules/
Demo and Bootstrap Data
If the package needs a usable demo, ship a seeder and a command. In the example package the command example:install-demo publishes assets and then runs the seeder that creates templates, TVs, and documents.
php artisan example:install-demo --migrate
What a Good Package Should Document
- install commands
- published config file
- what migrations create
- what commands exist
- which routes, views, modules, chunks, snippets, and plugins are included
- how to disable demo content in production
For the exact package anatomy, see Project Structure. For maintenance expectations, continue with Maintaining Extras.
Legacy Extras
Legacy extras remain important for maintenance and migration because many Evolution projects still depend on them.
Maintaining Extras
Maintain extras as real packages with documented install flow, compatibility notes, config, commands, assets, and upgrade guidance.