Daniel is correct. One more point though, there are cases where you may
want to use the full url instead of just "/django_project/", in which case,
you should use settings.BASE_URL or {{ request.get_host }}.
To use either of those in the template, the template would need to be
rendered with a R
Hmm, yeah, Ryan could be onto something, but that doesn't really help
figure out the root cause (which likely was an error that existing before
upgrading but just went ignored).
What should help get to the root issue is checking out the postgresql log
file (for me: /var/log/postgresql/postgresq
If you are mainly using this for splitting stuff into multiple files, here
is what we do to accomplish the same thing but keep it so that templates
always inherit base.html instead of sidebar.html:
base.html:
{% extends 'header.html' %}
{% block main %}
{% endblock main %}
header.html:
{%
My guess is that unique=True was added after the table was created using
syncdb.
I'm guessing that most companies that use Django professionally use South (
http://south.aeracode.org/) to make schema changes easier.
Without South, you would have to keep the database in sync with the code
manual
Hello,
What version of allauth are you trying to install and where did you get it
from?
https://github.com/pennersr/django-allauth/tree/0.10.0/allauth/socialaccount/migrations
is
the most recent version on pypi and has more than 2 migrations.
Could it be that you have another app installed th
Oh and I just noticed you added "Also, some images could be blank/None"
Instead of 'if obj.id:' you can simply do 'if obj.id and obj.photo:'
On Monday, April 15, 2013 10:52:11 AM UTC-7, Sam Solomon wrote:
>
> One small correction, in 'list_display'
One small correction, in 'list_display' it should be 'admin_photo' (or I'd
probably put 'display_photo' (see #1 below)), not 'photo'.
Some other tricks:
1) If you don't want to clog up your Model class, you can put the function
in your ModelAdmin class.
2) If you add "readonly_fields = ('displa
Yes, it's okay to just try stuff out locally, but one word of caution,
after everything is working and before you deploy the code, it's probably a
good idea to review any "lets see how this looks/works" code/decisions to
make sure it still makes sense.
Once a URL is in the wild, it's annoying t
Depending on if the expiration is a temporary thing or if you actually want
to permanently deactivate the user, this may be even simpler and database
efficient (and is what we use to ban users):
class DeactivateUserMiddleware(object):
def process_request(self, request):
if request.us
Not sure exactly what the issue is, but this may be handy (either as a
replacement or as an example of doing something somewhat similar):
https://github.com/disqus/django-bitfield
I believe on most machines the maximum is 63 "flags" though so you will
likely only be able to use it as an example
Here is something that may help:
import importlib
from django.conf import settings
for app in settings.INSTALLED_APPS:
views_name = "%s.views" % app
try:
importlib.import_module(views_name)
except ImportError:
pass
except:
print "Could not import %s" % vie
Tom Evans has probably the correct answer for you, but another thing that
I've done (maybe not 100% applicable in this case) is to have a default
base and then make it extendable from views when necessary:
{% extends base_template|default:"base.html" %}
This sounds like it isn't applicable in y
Not sure if this is what you meant by "we'll probably keep the javascript
reloading to process junks, waiting for the support of celery", but one
option without celery is to have the initial request save a bunch of
"PendingEmail" objects in the database and then redirect you to a
"send_queued_e
2073>),
> so you never know.
>
> Thanks again. I appreciate your time.
> - Rob
>
> On Feb 7, 2013, at 1:15 PM, Sam Solomon wrote:
>
> Regarding having WSGIDaemonProcess outside of vhosts, as explained in the
> comment I added, it allows you to use the same process to handl
Regarding having WSGIDaemonProcess outside of vhosts, as explained in the
comment I added, it allows you to use the same process to handle requests
from multiple vhosts.
As for the rest, I honestly don't remember why or where they came from, I
just know that this is probably not all that common (m
Can't spot any issues but here is what we have to run multiple staging
versions of our site:
group_* names are more descriptive in the actual settings
WSGIDaemonProcess group_1 processes=1 threads=100 display-name=%{GROUP}
inactivity-timeout=30 #defining it out here allows you to use the same
The word "Insane" caught my eye and lo and behold it was relevant to what
we've done. We actually do this for security reasons and it does help with
debugging sometimes (we actually log all queries, not just
INSERT/UPDATE/DELETE).
We also store fk to user (with a pre_delete hook to unattach use
I agree, the simple approach may be good for some things, but we have a
highly complex tightly coupled main app that for us, we believe it's
easiest to keep bundled together. If we add/write new, more generic apps to
our site, we would obviously consider adding it as an app in the "project/"
folder
We've not had any trouble and we have a very nested structure:
project/main_app/sub_apps/
project has manage.py, main_app has main urls.py, etc.
sub_apps have models/views/urls, etc.
We also have:
project/main_app/utils/other_apps/ with no issues (and utils and other_apps
both have models, ev
I'm guessing that the problem is there are many ways to deploy Django so
it's hard for anyone to give a good one-size-fits-all answer and also hard
to run down the complete list of possibilities, and I'm guessing that since
this list is only viewed by a small percentage of Django users, that the
I'm guessing that for some reason the classes in your app/models.py are not
set up correctly, are you sure you inherit from models.Model in your
class(es).
Example:
from django.db import models
class MyModel(models.Model):
rather instead of :
class MyModel():
If it doesn't inherit models.Mod
21 matches
Mail list logo
