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.json with package name, PSR-4 namespace, and provider registration
  • src/ExampleServiceProvider.php
  • config/example.php
  • views/ 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.

Previous

Legacy Extras

Legacy extras remain important for maintenance and migration because many Evolution projects still depend on them.

Next

Maintaining Extras

Maintain extras as real packages with documented install flow, compatibility notes, config, commands, assets, and upgrade guidance.