Installation and Prerequisites

This page covers the minimum setup required before you start building your own integration layer.

Baseline assumptions

Tagixo is designed for Laravel projects that already have:

• a working database connection
• a standard web middleware stack
• authentication or an equivalent access-control strategy
• a Vite pipeline for frontend assets

The package can be used without Primix or Filament, but it still expects your application to decide who can edit content and where builder pages live.

Install the core package

composer require ccast/tagixo

If you plan to expose the builder through Primix in the same application:

composer require ccast/tagixo-primix

Publish configuration

php artisan vendor:publish --tag=tagixo-config

This creates:

• config/tagixo.php

Do this immediately. Treat that file as part of your app, not as vendor internals.

Run migrations

php artisan migrate

The package ships tables for:

• pages
• templates
• layouts
• library items
• global variables
• media-related data

You do not have to use every table in your final product, but you should migrate them all first so the package can boot correctly.

Optional publishes

Publish these only when you intentionally need to customize package internals:

php artisan vendor:publish --tag=tagixo-views
php artisan vendor:publish --tag=tagixo-translations
php artisan vendor:publish --tag=tagixo-assets
php artisan vendor:publish --tag=tagixo-migrations
php artisan vendor:publish --tag=tagixo-seeders

Avoid publishing everything "just in case". It creates unnecessary divergence from vendor code and makes upgrades harder.

What should work immediately after install

After package discovery and migrations, the following should be true:

• Tagixo routes are registered.
• The config file is readable from config('tagixo').
• Builder bootstrap endpoints respond under your application middleware.
• The package can resolve built-in modules, PropTypes, icons, fonts, and canvases.

Smoke test checklist

Run these checks before you start building a custom admin UI or SDK integration:

php artisan route:list | grep tagixo
php artisan tinker

Inside Tinker, confirm config and route middleware assumptions:

config('tagixo.route_middleware');
config('tagixo.contexts');

Then call the bootstrap endpoint in your browser or HTTP client:

GET /tagixo/builder/bootstrap?context=page&layout_variant=default

You should receive JSON containing at least:

• context
• layoutVariant
• canvas
• structure
• availableComponents
• propTypeRegistry
• globalVariables

If bootstrap fails, fix that first. Nothing else in the integration will be reliable until bootstrap is stable.

Recommended project structure

Tagixo does not hardcode any namespace or directory for your custom extensions. The package only consumes fully-qualified class names you register via config/tagixo.php (modules, prop_types) or runtime calls (Tagixo::registerModule(...), Tagixo::registerPropType(...)).

The core ships artisan generators that scaffold a starter skeleton for each extension type:

php artisan make:tagixo-module HeroBanner
php artisan make:tagixo-form-field VatField
php artisan make:tagixo-form-wrapper WizardStep
php artisan make:tagixo-prop-type ShadowPropType
php artisan make:tagixo-prop CustomSliderProp

The destination is controlled by config/tagixo.php:

'scaffolding' => [
    'path' => 'app/tagixo',   // relative to base_path()
    'namespace' => null,      // null = derived from path (app/tagixo → App\Tagixo)
],

So the default layout is:

• App\Tagixo\Modules (+ companion Blade views in resources/views/tagixo/modules/)
• App\Tagixo\FormFields
• App\Tagixo\FormWrappers
• App\Tagixo\PropTypes
• App\Tagixo\Props

Change path to anything (app/builder, src/Cms, …) and namespace is re-derived automatically. Set namespace explicitly when your path can't be mapped (e.g. dashes or non-standard autoload).

Per-command overrides are supported:

# One-off override
php artisan make:tagixo-module HeroBanner --path=app/extras --namespace=App\\Extras

# Scaffold INTO a composer package you are developing (reads its PSR-4 autoload)
php artisan make:tagixo-module HeroBanner --package=../my-tagixo-plugin

In package mode the command reads the target package's composer.json, picks the single PSR-4 entry, and places the file at {package}/{psr4-path}/Modules/HeroBanner.php with the correct namespace. The registration snippet printed at the end suggests the plugin's ServiceProvider::boot() rather than config/tagixo.php.

Each command prints a copy-pasteable registration snippet on success. Use it to wire the new class into config/tagixo.php (app mode) or into your plugin's service provider (package mode).

SDK-specific generators (make:filament-builder-page, make:primix-builder-page) still exist and scaffold the host page class — they are complementary, not replacements.

First decisions to make before writing code

Decide these early:

1. Where will builder pages live?
2. Which users can access them?
3. Will content be stored in package tables, your own tables, or both?
4. Will rendered HTML/CSS be generated synchronously on save or cached asynchronously?
5. Will you start standalone, or directly expose the builder through an SDK such as Primix?

Common installation mistakes

• Assuming Tagixo ships your final admin UI out of the box. The package ships the engine and API contracts; your app or SDK adapter decides the host UI.
• Forgetting that builder routes inherit tagixo.route_middleware.
• Publishing views and then forgetting they are now frozen copies.
• Storing builder JSON before validating the structure shape.
• Treating preview routes as public URLs. They are signed, short-lived integration tooling.

Minimum go-live threshold

Before calling installation "done", verify:

• bootstrap works for page
• render works for a trivial structure
• stylesheet works for the same structure
• preview-url issuance works under your auth/session setup
• one persistence round-trip works end-to-end