Bundled install/assets components are not imported by the standalone installer

[middleDuckAi]

Summary

The standalone installer currently finishes a clean Evolution CMS installation with database seeders and optional Composer-based Extras, but it does not appear to import/register the bundled default components that still live in the Evolution core install payload under install/assets/*.

This creates a behavior gap versus the legacy/web installer: the Manager can come up with an empty or incomplete Elements -> Plugins list even though the core repository still ships bundled install assets such as install/assets/plugins/*.tpl.

Related core report: evolution-cms/evolution#2258

Why this looks like an installer issue

In the Evolution core repo, the legacy installer path still reads and registers bundled install assets:

• install/src/processor/result.php builds module/plugin/snippet/chunk/TV payloads from install/assets/*
• install/src/controllers/install.php persists those payloads into the database during installation
• install/cli-install.php also has explicit installModulesAndPlugins() logic for bundled plugins/modules

In the standalone installer repo, the new install flow currently does this instead:

• src/Commands/InstallCommand.php runs migrations
• src/Commands/InstallCommand.php runs a fixed seeder list (SystemSettingsTableSeeder, SystemEventnamesTableSeeder, SiteTemplatesTableSeeder, UserRolesTableSeeder, UserPermissionsTableSeeder, AdminUserTableSeeder, SiteContentTableSeeder)
• then it offers optional Extras installation via Composer / artisan

That seeder list does not include any import step for bundled install assets from the Evolution core distribution.

There is another signal in src/Presets/EvolutionPreset.php: configureProject() still contains a TODO note about finishing installation tasks (Create admin user, run migrations, seeders, etc.), which suggests this area is still evolving.

Expected behavior

A clean installation performed via the new standalone installer should reproduce the same bundled default component baseline that a supported web installer path produces.

Important distinction:

• bundled default components from the core distribution should be installed automatically
• optional Composer/managed Extras should stay optional
• expectations about third-party or no-longer-bundled packages should not be mixed into this contract

Actual behavior

The new installer completes successfully, but the bundled install assets are not guaranteed to be imported/registered, so the resulting Manager instance can miss default plugins/components.

Evidence / scope notes

At the moment, the bundled install payload visible in the Evolution 3.5.x repo includes examples such as:

• install/assets/plugins/CodeMirror.tpl
• install/assets/plugins/OutdatedExtrasCheck.tpl
• install/assets/plugins/transalias.tpl
• install/assets/plugins/updater.tpl
• install/assets/modules/store.tpl

So this issue is not about installing every historical extra automatically. It is about preserving the installation contract for the components that are still shipped as part of the core install payload.

Proposed solution options

Option A: Reuse the existing core install-assets import contract

Teach the standalone installer to invoke a dedicated import step for bundled install/assets/* content after migrations/seeders and before optional Extras.

Pros:

• closest behavioral match to the legacy/web installer
• low ambiguity about what counts as bundled defaults

Cons:

• may require extracting/reusing legacy install logic from core in a maintainable way

Option B: Move bundled defaults into a first-class manifest/seeder pipeline

Replace implicit install/assets/* scanning with an explicit manifest or dedicated seed/import classes that the standalone installer can call deterministically.

Pros:

• cleaner long-term contract
• easier to test and version

Cons:

• larger change because it touches both installer expectations and core packaging conventions

Option C: Preset-owned bundled-components step

Add an explicit EvolutionPreset step such as installBundledComponents() that imports only the core-shipped defaults, while leaving Composer Extras as a separate optional lane.

Pros:

• keeps the ownership clear inside the installer repo
• can evolve without coupling everything to the generic seeders stage

Cons:

• still needs a stable source of truth for which bundled assets must be imported

Recommended direction

Start with Option A or C as the shortest safe fix:

• define the bundled-components contract explicitly
• import core-shipped install/assets/* payload during evo install
• keep Composer Extras separate and optional
• add regression coverage proving that a fresh install registers the bundled plugins/modules shipped with the selected Evolution version

Acceptance criteria

• evo install ... produces the same bundled default component baseline as the supported web installer path for the same Evolution version
• bundled components shipped in the core install payload are registered in the database and visible in Manager
• optional Extras remain optional and are not silently conflated with bundled defaults
• installer coverage includes at least one regression check for bundled plugin/module registration