Getting Started

Overview

What Tagixo is, what this documentation covers, and how to navigate the integration path.

Tagixo — Core Overview

Tagixo is a visual builder engine for Laravel. It ships a pre-built Vue editor, a rendering pipeline, a module/prop system, and all the database models needed to build, store, and serve visually-authored content — pages, sliders, forms, mail templates, and PDFs. You host the editor yourself inside a Blade layout you control; Tagixo handles everything else.

The core package is ccast/tagixo (private, GitHub VCS). All functionality described in this documentation section comes from that single package.


What You Can Build

Content Type Render path Notes
Pages PageRenderer::renderWithLayout() Full layout: header + content + footer. Default use case.
Sliders Embedded inside a page section Special section type; shares the module/prop system, adds WebGL + WAAPI transitions.
Forms <x-tagixo-form> Blade component Form definitions in tgx_forms; submissions dispatched to configurable actions.
Mail templates MailRenderer Context-gated; produces 600 px scaffold with inline CSS only.
PDFs Headless render → download endpoint Static snapshot; you protect the download route in your own middleware.

Sliders are not a top-level page context. A slider lives inside a page as a special section type and is edited from within the page builder.


The Standalone Integration Model

In the standalone path you own the editor host page. Tagixo provides the builder JS/CSS and the Laravel service-layer; you wire them together with three endpoints and one Blade layout.

The three required endpoints:

Endpoint Method Responsibility
bootstrap GET Returns the initial builder payload (page data, module catalog, global variables).
save POST Receives the editor's JSON payload and persists it via the Tagixo models.
preview GET Renders a draft payload through PageRenderer and returns the HTML fragment for the editor's preview iframe.

Your bootstrap and save controllers call Tagixo's BuilderPayload and BuilderSave service classes. The preview endpoint calls PageRenderer directly with an unsaved snapshot. Full controller examples are in the Standalone Builder Integration page.

The editor layout is a plain Blade file. You load two asset files from public/vendor/tagixo/, output a mount point, and pass the bootstrap URL:

<!doctype html>
<html>
<head>
    <meta charset="utf-8">
    <link rel="stylesheet" href="{{ asset('vendor/tagixo/tgx-layout.css') }}">
    <link rel="stylesheet" href="{{ asset('vendor/tagixo/modules.css') }}">
</head>
<body>
    <div id="tagixo-vue"
         data-bootstrap="{{ route('builder.bootstrap', $page) }}"
         data-save="{{ route('builder.save', $page) }}"
         data-preview="{{ route('builder.preview', $page) }}">
    </div>

    <script src="{{ asset('vendor/tagixo/builder.js') }}"></script>
</body>
</html>

No npm step, no Vite config, no node_modules. The builder is pre-bundled in dist/ and published to public/vendor/tagixo/ during installation.


Architecture

┌─────────────────────────────────────────────────────────────────┐
│  Your Laravel app                                               │
│                                                                 │
│  BuilderController                                              │
│  ├── bootstrap()  → BuilderPayload::forPage($page)             │
│  ├── save()       → BuilderSave::fromPayload($page, $data)     │
│  └── preview()    → PageRenderer::renderWithLayout($snapshot)  │
│                                                                 │
│  Blade editor layout                                            │
│  └── <div id="tagixo-vue" data-bootstrap="..." ...>            │
└────────────────────┬──────────────────────┬────────────────────┘
                     │                      │
                     ▼                      ▼
       public/vendor/tagixo/        Database (tgx_* tables)
       builder.js                   tgx_pages
       frontend.js                  tgx_layouts
       tgx-layout.css               tgx_menus
       modules.css                  tgx_forms
                                    tgx_global_variables
                                    tgx_global_blocks
                                    ...
                                         │
                                         ▼
                              ┌──────────────────────┐
                              │  Public routes        │
                              │                       │
                              │  GET /{slug}          │
                              │  → PublicPageController│
                              │  → PageRenderer        │
                              │  → View: public.page  │
                              └──────────────────────┘

Request Lifecycle (Public Page View)

  1. GET /{slug} is handled by your PublicPageController::show().
  2. Load a published Ccast\Tagixo\Models\Page by slug. Return 404 on miss or unpublished (unless the request carries a valid preview token).
  3. Call PageRenderer::renderWithLayout($page). This resolves the effective layout (page-level override → global fallback) and concatenates header + content + footer HTML.
  4. PageRenderer::generateFontLinks() walks all three sections, deduplicates every Font component found, and returns <link rel="preload"> and <link rel="stylesheet"> tags.
  5. Render the final HTML through your Blade view, injecting the font links and any page-level custom_css.

Builder Assets

The builder and public runtime are pre-built bundles committed to public/vendor/tagixo/ via php artisan vendor:publish --tag=tagixo-assets. No build step is required in your app.

File Purpose
builder.js Full editor (Vue 3, PrimeVue, Tiptap, Pinia). Load only on editor pages.
frontend.js Lightweight public runtime. Load on every public-facing page.
tgx-layout.css Layout and responsive rules shared between editor and frontend.
modules.css Per-module CSS generated by the module system.

Commit public/vendor/tagixo/. If your production Docker image runs composer install --no-scripts, vendor:publish never runs in the build. The committed files are what gets served.

After every ccast/tagixo version bump, run vendor:publish --force and commit the updated files alongside the composer.lock change.


Module, Prop, and PropType System

Tagixo's content model is built on three registries resolved from the Laravel service container:

ModuleRegistry maps module identifiers to PHP descriptor classes. Each descriptor declares the module's name, catalog icon, available PropTypes, sub-elements, and Blade view. The editor's catalog panel reads directly from this registry.

PropTypeRegistry maps PropType class names to their JS-side configuration: schema shape, default values, and CSS-generator function. The Design drawer for each module is constructed from the PropTypes listed in that module's descriptor.

ComponentRegistry maps string identifiers to Vue component definitions. Both the editor canvas and the public renderer resolve components through this registry.

You extend the system by registering a PHP descriptor (which points to a Blade view and a set of PropTypes) and a Vue component. You do not need to modify any Tagixo source files. See Custom Form Modules and the module system reference for complete examples.


What This Documentation Covers

The Core section walks through every step of a standalone integration:

  • Installation — Composer setup, service provider, migration, asset publishing.
  • Configurationtagixo.php config reference, storage drivers, content tokens.
  • Blade integration — editor layout, public page view, font injection.
  • Builder endpoints — bootstrap, save, and preview controller implementation.
  • RenderingPageRenderer API, layout resolution, custom_css.
  • Forms — form schema API, <x-tagixo-form>, submission actions.
  • Mail templatesMailRenderer, context feature gating.
  • PDFs — headless render pipeline, download endpoint.
  • Data modelstgx_* table shapes and Eloquent models.
  • Module system — writing custom modules and PropTypes.

If you plan to use Filament or Primix as your admin panel, the Filament SDK and Primix SDK documentation sections cover those integrations.


See Also