Why does django.contrib.comments load only default template - django

This is quite strange. As far as I knew, django always searches in local dir and then goes into Python installed lib dir. But this is not the case with django.contrib.comments.
I am trying to load list.html from local template director of the comments app. Its located exactly at templates/comments/list.html on local app dir.
The strange part is, it doesn't get loaded. It only loads the default one found in django.contrib.comments dir..
Why is it happening.
My app is correctly configured
Since something is going wrong I thought to check whether template dir is in path or not. So, I quickly loaded
{% include "comments/list.html" %} and it showed default file (not the custom one it supposed to show)
but I just changed list.html to list1.html and it was showing.
I changed the file name from list.html to list1.html and its working.

Make sure that your comments app appears above django.contrib.comments in your INSTALLED_APPS setting.
When you you using the app directories template loader, Django goes through your apps in the order they appear in you INSTALLED_APPS setting.

Related

Templates are not found in django deployed project

I have got a Django Project. It runs perfectly using "python2 manage.py runserver". I have deployed the project in a server and I get "Template not found" error. I have changed the path in views file for the main page and now it works, but I have got two new issues:
I have got an {% include "/lateral/menu.html" %} line that does not work in main.html
All the href in buttons that redirect the user to other html files do not work either.
I think it has something to do with the paths, how should I added them in order to be relative path?
My structure:
-APP1
-APP2
-WEB
---manage.py
---TEMPLATES
------main.html
------logout.html
------loging.html
------LATERAL
---------menu.html
Some lines of my views file in order to check how I add the paths:
def loging(request): # FunciĆ³n vista
return render(request, "loging.html")
I have tried changing to some variations of the paths and with absolute paths too without success. All was working perfectly locally.

Mezzanine theme customization: the new base.html does not replace the original

I am trying to customize the theme of Mezzanine. Basically, I am following the tutorials of this and this.
I created a new app theme, copied base.html to the theme/templates folder, and insert the theme in the INSTALLED_APPS in settings.py (note, it is in the first line):
INSTALLED_APPS = (
"theme",
"django.contrib.admin",
"django.contrib.auth",
...
I suppose that Mezzanine will find theme's base.html first and use it in stead of the original. But it seems not the case; the original Mezzanine's base.html is still used.
Did I missed anything? Is there a way that I can trace how Mezzanine (or Django) searches for the templates in order to find out what went wrong in the process?
Use this tutorial, instead of "theme" in installed app you should have copied the template in your project directory and write it's name there. For instance
if you downloaded moderna theme add "moderna" under
INSTALLED_APPS = (
"moderna", ...
The link below explains all the steps clearly.
How To Deploy: Installing Mezzanine Theme

Django suit unable to detect template override

I am overriding a template file in django-suit. Unfortunately this file is not detected and overridden.
According to their documentation:
Alternatively you can copy base_site.html to any of template
directories, which are defined in TEMPLATE_DIRS setting (if any). By
default Django looks in every registered application templates/ dir.
I have copied the file base_site.html into an existing app/templates/admin directory but this is not detected. I am already consuming template files from this directory so it should work.
What may be wrong in my situation?
Make sure your app is above suit in INSTALLED_APPS in settings file.
This is really important step to learn how template loaders work. It checks the folders in order of app in INSTALLED_APPS setting if it finds the template in first folder it uses that template. That's why also suit has to be above admin app because it overrides admin templates.

How do I find my project name in a Django project?

I have a pycharm project and, presumably, a Django project. Perhaps they are one and the same, perhaps not - I'm unsure as to the distinction.
Anyway, in my settings.py file (which is in the root of project directory, which is what I presume is my pycharm project) I have:
ROOT_URLCONF = 'dumpstown.urls'
Does that mean dumpstown is my project name? Or my pycharm project name? What is the distinction? Because I also have a folder called dumpstownapp and this has all my models.py and view.py files. I would have thought that dumpstownapp was the Django project, but I really don't know!
So, to be concise:
In this folder setup
folderA
folderB
views.py
models.py
<other stuff>
templates folder
settings.py
<other stuff>
which is the "Django project name" ~ and by that I mean, if I have a UserProfile defined in my models.py (shown above) what would be the AUTH_PROFILE_MODULE entry I'd need for it? I'm getting several understandings from the django docs - I'd assume
dumpstownapp.models.UserProfile
But from the docs I'd get
dumpstownapp.UserProfile
Or maybe my app is called dumpstown? and then what do I get?
FolderA is the Django project folder, and folderB is the Django app folder.
I haven't used a UserProfile, but according to the docs ( https://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users) it should contain a string containing the Django app name and the model name separated by a dot, so "dumpstownapp.UserProfile" should be correct. If you show the error someone can probably give you better help..
Django documentation used to say that the parent of the project folder (i.e. the parent of folderA) should be on the path, but I believe that has been changed to also include the project folder itself (i.e. folderA) -- since it makes sharing of Django apps much easier. PyCharm seems to assume that is the case, since pressing Alt+F7 to auto-add an import for a newly used module create an import statement that assumes folderA is on the import path (I'm a relative newcomer to PyCharm, and I'm using it on a project that started in the Django 0.96 era, so I might just have things set up wrong..) But folderA is both the Django and the PyCharm project (the .idea file is where PyCharm stores its project data).
In one of my django-app git-submodule projects I needed to find out the name of the Django project that django-app/library was used in. To that end, I tried to get the path of the file that was being executed, find my package in the path and take the folder above it. However, it turned out that on the production server the project was deployed in a folder with a different name (a standard name like www or something along those lines). So this way is not fully reliable.
So I ended up setting a PROJECT variable in the django settings file and using that instead.

need help solving sorl-thumbnail error: "'thumbnail' is not a valid tag library:"

I've been pulling my hair out trying to solve this problem and I've tried everything and I have no ideas left.
I keep seeing this error:
Exception Value: 'thumbnail' is not a valid tag library: Could not load template library from django.templatetags.thumbnail, No module named sorl.thumbnail.main
$DJANGO_PACKAGES/sorl/thumbnail/main.py DOES exist.
Here's what I did to setup,
downloaded latest sorl-thumbnail and added its location to the python path in .bash_profile
included 'sorl.thumbnail' in INSTALLED_APPS (in django's settings.py)
used the {% load thumbnail %} tag in a django template
It would seem obvious sorl-thumbnail is not installed correctly, but I'm able to import thumbnail from the python shell and the django shell (when I use {% load thumbnail %} it brings this error). Also, there are no typos in related files (I've checked many many times).
I would venture to guess this is a $PYTHONPATH issue. Is it possible that the "thumbnail" directory is on the path and not "sorl"? I suspect this is the issue because you do not want to be able to type "import thumbnail" on the Python interpreter. You should instead have to type "import sorl.thumbnail".
Another thing to check is to print the module name after importing:
>>> import thumbnail
>>> print thumbnail
This will display the filesystem location where the module was found, in case it's loading another copy from somewhere you do not expect.
You also want to make sure your current working directory is not the root ../sorl/ location (ie. don't run python from the sorl folder). This will allow you to import thumbnail straight-away.
You should check your full Python path (it will be more than $PYTHONPATH) from within the python interpreter to verify your package locations:
>>> import sys
>>> print sys.path
It might also be helpful to learn more about Python importing
Problem solved.
When following the django book, it is suggested to create apps within a project directory and to refer to these apps in the INSTALLED APPS statement with a path that begins from the directory containing the project, for example, 'siteproject.books'. I was not able to give django access to apps without appending that directory name to the file path, so, for example, I was not able to simply use 'books', but needed to use 'siteproject.books' in the INSTALLED APPS statement and this was the case with sorl.thumbnail, which needed to be referred to as siteproject.sorl.thumbnail. Other attempts to include 'sorl.thumbnail' would yield a very ugly un-formatted and confusing purple-colored error page (yes, the sorl directory was in $PYTHONPATH, so who knows why these attempts didn't work...).
Unfortunately, Django was yielding the 'undefined tag' error, which is a generalized error that it gives in many situations. It doesn't really mean anything and isn't useful for locating problems.
The problem was solved when I opened the files in the sorl directory and edited the python files. I found import statements that imported objects from the sorl directory and I appended the 'siteproject.*' to those paths and everything began to work.
Here's another general tip on the unhelpful 'not a valid tag library' message: for tags that you create, it could be as simple as a syntax error.
Hat tip: 'Rock' on Django-users: http://groups.google.com/group/django-users/browse_thread/thread/d65db3940acf16c3?tvc=2