- What is awcodes/mason used for?
- Mason is a Filament plugin that adds a block-based drag and drop builder field for composing pages, posts, and landing page layouts. Editors assemble content from reusable bricks, and the structure is stored as JSON in an existing column. You can then render that JSON anywhere in your Laravel Blade templates. It is an admin-surface tool, not a full CMS or platform dependency.
- How do I install awcodes/mason in a Laravel Filament application?
- Install the package with Composer, register the Mason plugin or service provider in your Filament panel, and publish its assets. Run php artisan filament:assets as part of deployment so the compiled browser bundle is refreshed. Then add a Mason::make('content') field to a Filament form and register at least one brick class. Verify the field renders and saves JSON before rolling it out broadly.
- Does Mason require database migrations or new models?
- No. Mason stores block content as structured JSON in an existing column, so it does not add models, migrations, queues, jobs, APIs, or authentication. Backups, replication, and data-tier risk remain unchanged. Confirm your column type and JSON casting in the host model, then test persistence against the installed release artifact.
- Which Laravel and Filament versions does Mason support?
- Mason is distributed via Composer with constraints tied to Filament and Laravel, so check the repository's composer.json for the exact supported matrix before upgrading. Do not assume compatibility from the readme alone. Install the target release, such as a 3.6.0 artifact, and reproduce a working Mason::make('content') field and front-end render before committing to an estimate.
- How do I render Mason content on the front end?
- Mason provides a Blade render path driven by the @masonStyles and @masonEntryStyles directives. Use those directives in your layout, then render the stored JSON through the package's entry rendering mechanism. Because content is JSON in your own column, you control which model records and views expose it. Keep escaping and sanitization of brick configuration in mind as your responsibility.
- What is previewData() and why is it a security concern?
- previewData() supplies data to bricks in the Livewire editor preview, and that payload is JSON-serialized into the signed render context sent to the browser. Anyone who can reach the editor can read it, so pass only an explicit allow-list of fields rather than whole model attributes. Also audit bricks that detect editor mode with a $data === null check, because they can misrender silently once previewData() is supplied. Treat previewData() as a data-egress channel and add it to code review checklists.
- Do I need to republish Filament assets after upgrading Mason?
- Yes. The postMessage origin fix and other browser-side changes ship in the compiled JavaScript bundle, so a Composer upgrade without php artisan filament:assets can leave a patched backend serving an older Alpine component. That failure is silent and can create false assurance in a security review. Capture build-log evidence that asset publishing ran and diff the compiled bundle in staging.
- How does Mason handle security and sanitization of brick content?
- Mason documents the trust boundary: sanitization and escaping of brick configuration are the application's responsibility. The package provides the editor and render path, but it does not enforce an allow-list for every field you choose to expose. If you let non-engineers author settings, embed URLs, or raw HTML, add a security requirement to that roadmap item's acceptance criteria. Review brick output and preview payloads before enabling broad editor access.
- Can I use Mason outside Filament panels or in a non-Filament admin?
- The editing experience is a Filament form field, so authoring happens inside a Filament panel. The rendering path is Blade-based, which means stored JSON can be rendered in ordinary Laravel views outside the admin surface. Mason does not provide models, APIs, or authentication, so a non-Filament editing UI would be custom work.
- How should I test Mason fields and brick rendering?
- Test at two seams: a Filament form containing Mason::make('content') with at least one registered brick, and a Blade view that renders stored JSON through the Mason directives. Since content persists as JSON in an existing column, assert the saved structure without expecting new migrations. Also run a staging deploy to prove filament:assets fires and clear compiled views once if styles appear stale. Treat every package fact as unconfirmed until reproduced against the installed artifact.