Laravel Bootstrap and Configuration

The central configuration file is:

• config/tagixo.php

This file defines how Tagixo behaves inside your Laravel application. Do not leave it at default values without reviewing the sections below.

1. Contexts

Tagixo currently supports these builder contexts:

• page
• form
• mail
• pdf

Each context has metadata such as label, description, and enabled state.

Example:

'contexts' => [
    'page' => [
        'label' => 'Page Builder',
        'enabled' => true,
    ],
]

Why this matters:

• context affects which canvas payload is used
• context affects which modules are visible
• context affects render behavior
• context affects preview behavior

Do not invent custom context names unless you also own the full integration layer around them.

2. Route middleware

By default, builder routes use:

'route_middleware' => ['web', 'auth']

This applies to builder API endpoints such as bootstrap, render, preview-url, global variables, media, and model metadata.

Adjust this if your application requires:

• tenancy middleware
• custom guards
• panel-specific access control
• internal-only editor access

Do not remove web lightly. Preview and session-aware flows rely on standard Laravel web behavior.

3. Data models for bindings

If you want builder users to bind modules to Eloquent model metadata, register models here:

'models' => [
    App\Models\Post::class,
    App\Models\Product::class,
],

This powers endpoints such as:

• GET /tagixo/builder/models
• GET /tagixo/builder/models/{key}/attributes

Register only models you are willing to expose in the editing experience.

4. Custom modules

Register application-specific modules in config when you want deterministic boot:

'modules' => [
    App\Tagixo\Modules\HeroBanner::class,
    App\Tagixo\Modules\PricingMatrix::class,
],

Use config registration when:

• you want simple deployment behavior
• the module set is static
• registration should happen in every environment

5. Custom PropTypes

Register custom PropTypes exactly the same way:

'prop_types' => [
    App\Tagixo\PropTypes\ShadowPropType::class,
    App\Tagixo\PropTypes\DataBadgePropType::class,
],

This is the safest option for reusable application-wide style systems.

6. Runtime registration

If registration depends on environment, feature flags, or package composition, do it in a service provider:

use Ccast\Tagixo\Facades\Tagixo;

public function boot(): void
{
    Tagixo::registerModules([
        App\Tagixo\Modules\HeroBanner::class,
    ]);

    Tagixo::registerPropTypes([
        App\Tagixo\PropTypes\ShadowPropType::class,
    ]);
}

Prefer runtime registration when:

• a host package adds modules conditionally
• a panel adapter enables integrations only in some panels
• custom code depends on environment or customer plan

7. Preview security

The preview section controls signed preview flow:

• token_ttl_seconds
• url_ttl_seconds
• cache_prefix

Preview payloads are stored server-side, then consumed by a signed preview URL. This is integration tooling, not public publishing.

Recommended practice:

• short TTL in production
• slightly longer TTL in staging for QA sessions
• keep cache storage reliable enough that preview payloads do not disappear randomly during editing

8. Media gallery

Review media_gallery before enabling uploads in real projects:

• storage disk
• allowed mime types
• max upload size
• image quality
• thumbnail generation
• crop presets

Do not treat media configuration as a cosmetic detail. It affects storage cost, frontend consistency, and editor UX.

9. Cache behavior

The cache block controls package-level caching behavior:

'cache' => [
    'enabled' => true,
    'ttl' => 3600,
],

In local development, you may want easier invalidation. In production, treat caching as part of your rendering strategy and measure it.

10. Recommended Laravel bootstrap pattern

A clean app setup usually looks like this:

1. Publish config + assets.
2. Register custom modules and PropTypes in one app provider.
3. Register only approved Eloquent models.
4. Verify route middleware under real auth conditions.
5. Wire your admin UI to link at /tagixo/builder/embed?type=…&id=…&back=… (standalone) or use the SDK Resources (Filament/Primix).
6. Persist raw JSON and generate render artifacts after save.

Suggested application provider example

namespace App\Providers;

use App\Models\Post;
use App\Tagixo\Modules\HeroBanner;
use App\Tagixo\PropTypes\ShadowPropType;
use Ccast\Tagixo\Facades\Tagixo;
use Illuminate\Support\ServiceProvider;

class TagixoServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Tagixo::registerModels([
            Post::class,
        ]);

        Tagixo::registerModules([
            HeroBanner::class,
        ]);

        Tagixo::registerPropTypes([
            ShadowPropType::class,
        ]);
    }
}

Configuration review checklist

• contexts enabled intentionally
• middleware aligned with your auth model
• models registered intentionally
• custom modules autoloadable
• custom PropTypes autoloadable
• preview TTL values reviewed
• media disk and limits reviewed
• caching behavior reviewed

If this checklist is incomplete, your docs may look fine while the integration remains fragile.