Tincymicy Field Laravel Package

Getting Started

• Install the v2 release with composer require mohamed7sameer/tincymicy-field, then confirm the package’s service provider is auto-discovered or registered.
• Read the v2 compare link first: https://github.com/mohamed7sameer/tincymicy-field/compare/v1...v2. Since that is the only published release note, verify namespace, config, asset, and API changes before upgrading existing forms.
• Look first for published config/assets (php artisan vendor:publish --provider="...") and the package README for the field class name and supported editor options.
• First use case: add a rich-text field to an admin/resource form for a longText column, for example a body or content attribute, then save and render sanitized HTML on the front end.

Implementation Patterns

• Use the field directly in the form schema:

use Mohamed7sameer\TincymicyField\TincymicyField;

TincymicyField::make('content')
    ->rules('required', 'max:65535')
    ->help('Rich text content rendered on the public page.');

• Configure editor behavior per field when different forms need different toolbars:

TincymicyField::make('content')
    ->options([
        'height' => 500,
        'menubar' => false,
        'plugins' => 'lists link table code',
        'toolbar' => 'bold italic | bullist numlist | link table | code',
    ]);

• Prefer global config for shared TinyMCE defaults: toolbar, plugins, content CSS, upload endpoints, and menubar. Keep field-level overrides only for exceptional forms.
• Store HTML in a longText/text column, not a short string. Sanitize on output or before persistence with a trusted HTML purifier; never render raw user HTML without a policy.
• If the package supports uploads, configure disk, directory, max size, and MIME validation centrally. If it does not, pair the field with a separate media library or upload field.
• For index/detail views, avoid dumping full HTML into table cells. Use a plain-text excerpt or a custom formatter, and keep the rich field on the detail/edit form.
• In tests, assert the field is present on the form and that submitted HTML is stored/sanitized as expected. For browser-level checks, confirm TinyMCE initializes after the form is mounted.
• When upgrading v1 to v2, pin the version in staging, run composer update, clear caches, republish assets if required, and smoke-test create/edit/detail flows before production.

Gotchas and Tips

• The v2 release note is only a changelog link. Treat the compare view as mandatory upgrade reading; do not assume backward compatibility from the version bump alone.
• TinyMCE is client-side. If the editor does not appear, check published assets, asset caching, CSP rules, and whether the field’s JS is loaded on the page.
• Clear Laravel and Nova/package caches after config or asset changes: php artisan config:clear, php artisan view:clear, and any package-specific publish/cache commands.
• Rich text is an XSS boundary. Sanitize HTML server-side and use a strict allowlist for tags/attributes; do not rely on client-side editor cleanup.
• Long HTML content can exceed default validation or database limits. Use longText, set realistic max rules, and avoid string columns.
• Empty editor content can arrive as <p></p> or whitespace. Normalize empty values before validation and before rendering.
• If using TinyMCE Cloud/plugins, confirm API keys, domain approvals, and CORS. For self-hosted TinyMCE, verify the base URL and plugin paths.
• Extension points to check in v2: publishable config, field option serialization, custom toolbar/plugin registration, upload callbacks, and whether the field can be subclassed for project-specific behavior.