I am using django-colorfield in one of my project, it's awesome but I needed a way to get a list overview of the color to make sure they don't clash to much with one another.

So instead of displaying the hex value, it would be great to have a similar colored badge (except without the picker) as the creating/editing admin views.

As a temporary workaround, I am just coloring the background of the list view to the color using an extended admin template like so:

{% extends "admin/change_list.html" %}

{% block extrahead %}
    {{ block.super }}
    <script>
        function getTextColor(backgroundColor) {
            const color = (backgroundColor.charAt(0) === '#') ? backgroundColor.substring(1, 7) : backgroundColor;
            const r = parseInt(color.substring(0, 2), 16); // hexToR
            const g = parseInt(color.substring(2, 4), 16); // hexToG
            const b = parseInt(color.substring(4, 6), 16); // hexToB
            const yiq = ((r * 299) + (g * 587) + (b * 114)) / 1000;
            return (yiq >= 128) ? 'black' : 'white';
        }

        document.addEventListener("DOMContentLoaded", function (event) {
            const color_td = document.querySelectorAll("td.field-color");
            color_td.forEach(function (td) {
                const color = td.innerText;
                td.style.backgroundColor = color;
                td.style.color = getTextColor(color);
            });
        });
    </script>
{% endblock %}

which looks like this:

I was thinking maybe this would be a feature others would be interested in, though I don't know how easy it would to make generic and configurable in the project. Other than this, going from setting the background color to a nice colored badge is not such a big leap.

If you are interested I can look more into the code base and see if I can implement it and submit a PR.

Python version
3.6

Django version
2.1

Package version
0.2.2

Current behavior (bug description)
When I set default = None or default = '' the default value is still used.

Expected behavior
I would expect no value to be displayed when this form initially is displayed. Thus forcing the user to enter a value if the field is required or not saving a value at all in the database.

Python version
3.8

Django version
3.2

Package version
0.7.2

Current behavior (bug description)
Using image_field, if the uploaded image is corrupted a UnidentifiedImageError is raised and the whole model save is interrupted.

Expected behavior
Handle the error, extract no color and continue saving model correctly.

Python version
3.7.5

Django version
3.0.3

Package version
0.3.0

Current behavior (bug description)
After including a color_field in my model like described in the Readme of this repo and after running a collectstatics I am able to pick a color via the colorpicker like expected in the django admin panel. But when including the form field in a custom view and html page like the following, the colorpicker will simply not pop up:

<div class="form-group row">
        <div class="col-sm-2">{{ form.color_field.label }}</div>
        <div class="col-sm-10">{{ form.color_field }}</div>
</div>

When using the Firefox inspector I see that my <div> field does not have the "event" thing at the end of the line, like it does in the admin panel. So I assume it has something to do static files and the corresponding js files not being able to attach to the relevant input field. Obviously I'm not a js programmer and do not know how to debug this further.

Expected behavior
I would like the color picker to show when clicking into the input field in my custom view / html page. Any help is appreciated!

Thanks for your work and this nice tool!

Shouldn't this be STATIC_URL? Otherwise it's trying to find colorfield/jscolor.js in my client-uploaded media directory!

the color.html is not found

I need a new release in order to import correctly the library, right now it is not working with my python 2 project.

The latest setup.py states that it is v0.1.1 but if you download django-colorfield v0.1.1 from PyPI (with pip install django-colorfield==0.1.1) then the field freezing stuff for south is missing. Here's a copy of the content of fields.py for v0.1.1 hosted at PyPI.

#!/usr/bin/env python

import re

from django import forms
from django.db import models
from django.conf import settings
from django.core.validators import RegexValidator
from django.template.loader import render_to_string
from django.utils.translation import ugettext_lazy as _

color_re = re.compile('^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$')
validate_color = RegexValidator(color_re, _(u'Enter a valid color.'), 'invalid')

class ColorWidget(forms.Widget):
    class Media:
        js = [settings.MEDIA_URL + 'colorfield/jscolor.js']

    def render(self, name, value, attrs=None):
        return render_to_string('colorfield/color.html', locals())

class ColorField(models.CharField):
    default_validators = [validate_color]

    def __init__(self, *args, **kwargs):
        kwargs['max_length'] = 10
        super(ColorField, self).__init__(*args, **kwargs)

    def formfield(self, **kwargs):
        kwargs['widget'] = ColorWidget
        return super(ColorField, self).formfield(**kwargs)

# vim: et sw=4 sts=4

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
The application is missing the ability to add transparency settings to hex code (which is now the additional 2 characters you can add to a hex code).

For example, if you want to have a transparent black color you can now type: #50, or for white you can do #FFFFFF50. There's also the short hand extra character #FFF5. A full color would be #FFFF or #FFFFFFFF. A clear color would be #FFF0 or #FFFFFF00.

Describe the solution you'd like
A clear and concise description of what you want to happen.
I'd like to be able to add 2 additional characters (or do the shorthand version as well of 4 characters) and see a transition option on the color picker.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Personally I'm ok with using just a CharField, but that kind of kills the point of having a color picker lol.

Additional context
Add any other context or screenshots about the feature request here.
That's really it!

This is how VSCode does it:

Python version
3.8

Django version
3.0.7

Package version
0.3.2 (including jscolor 2.1.1)

Browser
Safari and Chrome

Current behavior (bug description)
Validation error on admin screen "Enter a valid color."
Occurs for colour edited via picker, or default colour or colour with # previously read from database.
On deeper inspection colours selected with colour picker are displayed without a leading hash symbol. Value without leading hash then fails validation at line 16 of fields.py. (have added additional validator to intercept and confirm value to be validated has no leading hash).

When reading colour from database (that had a leading hash) the colour is now displayed without the leading hash and validation fails on save even if colour not changed.

Have run collect static to verify have latest JS.

Have recently upgraded number of other library including upgrade to Django 3.0.7

See image below.

Expected behaviour
Unchanged colour and picked colour will not cause validation error.
Leading hash preserved on entered/default colour.

Heyo! I decided to give a go at adding the ability to do selection of a specific colorset, and what I thought would be quick is turning into a nightmare :( I can't get even the most basic case working - a list of issues:

• installation with an egg doesn't properly add templates unless the template loader is active
• I never got the static files to be added from colorfields
• it's not actually clear how to render the template, and interact in views

I have most of a dockerized image (in the example folder) here, and it would be really great to get a clean (base /dummy app) working so the additional features can be developed. I'm a bit frustrated so taking a break for now, thanks for your help!

https://github.com/vsoch/django-colorfield/tree/color-limits

Given that a hex colour is at most 7 characters (including the #), why is max_length set to 10 on this line?

Thanks a lot for this project. I understand that you're not actively developing on Django anymore, but this appears to still be the best one out there, so I'm going to use it anyway.

Given that jscolor is GPL3, doesn't that mandate that django-colorfield must also be GPL3?

I have given a default hex value ('#FFC107') in the model field. But the widget still gets initialized with #FFFFFF .
Any clue as to why this is happening?

I recently started using django-colorfield in a commercial application. I assumed that this was OK, given the MIT license advertised here. However, on the official jscolor page they clearly describe their commercial license.

So, without purchasing a commercial license from jscolor is is inappropriate to use django-colorfield in any non-open-source software.

Python version
3.8

Django version
3.2

Package version
0.6.0

Current behavior (bug description)
A ValueError: seek of closed file is raised when saving image in the backend and the field has the image_field property set.

Expected behavior
No exception should be raised.

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

Hi,
Saving a field of type colorField does not allow saving null or blank.
Thanks.

color_hex_1 = ColorField() color_hex_2 = ColorField(blank=True, null=True) color_hex_3 = ColorField(blank=True, null=True)

cannot pass widget attrs for modal at bootstrap4

ColorWidget(attrs={'class': 'form-control colorfield_field jscolor {zIndex: 1080}'})

I'm a senior python developer and use django for day to day task

default_storage can actually be completely different to staticfiles_storage method (for example use s3 for default but local on the static files). Its and easy fix, I will add a pull request.

Python version
3.6

Django version
2.1

Package version
0.2.2

Current behavior (bug description)
When the color field initial loads it is setting the color to a value of 'FFFFFF'. This causes an error to be thrown. Even if I change the color the '#' is still not added to the value. Therefore it's an invalid color.

Expected behavior
I expect it to consider colors without a '#' valid or to add the '#' as needed.

Strangely enough after I click save and the validation runs a '#' is added to the value and the item will save just fine.

The continuation of #68

Color can be auto generated at object save, and therefor can be read only in admin panel. It would be great if the color chip whould stay even on readonly value.

Python version
3.6

Django version
3.0.5

Package version
0.3.2

Current behavior (bug description)
I have 4 color fields. The first one does not change color when I move the slider, but the rest of them do.

Code:

class Test(models.Model):
  test1 = ColorField('Baggrundsfarve', max_length = 7, blank = True)
  test2 = ColorField('Temafarve 1', max_length = 7, blank = True)
  test3 = ColorField('Temafarve 2', max_length = 7, blank = True)
  test4 = ColorField('Tekstfarve', max_length = 7, blank = True, default = '#FFFFFF')

Expected behavior
Color fields should change background colors when the slider is moved.

Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "/tmp/pip-build-F9fkD5/django-colorfield/setup.py", line 3, in <module>
    with open("README.md") as readme_file:
    IOError: [Errno 2] No such file or directory: 'README.md'

Seems like MANIFEST.in still references README.rst

Hi,

I have a project that uses django-color and all went swimmingly, while I was using 0.1.10. Thanks for a very useful field! However, after I've upgraded to 0.1.14, it would never validate the color string, such as "#FF0000" I've used as default. I have solved the problem by rolling back to 0.1.10. I am not sure what kind of diagnostic I can provide for the issue.

Best regards,
Alexander

Python version
Python 3.9.1

Django version
Django==3.1.6

Package version
?

Current behavior (bug description)
I have this field in models.py:
backgroundColor = ColorField(default="#ffffff")
And in form.py:

class MyForm(ModelForm):
    def __init__(self, *args, **kwargs):
        super(MyForm, self).__init__(*args, **kwargs)
        self.fields['backgroundColor'].widget.attrs['disabled'] = 'disabled'

Expected behavior
I want it to disable the color field but the field is still enabled.

I'm not sure if this is happening to anyone else but the color widget won't show up in my form. Assuming that I have the correct code implementation as followed from Django Tutorials:

from django import forms
from .models import MyModel
from colorfield.fields import ColorWidget

class MyModelForm(forms.ModelForm):
    class Meta:
        model = MyModel
        fields =  ('myModel_id','agency_id', 'short_name', 'long_name',
                   'description', 'rtype', 'url')
        widgets = {
            'color' : forms.CharField(widget=ColorWidget),
            'text_color':forms.CharField(widget=ColorWidget)
        }

Am I doing a wrong implementation?
Thanks in advance!

Just discovered this code, was wondering what the license on it is.

Python version
3.8

Django version
3.2.8

Package version
0.4.4

Current behavior (bug description)
Rendering the input field in an html template leaves the name attribute empty, thus the input value is not submitted.

Expected behavior
The input element should have the name attribute set according to the name of the input field.

This can be fixed by passing the name from the render method to the template via the context.

The ColorField is initialized with a 'None' value which in turn causes the whole inline model to be required.

Python version
3.7.6

Django version
3.0.3

Package version
3.2.1

Current behavior (bug description)
When viewing model or trying to create a new model in admin panel (dev mode), I get the following error:

TemplateDoesNotExist at /admin/dashtile/dashtile/80/change/
colorfield/color.html

This was after I added a color field to a model, then ran makemigrations and migrate, with that being the only change.

The field I added:

iconBackground = ColorField('iconBackground', default='#000000', blank=True).  

Expected behavior
I should be able to view the model in the admin panel.

JScolor is licensed GPLv3 . We are distributing this lib as MIT with GPL code. JSColor has clearly stated as

If you are creating an open source application under a license compatible with the GNU GPL license v3, feel free to use jscolor under the terms of GNU GPL license v3.

Using and distributing this lib as MIT is a violation of GPL.
We have to either release as GPL (viral behaviour of GPL) or reconsider the js color picker lib,
Any thoughts on this?

TemplateDoesNotExist -> colorfield/color.html
"templates" folder and "static" folder are not included in the dist package.

I think the problem is in MANIFEST.in or in setup.py,
could you fix it? I need to use django-colorfield as an external dependency of another package.

Is your feature request related to a problem? Please describe.
I'm using ColorField in an HTML builder app. It's really nice but (I think?) it only supports hex colors.

Describe the solution you'd like
Add support for RGB, RGBA and HTML-named colors.

Describe alternatives you've considered
Alternatively I may couple the ColorField with a custom ColorFieldDisplayType field, with choices like 'hex', 'rgb', 'rgba' and 'html-name' and a translation function. The only real issue here is handling alpha becomes problematic between types.

Hi,
Extends bug #7
When editing a model that has an inline colorField from the django administration interface, the library correctly displays the color picker, but when a new record is added in this same model that contains an inline-model, it does not display the picker because it loads colorField.js first and then jquery.

The exception raised is:

'ColorWidget' object has no attribute 'template_name'

...everything was working just fine in v1.10.x. It appears the widget API changed from v1.11.0 onwards, see https://docs.djangoproject.com/en/2.0/ref/forms/widgets/#django.forms.Widget.get_context, noting the sections highlighted with New in Django 1.11.

I think COLOR_CHOICES will help users quickly choose the color what he want.The colors in COLOR_CHOICES are just recommendation for users.If users want to choose other colors that not in COLOR_CHOICES,I think he can also submit.Otherwise, the COLOR_CHOICES appearing while the color picker exist will be meaningless.

@jaredly since you are no more active on this repository, could you transfer to me the ownership of this repo?

Python version
3.8

Django version
3.0

Package version
0.3.0

Current behavior (bug description)
Is not possible to use the colorpicker in bootstrap modal because the z-index of the modal is higher (1050 vs 1000) and the colorpicker stays in background

Expected behavior
A way to change the z-index via js or via css

The lack of comma here on line 43:

results in implicit string concatenation, so 'django.contrib.messages.middleware.MessageMiddleware' will get concatenated with the next line 'django.contrib.sessions.middleware.SessionMiddleware', resulting in Django attempting to import a class from 'django.contrib.messages.middleware.MessageMiddlewaredjango.contrib.sessions.middleware.SessionMiddleware', which will of course fail.

It looks like Django <2.0 is still supported so I think this should be fixed

I can make a PR for you :)

Does the module allow for selection from a core set of colors? (versus the whole gamut!)

Using django 1.6

Python version
3.8.3

Django version
2.2.x

Package version
0.4.0

Current behavior (bug description)

• I have a model with ColorFields in it using an older 0.3.2 release of this package
• just upgraded to 0.4.0
• new palette choice code in the formfield() method causes a 500 error in the model admin

Essentially, I don't override choices in the model definition, choices weren't a thing in older versions of the package

The choices default to constructing as empty list, []:

When rendering the form-field, your new palette code runs:

palette = []
if self.choices is not None:
    choices = self.get_choices(include_blank=False)
    palette = [choice[0] for choice in choices]

...since self.choices is [], not None, is calls super get_choices()...

        if self.choices:
            choices = list(self.choices)
            if include_blank:
                blank_defined = any(choice in ('', None) for choice, _ in self.flatchoices)
                if not blank_defined:
                    choices = blank_choice + choices
            return choices
        rel_model = self.remote_field.model

...since choices is [], it is falsy, the field choices therefore falls through the first if-statement to the lower part of the method that assumes a relational field (e.g. a ForeignKey field)...it tries to do things with self.remote_field

KABLAM! :-D

Expected behavior

This should not crash

Recommend you fix by changing the choice-check in Colorfield.formfield() from "if self.choices is not None" to simply "if self.choices", in-line with the underlying Django

Python version
2.7.18

Django version
1.8

Package version
0.4.2

Current behavior (bug description)

app_1     | Internal Server Error: /admin/{{form}}/add/
app_1     | Traceback (most recent call last):
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 164, in get_response
app_1     |     response = response.render()
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/response.py", line 158, in render
app_1     |     self.content = self.rendered_content
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/response.py", line 135, in rendered_content
app_1     |     content = template.render(context, self._request)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", line 74, in render
app_1     |     return self.template.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 209, in render
app_1     |     return self._render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/test/utils.py", line 96, in instrumented_test_render
app_1     |     return self.nodelist.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 903, in render
app_1     |     bit = self.render_node(node, context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/debug.py", line 79, in render_node
app_1     |     return node.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/loader_tags.py", line 135, in render
app_1     |     return compiled_parent._render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/test/utils.py", line 96, in instrumented_test_render
app_1     |     return self.nodelist.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 903, in render
app_1     |     bit = self.render_node(node, context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/debug.py", line 79, in render_node
app_1     |     return node.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/loader_tags.py", line 135, in render
app_1     |     return compiled_parent._render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/test/utils.py", line 96, in instrumented_test_render
app_1     |     return self.nodelist.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 903, in render
app_1     |     bit = self.render_node(node, context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/debug.py", line 79, in render_node
app_1     |     return node.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/loader_tags.py", line 65, in render
app_1     |     result = block.nodelist.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 903, in render
app_1     |     bit = self.render_node(node, context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/debug.py", line 79, in render_node
app_1     |     return node.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/loader_tags.py", line 65, in render
app_1     |     result = block.nodelist.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 903, in render
app_1     |     bit = self.render_node(node, context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/debug.py", line 79, in render_node
app_1     |     return node.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/defaulttags.py", line 217, in render
app_1     |     nodelist.append(node.render(context))
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/loader_tags.py", line 159, in render
app_1     |     return template.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 211, in render
app_1     |     return self._render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/test/utils.py", line 96, in instrumented_test_render
app_1     |     return self.nodelist.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 903, in render
app_1     |     bit = self.render_node(node, context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/debug.py", line 79, in render_node
app_1     |     return node.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/defaulttags.py", line 217, in render
app_1     |     nodelist.append(node.render(context))
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/defaulttags.py", line 217, in render
app_1     |     nodelist.append(node.render(context))
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/defaulttags.py", line 329, in render
app_1     |     return nodelist.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 903, in render
app_1     |     bit = self.render_node(node, context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/debug.py", line 79, in render_node
app_1     |     return node.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/defaulttags.py", line 329, in render
app_1     |     return nodelist.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 903, in render
app_1     |     bit = self.render_node(node, context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/debug.py", line 79, in render_node
app_1     |     return node.render(context)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/template/debug.py", line 92, in render
app_1     |     output = force_text(output)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/utils/encoding.py", line 92, in force_text
app_1     |     s = six.text_type(s)
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/utils/html.py", line 390, in <lambda>
app_1     |     klass.__unicode__ = lambda self: mark_safe(klass_unicode(self))
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/forms/forms.py", line 543, in __str__
app_1     |     return self.as_widget()
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/forms/forms.py", line 599, in as_widget
app_1     |     return force_text(widget.render(name, self.value(), attrs=attrs))
app_1     |   File "/usr/local/lib/python2.7/site-packages/django/forms/widgets.py", line 209, in render
app_1     |     raise NotImplementedError('subclasses of Widget must provide a render() method')
app_1     | NotImplementedError: subclasses of Widget must provide a render() method

Expected behavior
works like the doc.

GET http://192.168.0.102:8000/media/colorfield/jscolor/jscolor.js 404 error

JSColor is only GNU GPL v3 for open source, GNU GPL v3 compatible, licenses. For anything else it requires a paid commercial license.
https://jscolor.com/download/

Python version
2.7

Django version
1.11

Package version
0.7.1

Current behavior (bug description)
When the palette options are not used, the input renders with the data-jscolor attribute ending with ...,palette:}. It causes the options to be ignored, e.g. a non-required field becomes required.

Expected behavior
An empty palette should not cause other options to be ignored.