The senior developer (and the only person experienced with Django in our company) has moved away and left us. Shortly after this (following his instructions) we pushed a site live onto a shared server (we have full control over the server) and updated the version of Django to the latest release for the new site to work.
Since then we have had issues with the other Django project on there which was built using an older version.
The main issue that I have is that we have a crontab that sends an email to the client outlining their orders. I have taken a screen grab of the error that I am getting but if I am honest I am struggling to make any sense of it. The names have been changed to protect the innocent (client).
http://i-am-a-fish.co.uk/help.png
I have uploaded a screen grab again i-am-a-fish.co.uk/help2.png
All suggestions are very welcomed!
Deprecation warning is not the reason, you can ignore it (unless you want to fix and use hashlib). The reason is multipart_subtype which your custom EmailAlternativesMessage class is not defining. Try to find declaration of EmailAlternativesMessage and add
class EmailAlternativesMessage(EmailMessage):
multipart_subtype = 'alternative'
...
Now that your immediate problem is fixed, the real solution here is to use virtualenv to isolate each project's dependencies (including Django itself) from the others, so deploying a project based on recent Django doesn't require an immediate upgrade of every other site on the server.
Related
There are two main schools of thought for doing A/B (Split) Testing:
Javascript-based solutions such as Optimizely, Google Analytics Content Experiments.
Server-side solutions such as Django-AB, Splango, and django-lean. (Also, writing your own.)
My understanding is that Javascript-based solutions are spectacular for "which color button converts better," but not so great for switching out entire page layouts, and completely unworkable for trying out large functional changes such as the sequence of pages in a funnel.
That leads me towards a server-side solution. I'm not crazy about coding my own, and will do so only if there is no other option. I'm trying to add value by improving the core functionality of my site, not by creating a better split-testing framework.
The Django apps I've found for split testing are various mixtures of unmaintained, undocumented, documented incorrectly, and incompatible with Django 1.5. This surprises me, because the Django and Python communities seem to have a strong focus on good documentation. I'm also very surprised that none of the testing frameworks I've tried has been compatible with Django 1.5 -- is testing not as core a part of the philosophy in the Django/Python world as it is in Rails?
Here's what I've found:
Splango https://github.com/shimon/Splango -- Not compatible with Django 1.5 (although most compatibility bugs I found were trivial to fix). Largely un-touched since October 2010, except for a fix August 2012 which claims to make sure templates get included in the install. Since templates don't get included in the install when Splango is installed via PyPI, either the fix didn't work or didn't get submitted to PyPI. Documentation is largely accurate, but doesn't completely cover how to set up tests and get reports. It tells you how to configure the template to gather the data, but there appears to be additional steps required in the admin interface which are completely undocumented, and I'm not sure I've done them properly.
Django-lean. Original at https://bitbucket.org/akoha/django-lean has not been updated since July 2010. There is an apparently "blessed" fork at https://github.com/anandhenry2002/django-lean which has not been changed since May 2012, when it was copied over from the original. The original's documentation is incorrect in ways that make following the examples impossible. (Though you can probably muddle your way through, as I did.) The new version's documentation has formatting problems that make it difficult to read on github. (This appears to be because it's the unchanged documentation from the old project, and BitBucket syntax doesn't work on Github.) The django-lean Google Group has not had a message since July 2012.
django-mini-lean https://github.com/DanAncona/django-mini-lean -- Updated as recently as February 2013, but undocumented.
Leaner - https://bitbucket.org/brianjinwright/leaner -- Last updated July 2012, and no docs.
Django-AB -- Last updated May 2009. Is not a package, and can't be installed via PIP or PyPI. After placing the checkout in my django app folder (and renaming the folder to ab) and following the installation instructions, I get an error loading the template loader that I have not tracked down further.
So far Splango appears to be the winner, as I've actually been able to get it more-or-less working (by manually installing the templates, and then editing them to fix Django 1.5 incompatibilities).
Can anyone point me to anything I've missed?
You have missed this app : https://github.com/mixcloud/django-experiments + https://github.com/disqus/gargoyle/
And then there's waffle: http://waffle.readthedocs.org/
It's simple, updated, maintained, but not very feature rich, it doesn't have any analytics/reporting stuff integrated. But then again, google analytics or mixpanel type of service is better for this.
I first looked at Django-AB and that is almost what I wanted, but I couldn't get it to work either. After looking at django-experiments and deciding I didn't want to mess around with redis yet, I decided to roll my own. I've tried to package it up nicely and make it easy to use for the beginner. It's super basic.
https://github.com/crobertsbmw/RobertsAB
You can swap out entirely different page layouts with Google Analytics Experiments (their default experiment setup will redirect users to a different URL for each variation you have), although in general its much easier to interpret why something is more successful if you test smaller things against each other.
You are right that testing different funnels and user flows against each other using Google Analytics would require a lot of manual setup; although theoretically you could do it by swapping out different links and tracking your users with UTM campaigns.
For smaller A/B tests within the same page, I ended up using Google Analytics Experiments and writing a custom Django CMS plugin for adding a few variant options to a template, which queries the Google Analytics API and displays the correct variant using Javascript.
This question already exists, but it is over one year old now and a lot has probably happened if the documentation is a good judge. There is no documented path to migrate from current redmine (2.1) to chiliproject for example.
Chiliproject is a fork of redmine, but I am unable to decide wherever I should migrate or not. There is no clear path as to how I should do the migrations and how much functionality I might loose.
Is there a way to compare the differences between the two projects? Is it worth to spend the time investigating the migration path?
If you have migrated what is your experience?
I searched StackOverflow for the "redmine vs. chiliproject" question because I am having a lot of trouble with installing plugins of any kind on the newest chiliproject version.
Usually, it looks like everything is working fine until you try to update the settings for the plugin (for example, install the Contact Form plugin and try to change something on http://SERVER:3000/settings?tab=contact_form), the debug log shows that the changes were made in the database, but they changes are never loaded back to the plugin page.
I have not been ale to find any documentation on potential changes to the plugin architecture in ChiliProject that would cause this. The plugin page does not list many plugins that are known to work with ChiliProject 3 either.
TL;DR: If you think that you will have any desire to use any existing plugins to extend the functionality of the program you choose, go with Redmine.
I am developing an Django application using the Django 1.3.1 release :
https://code.djangoproject.com/browser/django/tags/releases/1.3.1
I encountered a bug, which has been identified and fixed by the Django team :
https://code.djangoproject.com/ticket/16128
The changeset associated to the bug resolution is located in Django trunk
https://code.djangoproject.com/changeset/17755
My question is : how can I take advantage of the bug resolution, without upgrading to the Django trunk version ?
There a bunch of files attached to the ticket, the latest is :
https://code.djangoproject.com/attachment/ticket/16128/16128.diff
I can see that this file is a standard 'diff' file, which can be processed by the 'patch' utility. I tried to apply it on my django 1.3.1 installation (on a dev machine), but it does not work...The source lines (to be replaced) are not exactly the one expected by the diff file.
To which 'start state' does refer this diff file ? In other words, to which django version can it be applied ?
Is there another way than applying it 'manually' ? Even if I apply it manually, I can see that the patched code call new versions of methods not included in the patch...which means that I have to find out, by reading the code, which other files have to be patched, and patch them...
At this point, I think something like : "waow, it's to complicated, let's wait the next release of Django - 1.5, for this ticket - and find a workaround !". But, in other hand, if the patch system exists, it must be possible to apply this patch to my Django 1.3.1 installation...
Did anyone encountered the same kind of problem ? If so, how did you manage it ?
Thanks in advance for your help
Did you actually try with the Django 1.4 release, which has been issued a few days ago? I am quite sure it is part of it.
Anyways...you can get the official diff at the changeset page that you referenced - at the bottom there is a link to an unified diff. You can download the patch from there and use it to patch(1) your release (beware that should the Django team release a new security release of Django 1.3, you may have to apply it again). However, those diffs are always against the most recent codebase at the time the patch has been committed. For that reason, sometimes you might have a bad luck (like in the case you have described above) and it may not apply cleanly to the previous release. In such case you would have to track down all the changes required to make it work, which may be pretty much work and might be unacceptable. So there are only three options: find your own way to work the bug around, track all the changes required to apply the patch cleanly, or upgrade to the given revision.
I'm updating a 0.5.1 complete_project to 0.7beta3 + virtualenv + pip + fabric.
I have converted my project into multiple stand-alone applications and I have everything being pulled down by pip from a requirements.txt file.
I am now moving the code over and so far can get the Welcome page and perform a log-in, but then it breaks, due, it appears, to the introduction of Group support and the refactoring of Tribes into Tribes and Topics.
Has anyone successfully made this move? If you did, how did you handle migrating your data? What should I be looking out for? Anyone have a checklist or list of steps? What other exciting challenges do I have to look forward to?
The short answer as far as I'm aware (and I've been following Pinax development for some time now) is that there is no straightforward path to upgrade the project from 0.5.1 to 0.7beta3. I'm not sure how familiar you are with the code, but this is the process I would use based on my limited experience:
Start by using the social_project/ that ships with the latest version of Pinax. Copy into it any changes you made to the settings.py file as well as any custom apps you have.
The templates and media have moved to folders outside of the projects, but if you customized any of them (I'm sure you did) take the custom ones and drop them into the template folders in your project to override those in the default theme folders. You should compare them to those in the theme folders to see what changes may need to be made to keep up with changes in the apps.
The next step would be to do the same thing with urls.py copying any customizations over the one provided by the project.
Try getting it running at this point with a fresh DB. Hopefully any errors will point you in the right direction to stuff that you might have missed or not known about.
Once you gotten it running most of the DB tables should be the same (I believe) except as you mentioned the Tribes stuff. Migrating the data, though, is still beyond what I've had to deal with.
Disclaimer: I've been following development but never had to perform an upgrade quite this big. Good luck and (obviously) back up your work and data before trying to port it all over.
See the documentation and code ( http://github.com/pinax/pinax/tree/master ) for more details. The code is a convenient (though tedious) way to watch the evolution between 0.5.1 and 0.7beta3, for what that's worth.
I've been using a pre 1.0 version of django (a dev version somewhere around .97),
And now I'm considering upgrading to 1.x (I grabbed the latest thing from the svn).
There have been some changes to the way the admin interface works, so now I have to edit all my models.py files and create new admin.py files.
I remember seeing a tool that supposedly automated (most of) this process, but that was a long time ago and I don't remember where it was (or maybe my memory is wrong)
Is there such a tool? Where is it?
This might also be helpful:
http://www.djangosnippets.org/snippets/603/
I think what you're looking for is this page: http://docs.djangoproject.com/en/dev/releases/1.0-porting-guide/.
It contains info on the changes, and a link to the script that will auto-generate a 1.0-compatible admin.py file based on your models.