Wysiwyg Field Bundle Laravel Package

Getting Started

This bundle provides a wysiwyg field type for Unite CMS, which renders a rich text editor in the admin UI and stores HTML (typically) in the underlying content type. Because Unite CMS is a Symfony-based headless CMS, the bundle plugs into the field-type registry via a Symfony service tag — you don't "use" it directly in application code, you configure it on a content type.

Minimum steps:

1. Install the bundle via Composer in your Unite CMS project:

   composer require unite-cms/wysiwyg-field-bundle
   

2. Register it in config/bundles.php if it isn't auto-registered by Symfony Flex:

   UniteCMS\WysiwygFieldBundle\UniteCMSWysiwygFieldBundle::class => ['all' => true],
   

3. Verify the field type is registered. Unite CMS exposes available field types through the GraphQL introspection endpoint (__type on the content type input). If the schema rebuilds cleanly and wysiwyg appears in the field-type list, you're wired up.
4. First use case: open the Unite CMS admin, edit a content type, add a wysiwyg field (e.g. body), then create/edit a content item — the editor renders in the form and the HTML is queryable via GraphQL after save.

Look at src/ first: the field type class (usually implementing UniteCMS\CoreBundle\Field\FieldType) and Resources/config/services.yml tell you what config keys are honored and what the GraphQL output type is.

Implementation Patterns

Defining a field in the content type config (YAML / admin UI):

body:
  type: wysiwyg
  title: Body
  settings:
    # typical keys: toolbar, height, allowed tags, sanitization

Use the admin UI for exploration, but commit the exported content-type YAML to version control so schema changes are reviewable.

Reading and rendering content. Unite CMS returns the stored value (HTML string) through GraphQL. Treat it as HTML and sanitize on output — a headless CMS should not assume the client is the trusted admin UI:

// Controller / API consumer
echo $purifier->purify($content['body']);

For Symfony + Twig consumers, wire up html-sanitizer (or HTMLPurifier) in your app so rendering is consistent across headless and server-rendered paths.

Seeding / fixtures. Because the field is just a string field underneath, you can programmatically set it via the Unite CMS PHP SDK or by POSTing to the GraphQL mutation:

mutation($id: ID!, $data: bodyContentTypeInput!) {
  updateBodyContent(id: $id, data: $data) { id }
}

Pass the HTML string as the value of the body key.

Reusing editor HTML in other surfaces. The bundle stores raw HTML — do not store Markdown. If you need Markdown in a different pipeline (e.g., static site generator), convert at read time, not at write time, to keep the CMS consistent.

Version the content-type schema, not the bundle's config. Field settings (toolbar, allowed elements) belong to the content type; commit them. That way environments (dev/prod, multiple editors) render the same editor.

Gotchas and Tips

• Headless = trust boundary shift. Stored HTML is not automatically safe. Sanitize on read (or with a whitelist on write if you control the editor config) — XSS via admin content is a real risk when the CMS is consumed by a public frontend.
• Field type registration failures are quiet. If the bundle isn't registered, the content type fails schema validation with a generic "unknown field type" error. Check bin/console debug:container --tag=unite_cms.field_type (tag name may vary) before assuming a bundle bug.
• Config keys are not self-documenting. WYSIWYG field bundles tend to pass settings straight to the underlying editor (CKEditor/TinyMCE/Quill). If a setting is ignored, log the received settings in the field type's normalizeInput/serialize and confirm the actual key names — Unite CMS conventions (camelCase vs snake_case) may differ from the editor's native options.
• Empty vs null. HTML editors often submit "" for empty content; some Unite CMS versions treat "" as non-empty for validation/required rules. Trim/empty-check before saving if required: true behaves oddly.
• Symfony cache. The field-type registry is cached. After updating the bundle or changing a field's type, run bin/console cache:clear and reload the admin — schema changes don't appear until the GraphQL schema is rebuilt.
• Extending. If you need custom sanitization or a different editor, don't fork the bundle — decorate the field type service or add a compiler pass that tags your own field type using the same base class. The bundle is thin; most customization lives in content-type settings and your output pipeline.
• No dependents is a signal. With zero downstream users, expect thin documentation and untested edge cases (nested fields, translation handling, draft/publish diffing). Smoke-test those paths yourself before relying on it in production, and pin the bundle version.