So I started a new django project on a system that has another project. I use subdomains and mod_wsgi to handle the direction to the various projects. The direction seems to be working just fine.
For some reason, though, this second project is insist my urls.py and settings.py files should be located at settings/urls.py and settings/settings.py. Any ideas? It completely ignores the perfectly valid urls.py file that's sitting there (with a couple of filters as test urls). It also ignores any urls.py files I actually put at settings/urls.py (as a test). I made ROOT_URLCONF='urls' as opposed to ROOT_URLCONF='projectname.urls' as django never seems to like the former.
Anyway, I'm completely stumped, and after a couple of hours searching through everything, I can't for the life of me figure out where I should even look. Any ideas?
First, I think your problem might actually be that you have ROOT_URLCONF set to urls instead of <proj_name>.urls so it is searching for settings.urls.py because your ROOT_URLCONF tells it to go to urls.py which would be settings.urls.py while in the settings module.
Second, in your wsgi file, do you have the following line:
s.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
Related
This is a kind of want-to-know itch. Many questions here ask how to replace the default Django homepage (e.g. ). I understand that issue. What I'm curious to know is how the default page is rendered when a new project is created (i.e., in debug mode). Even though my question is not as directly practical as knowing how to replace the default homepage, I have the feeling that if I figure it out, I may understand how Django works a bit better.
I would expect it to be in the default urls.py file, but the only entry by default in urlpatterns of urls.py is path('admin/', admin.site.urls). My first naive expectation would be an entry in urlpatterns that you could remove or comment out. Since there's nothing there besides admin/, I'm guessing there's some other built-in app or middleware that specifies the default homepage, but I don't know where to look.
Here's my progress in understanding this so far:
Commenting out DEBUG=True in settings.py causes the default homepage to no longer appear.
I've seen this documentation about how Django processes requests, which mentions middleware that can set the urlconf attribute on a request that changes the default, ROOT_URLCONF.
So far Django has been pretty straightforward, but this seems like something magical, so I'm trying to figure out what's going on behind the scenes.
I appreciate the help!
The relevant code is here. Django basically has a special case for when no matching URL is found in the URL configuration, and the requested path is /, and there is only one entry in the URL configuration.
In that case it loads a default_urlconf which renders that welcome template in place of a regular 404 response.
This is called from inside the technical_404_response function, which is only called when DEBUG=True.
I want to start a new django project. This will just be a relatively simple website to test django itself. So the way all tutorials structure their project is this:
mysite
mysite
some_app
...
For me it's not very clear what does what. I don't really need any app right now. Could I implement my website without using any app? Should I use an app? What would it be called for a simple website?
Have you read Django doc already?
They have a nice tutorial on how to get started.
As for apps, in Django, you have a project containing one or more app. If you just want to try to build a simple website, your project called mysite will contain only one app.
I think you don't need more than the main mysite, BUT, at the django documents, have a session that says:
If your background is in plain old PHP (with no use of modern
frameworks), you’re probably used to putting code under the Web
server’s document root (in a place such as /var/www). With Django, you
don’t do that. It’s not a good idea to put any of this Python code
within your Web server’s document root, because it risks the
possibility that people may be able to view your code over the Web.
That’s not good for security.
Put your code in some directory outside of the document root, such as
/home/mycode.
This model may have been designed with focus on safety.
Some files in mysite could be used to control things in another apps, so i think that is a 'best pratice' to follow this model.
Font
if u aren't in need of an app you can avoid creating one. just give your view in views.py of your project set the url and u r all set to go.
here the first mysite folder is just an usual folder u can change the name in ur convenience next mysite is your project folder and recommended not to change it and next some_app is the application name(you can name your app anything relevant but in proper convention.)
and follow django documentation and djangogirls tutorial for better understanding.
https://docs.djangoproject.com/en/2.0/
https://tutorial.djangogirls.org/en/
When running manage.py collectstatic in Django, I see messages like:
Found another file with the destination path 'admin/js/jquery.init.js'. It will be ignored since only the first encountered file is collected. If this is not what you want, make sure every static file has a unique path.
I tried running find . -type l to search for symbolic links in my Django project, but it didn't turn up anything.
How can I figure out where the other file with the same destination path is?
Like templates, static files are searched for in two locations:
under the directories listed in STATIC_DIRS
in static directories in the apps themselves.
In this case, it looks like this file is provided both by django/contrib/admin/static, and /static/.
Django respects the order of your apps in settings.py INSTALLED_APPS when running collectstatic.
If you have two installed apps that write the same static files (e.g. django.contrib.admin and grappelli) then Django collectstatic will write the static files for the app appearing first in the list. When it hits the second app it will ignore its static files and output the warning you are seeing.
So you need to find out which two INSTALLED_APPS are trying to write the same static files, and decide which one you want to use the static files of. If you make sure that app appears first in your INSTALLED_APPS list then you can safely ignore the warnings generated from the second app.
check this: https://github.com/django-compressor/django-compressor/issues/720
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
#'django.contrib.staticfiles.finders.AppDirectoriesFinder', #causes verbose duplicate notifications in django 1.9
)
Using the development server, it works with debug=True or False.
In production, everything works if debug=True, but if debug=False, I get a 500 error and the apache logs end with an import error: "ImportError: cannot import name Project".
Nothing in the import does anything conditional on debug - the only code that does is whether the development server should serve static files or not (in production, apache should handle this - and this is tested separately and works fine).
Just to say, I ran into a similar error today and it's because Django 1.5 requires the ALLOWED_HOSTS parameter in the settings.
You simply need to place this row to make it work ;)
...
ALLOWED_HOSTS = '*'
...
However, be aware that you need to set this parameter properly according to your actual host(s) (https://docs.djangoproject.com/en/dev/ref/settings/#allowed-hosts)!
Values in this list can be fully qualified names (e.g. 'www.example.com'), in which case they will be matched against the request’s Host header exactly (case-insensitive, not including port). A value beginning with a period can be used as a subdomain wildcard: '.example.com' will match example.com, www.example.com, and any other subdomain of example.com. A value of '*' will match anything; in this case you are responsible to provide your own validation of the Host header (perhaps in a middleware; if so this middleware must be listed first in MIDDLEWARE_CLASSES).
So basically it's better for you to use this type of configuration once you're in production:
...
ALLOWED_HOSTS = [
'.yourdomain.com',
]
...
thanks to gertvdijk for pointing this out
This happens if you have a circular import in one of your files. Check and see if you are importing something from Project and then importing something in Project from the original file that originally imported Project.
I ran into this same problem recently, and rearranging some of my imports helped fix the problem.
This can also happen if you do not have both a 500.html and 404.html template present. Just the 500 isn't good enough, even for URIs that won't produce a 404!
I had this problem as well. Although it persisted even when setting Allowed_hosts and already having 404 and 500 templates.
I also checked for circular imports, but that was not it.
I finally had django produce a log file, https://stackoverflow.com/a/15100463/1577916
I accidentally left in a "get_host" function which now exists under
HttpRequest (changed to HttpRequest.get_host())with Django 1.5.
for some reason that was not raising an error with Debug True OR False.
Background:
I'm starting to use Django for the first time, which is also my first foray into web development. I just got stuck on the whole "serving static media" problem. After spending a while looking at all the documentation and StackOverflow questions, I think I understand how it's supposed to work (i.e. MEDIA_ROOT, MEDIA_URL, updating the urls file, etc).
My Question:
Ok, so here's the part I'm not sure about. Django applications are supposed to be "pluggable", i.e. I can move an application from one project to another. So, how should these applications bundle static media?
For example, let's say I have a "foo" application, which has templates that load some css/image files. Where am I supposed to put these files, so that they'll automatically get served once I include the application?
The only solution I see, is that installing an application has to include the extra step of copying its static media to some place on your own server that serves that media.
Is this the accepted way to do it? It includes an extra step, but maybe that's standard when dealing with web-dev (I'm new so I don't really know).
Also, if this is the way, is there a standard way to collect all my static media to make it easy to know what I need to serve? (I.e., is it standard to have a folder named "media" or something inside the app?).
Thanks,
Convention is to put static media in either media/appname/ or static/appname/ within the app (similar to templates).
For using apps in your project that come with media, I strongly recommend using django-staticfiles. It will automatically serve media (including media within apps) in development through a view that replaces django.views.static.serve, and it comes with a build_static management command that will copy media from all apps into a single directory for serving in production.
Update: django-staticfiles has become part of Django 1.3. It now expects app media to live in a "static/" subdirectory of the app, not "media/". And the management command is now "collectstatic."
The only app I know of that deals with this without any intervention is the rather wonderful django-debug-toolbar, though it's arguable that this isn't a great example, since it's an app specifically designed for debug mode only.
The way it deals with it is that it serves its media through Django itself - see the source for urls.py:
url(r'^%s/m/(.*)$' % _PREFIX, 'debug_toolbar.views.debug_media'),
In general, this is a bad idea (you don't want to serve static files through Django), per this comment from the documentation:
[Serving static files through Django] is inefficient and
insecure. Do not use this in a
production setting. Use this only for
development.
Obviously, the django-debug-toolbar is only used for development, so I think its method of deployment makes sense, but this is very much an exception.
In general, the best way I know to do it is to create symbolic links wherever your media is stored to the media inside your app code. For example, create a folder called media within your app, and then require users installing your app to either add a symbolic link from their media directory, or copy the whole thing.
i usually put apps media in ./apps/appname/static (my apps resides in an apps subfolder)
then i have something similar in the vhost in apache :
AliasMatch ^/apps/([^/]+)/static/(.*) /home/django/projectname/apps/$1/static/$2
<DirectoryMatch "^/home/django/projectname/apps/([^/]+)/static/*">
Order deny,allow
Options -Indexes
deny from all
Options +FollowSymLinks
<FilesMatch "\.(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|txt|htm|html|json)$">
allow from all
</FilesMatch>
</DirectoryMatch>
i also have this in my urls.py for dev server (use only for debug) :
def statics_wrapper(request, **dict):
from django.views import static
return static.serve(request, dict['path'], document_root = os.path.join(settings.BASE_DIR, 'apps', dict['app'], 'static'), show_indexes=True)
urlpatterns += patterns('', (r'^apps/(?P<app>[^/]+)/static/(?P<path>.+)$', statics_wrapper))
this is very handy because statics url are simply mapped to filesystem, eg :
http://wwww.ecample.com/apps/calendar/static/js/calendar.js resides in [BASE_DIR]/apps/calendar/static/js/calendar.js
hope this helps