I would like to add a link to / to every page in template. Can I do it without changing django internal template? I could customize django, but this is something I seriously wouldn't like to do.
Sure, just override one of the Django admin templates in your own templates/admin directory. For instance, copy the contents of django/contrib/admin/templates/base.html into yourproject/templates/admin/base.html. Then, change the latter to your heart's content.
See: https://docs.djangoproject.com/en/dev/ref/contrib/admin/#overriding-admin-templates
According to the accepted answer, I still failed to make it. After some try-error experiments, my answer is:
copy django/contrib/admin/templates/base_site.html to as your_project/templates/admin/base_site.html
customize your local base_site.html to whatever you want
add to your settings.py
TEMPLATE_DIRS = ('templates',)
Related
I have made alot of models and forgot to register them when I made them, after I realized I didn't register them I went and registered them the usual way (shown below). I've deleted the database and all migrations (including __pycache__) but haven't deleted the __pycache__ in the inner project folder (that holds settings.py) because I don't know if that would cause problems or not. I've tried using admin.register(Comment,admin) but that didn't work and, as you know, isn't necessary. I'm not sure what other information I would need to give so please let me know what else you need to know. Just so you know, I have 'django.contrib.admin' and 'django.contrib.sites' in the INSTALLED_APPS and also have path('admin/', admin.site.urls) in the project level urls.py
admin.register(PicturePost)
admin.register(VideoPost)
admin.register(TextPost)
admin.register(Comment)
admin.register(Report)
Please use below code because you are not using correct method to register the model. admin.register is method decorator for ModelAdmin class.
admin.site.register(PicturePost)
admin.site.register(VideoPost)
admin.site.register(TextPost)
admin.site.register(Comment)
admin.site.register(Report)
admin.register is a decorator that you should apply to custom ModelAdmin classes - not a function that you can use to register models.
You need to use admin.site.register instead:
admin.site.register(PicturePost)
etc.
I have a lot of apps running on my site and I was wanting to make all the views accept a certain kwarg without having to go in and edit them all manually? Is there a way to do this?
I suppose I should add it into the django base view class somewhere, but I am unsure exactly where to add it to in that?
Any ideas?
EDIT:
What I am trying to do is have translations set in my db under a certain model and then have the site default text areas be displayed in a certain language based on the url...
/eng/some/url
/esp/some/url
those two urls would display different languages, but I have to capture the variable and put it into each and every view which is quite cumbersome
Django already has some i18n support in urls, check it out. You need to activate django.middleware.locale.LocaleMiddleware by adding it to your settings.MIDDLEWARE_CLASSES and to tune your urlconf a bit by wrapping your urls with i18n_patterns.
The complete example is given in the docs, I see no sense copying it here.
I have recently installed Django Userena on my Linux Apache server.
After correcting some errors, I began looking through the documentation. However, after searching through the docs and after many Google searches, I still cannot find out how to change the appearance of the pages! For example, how do I change the appearance of the signin page, the signup page, etc? I know that each userena template extends base.html, but where do I go from there?
I am probably missing something very simple, so please forgive me if the answer is very obvious.
This is the signin method signature for Userena(source) -
def signin(request, auth_form=AuthenticationForm,
template_name='userena/signin_form.html',
redirect_field_name=REDIRECT_FIELD_NAME,
redirect_signin_function=signin_redirect, extra_context=None):
As you can see, there is a template_name method that holds the template location. You can override this. In your urls.py, you can use it like -
url(r'^signin/', 'userena.views.signin', {'template_name': 'signin.html'}, name="signin"),
You can then create the signin.html page inside your templates folder and extend base.html. The signin view sends the login form in a variable called form. You can see the source. You can use the form on your template signin.html like {{ form.as_p }}. You can also format each field individually if you can follow the userena.forms. AuthenticationForm. Again, check the source code. You can do the same for any view Userena has that allows overriding like this.
When in doubt, read the source code. :)
You need to override userena default templates.
Create a directory inside your templates/ named userena/, Then for example if you want to change signup form, easily create signup_form.html template file inside that userena/ dir that you've just created and start writing.
For instance here is default signup_form.html template.
You can find userena default templates at its github repo
Just copy the supplied userena templates in your template directory.
You can find them on a linux box with find / -name userena
The path you are looking for is ../userena/templates/userena. Copy the userena folder into your template directory and start changing the signin_form.html.
Just copy the templates to your own template directory. If you follow this link download and just copy the directory 'userena' to your template directory. You can then customise the templates including the email text and templates.
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.
I have flatpage attached to multiple sites. Its admin preview chooses
arbitrary site, which is quite obvious after debugging up to lines 35-36 of
django.contrib.contenttypes.views.shortcut().
What would be the best way of fixing this problem?
I see that the shortcut() function takes a request object, so I could just extract host from there, but I prefer to not patch the live server.
I haven't looked at catching admin url yet, so maybe someone can suggest some nice solution?
In my opinion, this could be considered a bug in Django, and at least a partial fix would be to check if the current SITE_ID is one of the sites related to the object, and if so use that one instead of an arbitrary one. You could file a ticket with a patch.
To fix it without patching Django, you might look into overriding the admin edit-form template for the flatpages model so that you can put the URL you want into that link instead of the default one that goes to the shortcut view. I haven't looked into it enough to know how clean that would be.
Another option might be to monkeypatch the Flatpage model with a get_absolute_url method that actually returns a complete absolute url, including the domain, based on Site.objects.get_current().domain.