Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
How to fix Django’s HTTPS redirects in nginx
You deploy with nginx and Gunicorn and your site uses HTTPS. If Django occasionally returns HttpResponseRedirect or similar, you may find that the redirect sends you back to HTTP. Here’s how to fix it. In the nginx configuration (inside the location block), specify this: proxy_redirect off; proxy_set_header X-Forwarded-Proto $scheme; The proxy_redirect off statement tells nginx that, if the backend returns an HTTP redirect, it should leave it as is. By default, nginx assumes the backend is stupid and tries to fix the response; if, for example, the backend returns an HTTP redirect that says “redirect to http://localhost:8000/somewhere”, nginx replaces it with something similar to “http://yourowndomain.com/somewhere”. But Django isn’t stupid (or it can be configured to not be stupid), and it will typically return a relative URL. If nginx attempts to “fix” the relative URL, it will likely break things. Instead, we use proxy_redirect off so that nginx merely passes the redirection as is. The second line is only necessary if your Django project ever uses request.is_secure() or similar. It’s a good idea to have it because even if it doesn’t today it will tomorrow, and it does no harm. Django does not know whether the request has been made through … -
Install Django on Mac
#### Install Django & Virtuale... -
Install Python & Django on Windows
### Install Python & Django on... -
Common Regular Expressions for Django URLs
Common Regular Expressions for... -
Python Cheat Sheet
A quick reference guide for us... -
My Equipment
### Computer Laptop: [http:... -
AngularJS vs jQuery
### AngularJS is a framework ... -
Django App Structure
To make your individual Django... -
Syncdb is ... gone?
Yup `python manage.py syncdb` ... -
A Fantastic Ted Talk
This is by far one of the most... -
Everything coming in 2017
Topics -
*args and **kwargs
So when you write any given fu... -
Testing Email in Django with send_mail
Sometimes you need to test tha... -
Which Version to Use?
When you watch or read tutoria... -
New URL Structure for Django
Django 1.10 has changed the re... -
post_save vs pre_save vs override save method
Which is better ... `post_save... -
TemplateDoesNotExist error
I see this error come up a lot... -
Hats off to you...
CFE Community! Hats off to ... -
Transcoding with AWS- part five
This is the last blog post in this series - the only thing that has to be done is telling the user that file he or she uploads is processed. It will be done by writing custom message application. Tabel of Contents: How message application should work Implementation in django Other blog posts in this series How message application should work From previous post I know that the last point of my application flow is to inform user that file is transcoded and ready to download. To do such thing I have to display message on every webpage that current user is. This message should have information about which file was processed. First I wanted to do this with existing django messaging framework but as it turns out is works only with request. As I decided to show message for different users as long as they dismiss this information I had to write my own small application. Implementation in django In my newly created application I created following model: from django.db import models from django.contrib.auth.models import User class Message(models.Model): text = models.CharField(max_length=250) read = models.BooleanField(default=False) def __str__(self): return self.text I decided to display my message only when it wasn't read. … -
Transcoding with AWS- part five
This is the last blog post in this series - the only thing that has to be done is telling the user that file he or she uploads is processed. It will be done by writing custom message application. Tabel of Contents: How message application should work Implementation in django Other … -
Integrate Django-Oscar-Accounts with Django-Oscar
Django Oscar Accounts is a package that provides the ability to manage accounts with fully managed account functionality to use with Django Oscar. * Django Oscar Accounts provides managed accounts using double-entry bookkeeping. * In this package every transaction is recorded twice(once for the source account and once for the destination account) by using double-entry bookkeeping. This make sure that books always balance and there exist full record of all transactions. Features - A user can have multiple accounts An account can be created with - no users assigned, a single primary user assigned or set of users can be assigned An account consists of start date and end date to restrict its usage in a limited time, also it can be restricted so that it can only be used to pay for a range of products. An account has a credit limit, by default it will be zero. Installation - * Install using pip: pip install django-oscar-accounts * Next, add "oscar_accounts" to INSTALLED_APPS in settings file. * After this apply migrations with "manage.py migrate oscar_accounts" command. This will create the appropriate database tables. * Next use "manage.py oscar_accounts_init" command to create core accounts and account-types. The names of these … -
Ship It Day Q1 2017
Last Friday, Caktus set aside client projects for our regular quarterly ShipIt Day. From gerrymandered districts to RPython and meetup planning, the team started off 2017 with another great ShipIt. -
How I Deploy Django Day-to-Day
There are a lot of ways to deploy Django so I think it is one of those topics people are really curious about how other people do it. Generally, in all deploys you need to get the latest code, run migrations, collect your static files and restart web server processes. How yo do those steps, that is the interesting part. In todays video I go over How I deploy Django day to day, followed by some other ways I have done it. This is definitely a topic you can make as easy or complicated as you want. Here is the link again: https://www.youtube.com/watch?v=43lIXCPMw_8?vq=hd720 -
Why does Django not email me the 500 internal server error?
You’ve set your EMAIL_* settings correctly, and when you try to send emails with django.core.mail.sendmail() it works. However, Django still does not send you internal server errors. Why? The sender’s email address matters SERVER_EMAIL is the email address from which emails with error messages appear to come from. It is set in the “From:” field of the email. The default is “root@localhost”, and while “root” is OK, “localhost” is not, and some mail servers may refuse the email. The domain name where your Django application runs is usually OK, but if this doesn’t work you can use any other valid domain. The domain of your email address should work properly. → Set SERVER_EMAIL → When testing with django.core.mail.sendmail(), use the same sender email address as the one you’ve specified in SERVER_EMAIL. The recipient’s email address matters Because of spam, mail servers are often very picky about which emails they will accept. It’s possible that even if your smarthost accepts the email, the next mail server may refuse it. For example, I made some experiments using EMAIL_HOST = 'mail.runbox.com' and this command: send_mail('Hello', 'hello, world', 'noreply@example.com', ['anthony@itia.ntua.gr']) In that case, Runbox accepted the email and subsequently attempted to deliver it to … -
New Django Admin with DRF and EmberJS... What are the news?
A couple months ago, I published a post titled "Yes I want a new admin". Now that more than a few weeks have gone by, I want to bring you up to speed on the progress. In the original post, it was mentioned that, in order to achieve this goal, several libraries would be needed and that some of these libraries were already published. Among them were DRF-auto-endpoint and djember-model. During Django Under The Hood's sprints, we got together with several people interested by the concepts of those two libraries, merged them in a signle library (DRF-schema-adapter) and added some functionalities. Other than being a merge of the two "old" libraries DRF-schema-adapter also brings the concept of adapters which make it possible to use the same library for different frontends. DRF-schema-adapter pursues 3 main goals: Making it as easy, fast and straight-forward to define an API endpoint as it would be to generate a ModelAdmin class. Letting developpers be DRYer by generating frontend code (models, resources, stores, ...) based on your DRF endpoints. Providing enough information to the client to be entirely dynamic. Although there are still some improvements planned for the library, all 3 of these goals have been …
