Upgraded to Django 1.8 and now you get this error when you run your tests?
Have you created migrations for all your apps? If not, you may well be hitting the problem that the database tables are being created in the wrong order, which will give you this error.
If you have an existing Django 1.7 or earlier project, then you need to create the initial migration files, and then fake the initial migration, as described here
Create the migration with
$ python manage.py make migrations your_app_label
And then fake the application
$ python manage.py migrate –fake-initial your_app_label
If you change the site URL in WP, it’s possible to lock yourself out of the admin site by virtue of a redirect loop.
If you’ve got access to the database, you can revert that change. If not…
You can update wp-config.php to override those settings; WP_HOME and WP_SITEURL.
Found this useful summary in Ask’s reply:
Group (runs in parallel): Error on one task does not stop the others
Chain (runs in serial): Error on one task halts the chain
Chord (group with callback): Error in group prevents callback from firing
Update: From Celery 3.0.14, this Chord behaviour is configurable. See CELERY_CHORD_PROPAGATES config option.
I was deeply sad to hear of the untimely death of John Pinner.
I met John at PyCon UK a few years ago, and very quickly learnt a great respect for him as a man, a friend, a mentor.
I saw him but once a year at the annual PyCon UK conference, and yet he had a great effect on me; I can only imagine the huge void that will be left by his passing for those who knew him more closely.
RIP John. I’m glad you were part of my life.
Currently available at $39 and upwards (May 2014)
Check the current live price at Luzme
Meteor is a new web framework which promises near-real time data updates on the client.
If you’re planning to learn how to learn Meteor (which you should, it’s awesome!), you need this book “Discover Meteor”.
Continue reading Review: “Discover Meteor”,Tom Coleman & Sacha Greif
For example, ‘15,99 EUR’
See whether you have the right locale installed.
$ locale -a
$ sudo apt-get install language-pack-es
$ sudo dpkg-reconfigure locales
And then in the code, you can do this
myprice = unicode(locale.atof(myprice))
I’ve been wanting to migrate away from django-registration for a while.
Yes, I know it’s been the default registration package since forever and I’ve used it happily for many years. But :
- it’s no longer actively maintained
- I want to do away with the email confirmation
- I want to allow login using either email or username
So after a bit of googling, I decided to try out django-allauth, and I’ve just finished the migration.
Here’s some notes for anyone else thinking about doing the same.
I’ve got an existing system:
Note: I’m only setting up the ‘accounts’ side of the allauth package, I’ll leave the social-accounts for later.
So here’s what I did:
- Set up django-allauth as per their documentation at http://django-allauth.readthedocs.org/
- Removed the django-registration module from the settings
- I wanted to use my own templates rather than theirs, so I added an account subdirectory into my accounts/templates and copied theirs over from the package. I needed to ensure that their package was called later in INSTALLED_APPS to make sure my templates were found first.
- Mostly the templates just worked by changing my copy of their templates to use my base template, and other cosmetic changes
- One minor gotcha was that the django-registration login template uses id_username as the field, whereas django-allauth uses id_login (since it can be either username or email)
- By default, allauth will produce a message for every action. Their base template displays these. I decided I didn’t want them; so following their instructions at http://django-allauth.readthedocs.org/en/latest/index.html?highlight=templates#messagesI replaced the provided templates with blanks.
- I added a redirect url from the old django-registration /accounts/register to the new django-allauth /accounts/signup
That was it. Much easier than I expected.
And the answer is…
I’m subclassing someone else’s form; I need to remove their input field and replace it with a fixed value.
def __init__(self, *args, **kwargs):
super(MyForm, self).__init__(*args, **kwargs)
# remove unwanted field
def clean(self, *args, **kwargs):
cleaned_data = super(MyForm, self).clean(*args, **kwargs)
# Restore field with fixed value
cleaned_data['fixedfield'] = FIXEDVALUE
Can’t find the upgrades because the ubuntu distribution is just too old?
Change /etc/apt/sources.list to use old-releases.ubuntu.com