Color Picker Type Bundle Laravel Package

Getting Started

What you're actually getting. This is an archived Symfony2 bundle (MIT, 1 star, 0 dependents) that ships roughly three things: a form type class under Form/Type/, a Twig form-theme block that renders a text input plus the JS picker markup, and a small JS file under Resources/public/js/ that wires a jQuery-era color-picker plugin to that input. There is no server-side color logic, no validation, no data transformer, no tests.

Do not plan to use this in a Laravel app. Laravel has no form-type/theme system to hook into; the bundle's only value there is the JS picker, which you should pull from a maintained library and wrap in a Blade component. Use this package only when you're maintaining a legacy Symfony 2.x admin, or reading it as a reference for how to structure a custom widget.

Minimal steps (Symfony 2.x only):

1. Install. There is almost certainly no tagged release and no symfony/symfony version constraint, so expect to pin dev-master and possibly relax minimum-stability:

   "require": {
       "xmon/color-picker-type-bundle": "dev-master"
   }
   

   If Composer fights you on Symfony conflicts, stop resolving and vendor the source: copy Form/, Resources/, and the bundle class into src/Xmon/ColorPickerTypeBundle/.

2. Register the bundle in app/AppKernel.php:

   new Xmon\ColorPickerTypeBundle\XmonColorPickerTypeBundle(),
   

3. Publish assets and clear cache:

   php app/console assets:install web --symlink
   php app/console cache:clear
   

4. Read these four files first, in this order — they define everything the bundle does:

   • Form/Type/ColorPickerType.php — the getName() / service alias you'll use in form builders, and which options it accepts.
   • Resources/views/Form/*.html.twig — the block name (color_picker_widget or similar) you'll need to theme.
   • Resources/public/js/* — which picker plugin is bundled (or, more likely, merely referenced) and how it's initialized.
   • Resources/config/services.yml — whether the type is a service (form.type.color_picker) or instantiated directly.

5. First use case: a hex color field on an entity — brand/accent color, category label color, status badge color — edited in an admin CRUD. Entity gets protected $color; with @ORM\Column(type="string", length=7), and the form gets one line:

   $builder->add('color', new ColorPickerType());
   // or, if registered as a service with an alias:
   $builder->add('color', 'xmon_color_picker');
   

Implementation Patterns

The one-liner in a form. The intended workflow is exactly as above: add the type, get a text input with a picker attached. It accepts the standard field options (required, label, attr, data), so it composes normally with everything else in your form.

Make it a project type, not a bundle call. Don't scatter new ColorPickerType() through 30 form classes. Wrap it once:

// src/AppBundle/Form/Type/ColorType.php
class ColorType extends ColorPickerType
{
    public function setDefaultOptions(OptionsResolverInterface $resolver)
    {
        parent::setDefaultOptions($resolver);
        $resolver->setDefaults([
            'required' => false,
            'attr'     => ['placeholder' => '#RRGGBB', 'maxlength' => 7, 'class' => 'color-input'],
        ]);
    }

    public function getName() { return 'app_color'; }
}

Now every form says ->add('color', 'app_color') and changing the picker later is a one-file edit.

Global form theme (the pattern you want). Rather than adding {% form_theme %} to every template, register the block app-wide in config.yml:

twig:
    form:
        resources:
            - 'XmonColorPickerTypeBundle:Form:color_picker.html.twig'

Then any color_picker field renders correctly anywhere, including inside SensioGeneratorBundle CRUD templates you didn't hand-write.

Pair it with a DataTransformer for normalization. Users will paste #fff, fff, #FFF, or rgb(0,0,0). The bundle won't help, so normalize on the way in and store canonical #rrggbb:

class HexColorTransformer implements DataTransformerInterface
{
    public function transform($value) { return $value; }
    public function reverseTransform($value)
    {
        $value = strtolower(trim((string) $value));
        if (preg_match('/^#?([0-9a-f])([0-9a-f])([0-9a-f])$/', $value, $m)) {
            return sprintf('#%1$s%1$s%2$s%2$s%3$s%3$s', $m[1], $m[2], $m[3]);
        }
        return $value === '' ? null : $value;
    }
}

Swatch preview pattern. The picker's value is only visible on click; add a live swatch so editors see the color inline:

<div class="color-field">
    {{ form_widget(form.color) }}
    <span class="color-swatch" style="background: {{ form.color.vars.value|default('#ffffff') }}"></span>
</div>

$('.color-input').on('change keyup', function () {
    $(this).siblings('.color-swatch').css('background', $(this).val());
});

Integration tip — non-form contexts. The widget only exists inside a Symfony form render. If you need a picker in a settings page built by hand or in an AJAX-loaded modal, skip the form type and load the JS + markup yourself; don't try to render form widgets ad hoc.

Laravel porting pattern. If the goal is "do this in Laravel," the reusable idea is just the composition: one Blade component (<x-color-input name="brand_color" :value="$model->brand_color" />) that emits <input type="text"> plus a maintained picker mounted by Vite, one regex:/^#[0-9a-f]{6}$/i validation rule, and a HexColor cast or mutator to normalize. That's a half-day of work and replaces this bundle entirely.

Gotchas and Tips

It is archived with zero dependents. No security fixes, no Symfony compatibility work, no issue triage. Treat it as vendored code you now own, not as a dependency. Read composer.json before installing — an unconstrained symfony/* requirement will fight a modern lockfile, and even in a legacy app it may drag in an incompatible constraint.

Symfony 2.x only. The form type API changed hard in Symfony 3: setDefaultOptions(OptionsResolverInterface) became configureOptions(OptionsResolver), and getName() was removed in favor of the FQCN as alias in 2.8/3.0. On top of that, Bundle:Form:file.html.twig template notation is deprecated from 3.0 and gone in 4.0. If your app is Symfony 3+, expect to rewrite both the type and the theme path before anything renders.

Missing JS fails silently. The bundle's template likely assumes a picker plugin (and jQuery) is already loaded in your layout. If it isn't, you get a perfectly functional text input and no error — which reads as "the bundle is broken." Check the network tab and the bundle's Resources/public/js before debugging PHP.

CSP and inline scripts. These older picker integrations initialize with an inline <script> in the widget block. Under a strict Content-Security-Policy that silently dies. Move the init call into your compiled JS, keyed off a data-color-picker attribute in your own theme override.

You must add validation — and it matters for security. The bundle stores whatever string the user typed or pasted. If that value reaches style="color: {{ entity.color }}" unescaped or unvalidated, you've handed over CSS injection. Always pair the field with:

new Assert\Regex(['pattern' => '/^#[0-9a-f]{6}$/i'])

and render it with escaping (Twig's {{ }} in an attribute is escaped by default — don't |raw it).

Extension points are exactly two, and they're both shallow: override the widget block in your own form theme (define the same block name — Twig takes the last registered resource), or subclass the form type to change defaults. To swap the picker library, replace the bundle's public JS and adjust the init call in your theme override; there's no configuration knob for it.

Asset/cache footguns. After assets:install --symlink you may still see the old widget because of the Twig/prod cache; cache:clear and, if Assetic is in play, assetic:dump --env=prod. If you vendored the source instead of installing via Composer, the Twig theme path changes — fix it in config.yml at the same time.

Accessibility. jQuery-era picker popups are usually mouse-only. Keep the text input fully functional (it already is), add a hex hint via placeholder, and don't make the picker the only way to set a value — screen-reader and keyboard users get nothing from it.

Don't extend it upward. If you find yourself needing alpha channels, named colors, or a palette endpoint, stop: the archived codebase won't carry that weight. Replace the widget with a maintained picker and keep only the form-type wrapper, which is the one genuinely reusable 40 lines here.