kitlabs/kit-form-bundle
Kit Form Bundle provides reusable form components and helpers for Laravel applications, making it easier to build, validate, and render forms with a consistent, configurable API.
First, the stack check. Despite the catalog listing, kitlabs/kit-form-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no extra.laravel, and no config/app.php registration path. Confirm this before you spend time on a spike:
composer require kitlabs/kit-form-bundle # expect it to fail on a Laravel app
If you are on Symfony (4.x/5.x era), install proceeds normally and you register the bundle in config/bundles.php. If you are on Laravel — which the repo name and your question imply — the honest answer is that you cannot "leverage this package" directly. You have two real options: (a) treat it as reference code and reimplement two form macros/Blade components yourself, or (b) fork and vendor the JS asset wiring only. Everything below assumes either a Symfony spike or a port; the concepts carry over.
Where to look first. Read in this order:
composer.json — PHP and Symfony constraint ranges. This is your cheapest kill signal; a Symfony 3/4-era bundle will not install on 5/6/7 without conflicts on Twig and asset pipeline.Resources/ — this is where the Twig templates and any bundled JS/CSS live. Check whether UEditor/UMEditor/laydate assets are vendored or expected to be published manually (php bin/console assets:install --symlink → public/bundles/kitform/...).FulltextType, LaydateType) — the interesting part is the default option arrays (toolbar config, editor flavor, date format, min/max) and the buildView/finishView wiring that attaches assets.move_uploaded_file, $_FILES, extension whitelists, and path handling. This is a hard security gate, not a nice-to-have — legacy UEditor connectors have a documented history of arbitrary upload and RCE.First use case. A Chinese-language admin form with a rich-text body and a Laydate date input:
// Symfony Form
$builder
->add('body', FulltextType::class, ['editor' => 'ueditor'])
->add('publish_at', LaydateType::class, ['format' => 'yyyy-MM-dd HH:mm:ss']);
{{ form_start(form) }}
{{ form_row(form.body) }}
{{ form_row(form.publish_at) }}
{{ form_end(form) }}
That is the entire value proposition: asset registration + sensible CJK defaults for two widgets, roughly 1–2 dev-days of in-house work.
Wrap, don't sprinkle. Whatever stack you land on, define an internal facade so the rest of the app never references kitlabs/* directly. On Symfony that's a base type or option resolver; on Laravel it's a Blade component + a FormRequest rule set. This keeps the replacement path open when the editor migration inevitably comes.
// Symfony: project-level extension point
final class RichTextType extends AbstractType
{
public function configureOptions(OptionsResolver $r): void
{
$r->setDefaults(['editor' => 'ueditor', 'toolbar' => 'project-standard']);
}
}
Centralize editor config. UEditor/UMEditor behavior (toolbar layout, upload URL, paste-from-Word handling) lives in a JS config object, not in PHP. Put it in one place — a Twig global, a JSON blob from config, or a JS module — and pass options through the form type rather than duplicating defaults per form.
Two-phase rendering for heavy assets. These are large client-side bundles (UEditor especially). Do not bundle them into your main entrypoint. Register the asset in buildView and lazy-load it on the pages that actually host a rich-text field, or serve from CDN. In a ported Laravel version, use @push('scripts') in the component rather than a global @vite.
Standardize the date contract. Pick one wire format for Laydate and enforce it on both ends. The safest pattern is to let the widget produce a human string but normalize to ISO 8601 (Y-m-d H:i:s) server-side before persistence, and never trust the client format string. On Laravel, that's a prepareForValidation() cast; on Symfony, a DataTransformer.
Sanitize on the way out, not just in. HTML from these editors is stored XSS by default. Even in a Symfony spike, wire a server-side sanitizer (HTMLPurifier or Symfony's HtmlSanitizer) into the read path before |raw in Twig. On Laravel, this is an accessor or a Purify cast.
Migrate content, not the editor, where possible. If the requirement is "existing CMS content renders," your integration surface is really stored HTML dialect compatibility. Render UEditor output through a maintained editor (Tiptap/ProseMirror/CKEditor 5) with an adapter, rather than shipping the legacy editor forward. The bundle's option arrays are then a useful requirements checklist, not a runtime dependency.
composer require on Laravel and it installs, nothing happens until you manually port the types. Treat an unexpected successful install as a red flag for constraint laxity.public/bundles/kitform/... after assets:install. If assets are not vendored in the repo, you'll get silent missing editor CSS/JS — check the deployed public/bundles/ tree before debugging anything else.assetic: tags in the templates, budget for rewriting asset inclusion.format you set; if PHP's DateTime creation then assumes a different timezone than the browser, you get silent off-by-hours bugs. Always round-trip through a DataTransformer and assert the format server-side.Twig_Extension, getGlobals(), or other pre-2.x idioms. They warn-then-break on Symfony 5/6 upgrades and can block a framework major version bump.How can I help you explore Laravel packages today?