Develop Reference

What template is loaded by Django?

I was following Django tutorial, and got stuck where it asked me to replace the default template for administrative part of the site with my own. The problem was a typo in the template's name. I suspected there must be a problem like that, but to troubleshoot the problem it'd be very helpful to see some kind of report from Django on what template it used to render a particular page. Is there any way to do this?

First if you have set DEBUG = True django automatically gives you information about where django was looking for templates (in general and especially in case it didn't find one)
You should see something like this:
second you can add the popular django plugin django-debug-toolbar. It can show you for each request what templates were used and what their context was.
see: https://django-debug-toolbar.readthedocs.io/en/stable/panels.html#template

Still, not exactly the answer, but something to get me closer. One could start Django shell, and then try this:
>>> from django.template.loader import get_template
>>> get_template('template/name').origin.name
to find out what template was actually used. This is still not enough to see though which templates were considered while resolving the template.

Django 1.6 admin panel customization

Now I'm developing a feedback application,
So, the admin must see messages from users, filter them(read/unread) and mark them as important.
I have already done all the functionality I need, but i cannot customize my headers.
For example.
There is a default header in change list(see the screenshot, this header is selected),
How can I delete these headers or customize them?
Great thanks in advance.

Actually, the answer from #mayankTUM is not correct. It does not follow the django design philosophies and should not be implemented (#mayankTUM himself mentions one of the problems of his solution however there are many, many more)!
Basically, what you need to do can be done by overriding the admin templates. Because there are some problems with that (I will explain later), here's exactly what
I did to solve your requirement:
Created a directory named admin in my templates folder.
Copied there the change_list.html template from <django>\contrib\admin\templates\admin\change_list.html.
Added the following to the end of the new change_list.html: {% block content_title %}Hello world!{% endblock %}
Now, instead of "Select ... to change" it will print "Hello world!"
I have to notice that copying the whole change_list.html is not DRY - it'd be much better if I just created the file, made it extend from admin/change_list.html and add the content_title. However this is not working and will lead to infinite recursion (please check this bug report https://code.djangoproject.com/ticket/15053 ) -- this is the problem to which I was referring before. A better solution that copying over the whole template is discussed in the following questions:
Django: Overriding AND extending an app template
and
How to override and extend basic Django admin templates? and
django override admin template
PS: My TEMPLATE_DIRS and TEMPLATE_LOADERS project settings are these:
TEMPLATE_DIRS = (
PROJECT_PATH.child('templates'),
)
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
)

Why don't I have any comments in my py-files? (Django)

I'm following this tutorial about creating a simple blog with Django. I see that this guy has a lot of comments in his py-files with explanations and such. My py-files don't look at all the same. For example, in settings.py I don't have any varibale called TEMPLATE_DIRS, but in this guys file it looks like this:
TEMPLATE_DIRS = (
"",
# Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.
)
Since I'm a newbie I would of course appreciate the help that these comments and pre-defined variables provide. Why don't I have them? Have Django removed them in a later version?
Thanks in advance!

Perhaps the answer is here
Its because of your django version that you are using. in this tutorial they used django 1.3. its
existing in the django 1.3. But Its misssing in djang 1.4 and later versions.
So add the below code in your settings.py
from os.path import join
TEMPLATE_DIRS = (
join(BASE_DIR, 'templates'),
)

It may be that the author of the tutorial wrote his own comments so that readers would better understand each of the settings. It may also be that in a newer version of Django the core developers thought it would be simpler to leave them out of the default settings file created.
It doesn't matter much because each setting such as TEMPLATE_DIRS has a default value. So you can check django documentation for their meaning.

Is it proper to reference your project name inside your Django project?

I'm using Django and I'm wondering whether it's proper to use myapp.models, opposed to myproject.myapp.models, or in INSTALLED_APPS, should the FULL NAME be used myproject.myapp or is it alright to just use myapp for it's name? I am wondering because if I were to change the project name using the latter method it would break my app, but I'm not sure that just because the former method works that it is correct. Could someone clear this up for me.
Thank you!

I would say that it is not encouraged to reference your apps using your project name. I say this because as of Django 1.4 this will not work with a default Django project. You can read more about this here:
https://docs.djangoproject.com/en/dev/releases/1.4/#updated-default-project-layout-and-manage-py
A quote from that:
"If settings, URLconfs and apps within the project are imported or referenced using the project name prefix (e.g. myproject.settings, ROOT_URLCONF = "myproject.urls", etc), the new manage.py will need to be moved one directory up, so it is outside the project package rather than adjacent to settings.py and urls.py."
I would recommend against it since it would mean messing with the default project structure, not a huge deal, but increased unnecessary work.
I would also recommend against it since it couples your apps to your project, which imho goes against the philosophy of Django which advocates reusable, decoupled apps.

Django URL resolving infrastructure stops working

We recently launched a new Django-powered website, and we are experiencing the oddest bug:
The site is running under Apache with mod_fastcgi. Everything works fine for a while, and then the URL tag and reverse() functionality stops working. Instead of returning the expected URL, they return "".
We haven't noticed anything in Apache's log file; there are no errors being generated by Django. And (the kicker) the problem only occurs in production mode; we can't reproduce it when DEBUG=True.
Any thoughts on where we should be looking for the problem?
Update: It turned out to be a problem with settings.LANGUAGES, although we haven't determined exactly why that broke things.

This has happened to me before. Normally it's due to a 'broken' urls.py file. There are two things that make this kind of bug really hard to fix:
It could be the urls.py file in any of the apps that breaks the reverse() function, so knowing that reverse() breaks for app X doesn't mean the error is in that particular application's urls.py.
Django won't even notify you of errors in the urls.py file, unless you somehow manage to crash the site by doing something really, really nasty in the urls.py file.
Debugging: The way I go around fixing this is by manually disabling all applications (just comment out their line in INSTALLED_APPS) and checking reverse() works. If it still works, then I enable the next app, until it breaks. I know, very rudimentary stuff, but it works :)

Django has a odd behaviour when matching urls in a environment that isn't under debug mode.
For example, with DEBUG=False, Django will ignore urls such as:
url(r'^', include('someapp.urls')),
specifically in the case above, you could let the string empty:
url(r'', include('someapp.urls')),
In other words, check your regexes.
Can you put your urls.py here to be analyzed?