Django 3.0.6
For one model I need a modified admin site template.
Namely, I want to modify this template:
admin/includes/fieldset.html
I have copied the fieldset.html from Django package directory and placed it like this:
/my_project/image/templates/admin/includes/fieldset.html
Here image is my application. It is this application that needs a modified admin template.
The problem is that all other models also get this template. And the used template filters don't receive necessary params and explode.
Documentation: https://docs.djangoproject.com/en/3.0/ref/contrib/admin/#set-up-your-projects-admin-template-directories
Well, I got confused and fail to organize the necessary directories structure.
How can I use the modified template only for one Image app?
You have a couple of issues. Firstly, only the following templates can be overridden per-app or per-model:
actions.html
app_index.html
change_form.html
change_form_object_tools.html
change_list.html
change_list_object_tools.html
change_list_results.html
date_hierarchy.html
delete_confirmation.html
object_history.html
pagination.html
popup_response.html
prepopulated_fields_js.html
search_form.html
submit_line.html
fieldset.html isn't in there, so you'll need to see if the including template(s) is in this list, and if it is, replace this template and use it to include your own version of fieldset.html.
Also, your location (slightly modified since can't override included templates per-app): /my_project/image/templates/admin/template.html isn't quite right. This will overwrite that template for every app. To do it per-app, you need a further subdirectory under admin:
/my_project/image/templates/admin/image/template.html
The reason for this is that templates don't really care about which app they're in, so the fact that the template lives in your image app doesn't mean anything to Django, the convention of putting them in your app's sub-directory is solely to avoid overriding templates that you don't intend to.
I want to implement the feature for admins to set custom templates. Like they can place themes or templates in a particular folder relative to the home folder.
Each theme may have a folder and some config or preview for example(optional).
1) First I need to figure out how to set custom templates dir for an app.
2) Then I can probably do listdir and get all the folders and then give the admin an option to select the dir.
3) A setting list to specify additonal template folders by users.
1 is the problem.
The main question I want answer for is how to set custom template dir which can be modified anytime.
I found out that askbot (the SO clone) implements this kinda theming where you can place themes in subfolders a folder and the admin can select the folder which he/she wants the templates.
I am new to Django. I guess you can do it using jinja templating.
http://jinja.pocoo.org/
Add a common styling to one html page(base.html)
and then extend the base html to whichever pages u want using extends-- check out template inheritance in the above link
Also you can get some cool templates in bootstrap.. checkout their template section. https://www.w3schools.com/bootstrap/bootstrap_templates.asp
Good luck!
What really is the true meaning of django project and individual apps in it?
I mean - AFAIK you cannot create a project and live entirely in that project you created, you have to create an app in that project to be able to actually do something in django. Please correct me if I'm wrong.
Now what should really be the structure of a django project? I'm writing an e-shop. Let's say my project is named foo:
/foo
/foo
/settings.py
/templates
/urls.py
/wsgi.py
/shop
/__init__.py
/admin.py
/models.py
/tests.py
/views.py
and do everything entirely in /foo/shop/, but I edit urls.py inside /foo/foo/ etc.
I was following the Django Book, but I've begun to gain that strange feeling that /foo/foo/ is just for a main folder "stitching the thing together" but individual stuff should be done only in /foo/shop/, but not limited to. Preferably in /foo/web/, /foo/products/, /foo/forum/, /foo/controlpanel/, /foo/shop/, /foo/helpdesk/, /foo/backoffice/ etc.
Is that correct? Should I put everything products-related in /foo/products/, that including storage management, shipping, dealers, prices etc., then put management of those products (from the employee side) to /foo/backoffice/, which will serve as some sort of "django.contrib.admin" for this? Is that correct? Then if I want to host multiple instances of this (with completely separate databases and stuff) for multiple customers, should i only create a barebone project, that will put these things together, to configure the settings and then just move individual components in some sort of central repository and call them back in the project via INSTALLED_APPS? Because that would be cool as hell! I mean - making all the changes globally, not touching users data and configuration, unless necessary (adding columns in models and such). Is this how django is really supposed to be used? Or am I completely off the track and do things ENTIRELY wrong and this paragraph just doesn't make any django-sense?
I'm relatively new to this. I've been using PHP before and even though Django was a pain-in-the-ass to get basic grip of, I don't regret that and plan to deprecate and make offline any PHP project I created to date and replace them all with django. Well - where it makes sense and is not a single-purpose site. Not only because Django is awesome and versatile, but i cas I can scale it easily as well…
So… How should I really design Django projects, apps, and how to use them in production, providing them to multiple customers?
Thank you!
I mean - AFAIK you cannot create a project and live entirely in that project you created, you have to create an app in that project to be able to actually do something in django. Please correct me if I'm wrong.
You can do plenty of things on just a project, but you need an app for models to be auto discovered.
For example, I have a project with just this in urls.py:
class Homepage(generic.TemplateView):
template_name = 'homepage.html'
def get_context_data(self):
context = cache.get('homepage')
if not context:
management.call_command('reset_cache')
context = cache.get('homepage')
return context
urlpatterns = patterns("",
url(r"^$", Homepage.as_view(), name="home"),
)
You guessed it, it's a really basic website.
and do everything entirely in /foo/shop/, but I edit urls.py inside /foo/foo/ etc.
I was following the Django Book, but I've begun to gain that strange
feeling that /foo/foo/ is just for a main folder "stitching the thing
together" but individual stuff should be done only in /foo/shop/, but
not limited to. Preferably in /foo/web/, /foo/products/, /foo/forum/,
/foo/controlpanel/, /foo/shop/, /foo/helpdesk/, /foo/backoffice/ etc.
Well, you should define /foo/shop/urls.py, and import it from /foo/foo/urls.py ie.:
urlpatterns = patterns("",
url(r"^shop/", include("shop.urls")),
)
The point is to make your apps more convenient to reuse in other django projects.
Is that correct? Should I put everything products-related in
/foo/products/, that including storage management, shipping, dealers,
prices etc., then put management of those products (from the employee
side) to /foo/backoffice/, which will serve as some sort of
"django.contrib.admin" for this? Is that correct?
You should take a look at open source projects and see how they divided that.
According to the directory tree that you represented, you seem to have understood the point, but your statement seems fuzzy so I'll attempt to clarify it.
Apps are generally oriented around models. So if I make a product app it will probably contain:
Product model,
Product list, edit, create, delete and detail view
urls for the views,
Product admin,
tests for Product and views,
other things which are used by other django apps like product/admin.py would be used by django.contrib.admin, but also external apps like django-autocomplete-light would use product/autcomplete_light_registry.py and django-rules-light would use product/rules_light_registry
Then if I want to host multiple instances of this (with completely
separate databases and stuff) for multiple customers, should i only
create a barebone project, that will put these things together, to
configure the settings and then just move individual components in
some sort of central repository and call them back in the project via
INSTALLED_APPS?
There are many ways to do SaaS with django. But I agree that the easiest and most convenient is to maintain generic apps and build a project per customer that reuses (and eventually override parts of) these apps.
I've started working on a django project that has couple apps that are used entirely through templatetags through other apps. Voting app, comments app..etc
Although am faced with a challenge when it comes to rendering assets for that particular templatetag (css,js).
I already have a base.html with blocks for css and js but how would I be able to access them using templatetags to append related assets. Currently am heavily relying on inclusion templates and I did a lot of research and it seems impossible to touch blocks.
any advise? even if I would change the approach of using blocks am open to any suggestion
it seems perfectly reasonable to tell the users of your library (app) that they must include your css/js somewhere in their template. E.g. django crispy-forms does this. Just give them some sample code to include in their base template
Building a django app with some mostly static pages at the front of the site e.g. about.html faq.html
that kind of thing
I was looking at how urls.py work and I created this.
('(.+\.html)$', direct_to_template),
It seems to do exactly what I needed. Now for any new .html page I add to the root of my templates folder it just works. templates/about.html templates/faq.hml
I can also use things like this in my templates
{% include "_menu.html" %}
Now someone has kindly pointed out Django FlatPages and suggested maybe I use them instead. If I'm not connecting to the db are there any disadvantages to the way I'm doing it.
Seems to me like its a better way to do it than FlatPages because it uses the db and isn't quite as elegant (haven't actually used flatpages in practice though)
If you're ok editing template files directly and manually adding new ones to your urls.py file, then stick with what you've got. Flatpages is useful if you want to be able to edit page content from the admin interface or any web-based editing tool you might care to design, or perhaps more to the point: if you want non-technical users to be able to edit the content.
I would suggest moving one step further. If your static content doesn't change frequently and doesn't make use of Django's templates then don't use Django to serve them. Use a light weight server such as Nginx instead.
If you do make use of Django's template features without requiring any dynamic content from the database then you can stick with direct_to_template.
One advantage to using FlatPages is that you can use the Django templates to for headers, sidebars, footers (to maintain a consistent site appearance) while still using mostly plain HTML for the page content. That is offset by the need to store the page content in a database table.
My advice? If what you're doing is meeting your needs, stick with what works.