search

presseddigital / colorit

A slick color picker fieldtype plugin for the Craft CMS control panel
Other
21 stars 8 forks source link

Critical: Presets don't show correct colors, defaults to light grey #32

Closed mattaebersold closed 3 years ago

mattaebersold commented 3 years ago

Preset set, and showing colors in plugin settings: image image

Using a supertable field set to colorit, but here's the set of presets: image

And furthermore, in the entry edit view image

iamtompickering commented 3 years ago

@mattaebersold I've also just come across this issue. Bit of a strange one, because it is working as expected for some preset colours, but not for others...

Screenshot 2021-05-13 at 11 12 34

Looking in Dev Tools, the # is missing.

hinderson commented 3 years ago

I have the same issue. Seems like Craft has changed how they're storing hex values for the native color field (which this plugin uses) – they're now without the # prefix. It's only an issue for new fields or updated fields, so it took me a while to discover it.

I made a fork with a quick fix to make the preview's show, but it's very much a hack and I'm not sure of the larger consequences of using it like this. https://github.com/SPRNGSMMR/colorit/tree/bugfix

chadcrowell commented 3 years ago

Same issue here. It appears to me to be working fine within a Super Table but not within a Matrix. (or perhaps, that Super Table field hasn't been updated, but the Matrix one has, as @hinderson noted above)

robzor commented 3 years ago

I've also got this issue, has anyone heard anything back from the devs?

samhibberd commented 3 years ago

So sorry for the silence, we have literally just hit the launch button on what has been an all consuming 18 month project for our entire team, lucky that our partners are still talking to us all, let alone everyone else!

Anyway we should finally have some time to give our plugins some well overdue attention, please bear with us whilst we get our lives back on track!!!

Thanks.

S

robzor commented 3 years ago

Hi @samhibberd thanks for getting back to me, I totally understand all consuming projects!

Can I please ask if you have any sort of ETA on a fix for this? I'm currently working on a client site and there really isn't a suitable alternative to your plugin that will work for them.

Just to clarify, this is what you see on a field. And if you choose any of the swatches, they do not output on the front-end either.

CleanShot 2021-06-11 at 11 56 24

proimage commented 3 years ago

Here's hoping it's a simple fix; it seems like it should be...

david-garcia-jr commented 3 years ago

Screen Shot 2021-06-23 at 10 30 15 AM

Looks like the hash is missing from all custom color presets.

pelmered commented 3 years ago

Any progress with this? We have had this problem in production for almost two months now.

It is a pretty critical bug and it should be a pretty simple fix as far as I can tell.

david-garcia-jr commented 3 years ago

Any progress with this? We have had this problem in production for almost two months now.

It is a pretty critical bug and it should be a pretty simple fix as far as I can tell.

Same here, we used this field type heavily in a recent production site and all colors were dropped from a large number of components. Unfortunately, we have had to revert to Crafts default color field.

pelmered commented 3 years ago

Yes, we will probably have to revert to the default as well. I don't feel like this plugin can be trusted anymore unfortunately.

robzor commented 3 years ago

I've ended up having to use a Super Table with a combination of both a native Colour field and this: https://github.com/percipioglobal/craft-colour-swatches

Hopefully the guys will get some time to fix the bug soon though, as I prefer the UX of this plugin to the current client's needs.

extensibleseth commented 3 years ago

I had some luck using @hinderson's changes, and updating the regex in /helpers/ColorHelper.php isValidHex(). The leading # is optional now.

/^#[0-9a-f]{3}(?:[0-9a-f]{3})?$/i to /^#?[0-9a-f]{3}(?:[0-9a-f]{3})?$/i

proimage commented 3 years ago

Any progress on this, peeps? Seems like this would be low-hanging fruit, no? :-/

ben-callaway commented 3 years ago

Fixed in 82872ca. Thanks for your patience everyone!

sunscreem commented 3 years ago

Hey @ben-callaway can I quickly check. I've just ran a batch updates which included 1.1.0 and 1.1.1.

In order to see things working again I needed to resave all entries using ./craft resave/entries and also find everywhere in the front end where I've output the hex code and add the missing #.. eg style="border-color: {{ block.colour }}" becomes style="border-color: #{{ block.colour }}".

Does that sound right?

ben-callaway commented 3 years ago

@sunscreem I've just pushed an update (1.1.2.1) so the Auto (Best Guess) option now either outputs the HEX value including the hash or RGBa depending on the opacity value used. This means the default fieldtype twig can be used for all color options set in the CP. You can still choose to output with or without the # as required.

proimage commented 3 years ago

This is still a problem and really needs fixing, guys. See issue #36. 😠