I am working on an existing django project where admin console is extensively used.
With my latest run of package upgrade for my application admin page layout has changed.
Models have started appearing on all the pages, leaving a small space to display form fields.
For example this is how form page look like now:
Original Form view was occupying the whole page like this:
Any clue on what has been changed and which setting to change to get back the original view?
From the django-3.1 release notes,
The admin now has a sidebar on larger screens for easier navigation.
It is enabled by default but can be disabled by using a custom
AdminSite and setting AdminSite.enable_nav_sidebar
to False.
You can refer Customizing the AdminSite class - (django doc) to know more about customizing the AdminSite
Try this, open your browser and clear all the history then login back in again and it should work. I am sure the browser has cached an old version of Django admin.
I had the same problem when using version 3.1. I started a new demo app with version 2.2 to demonstrate something and when I got back to version 3.1 I got that issue, So what I did was just clear the browser history and everything came to its original state.
Related
I have built a Django application with a custom interface. It hasn't been changed in a couple of years.
These (previous) servers are running Django 3.0.8.
Recently I set up a new server, and the Django Admin interface now shows the model list in a scrolling iframe, and long tables on the right side are also scrolled independently of the page.
This server is running Django 3.2.3.
I don't like the new interface, but it more importantly it will require an extensive rewrite of our custom admin css.
Can anyone point me to information about the change, or tell me if there is a setting to disable it?
I found the answer in this Stack Overflow answer. I will leave this question up because the other answer doesn't mention iframes.
Django 3.1 added the new scrolling sidebar in an iframe.
To disable it add the following to the root urls.py file:
from django.contrib import admin
admin.autodiscover()
admin.site.enable_nav_sidebar = False
The 3.1 Release Notes say:
The admin now has a sidebar on larger screens for easier navigation. It is enabled by default but can be disabled by using a custom AdminSite and setting AdminSite.enable_nav_sidebar to False.
Reference links from the original answer:
Django 3.1 release notes
The Django admin site
I've just set up a new local version of my django application, and all working fine until I checked on the django admin.
127.0.0.1:8000/admin works fine and brings up the usual Django Admin homepage with full list of apps, but when I click into any of the individual app elements it breaks. The URL changes, but instead of displaying that app's admin site it shows an oddly rendered version of the admin homepage, with the app list collapsed on left side of screen (see screenshots below)
Can't immediately see which parts of codebase could be relevant here, so please request copies of any code you want to see.
The correctly displayed Django Admin homepage
How it renders when I click into any of the individual app/model admin sites
As above, with list of all apps expanded from left
This happened to me when I upgraded to django 3.1.
Set admin.site.enable_nav_sidebar = False on your admin.py file.
from django.contrib import admin
admin.site.enable_nav_sidebar = False
Actually the admin does load the pages for every model but the nav_sidebar takes all the space. If you zoom out long enough you'll see the models and forms are there.
I have a snippet called event, After upgrading to wagtail 2.5.1 (Still i am not sure if this issue is related to version 2.5.1) The previous events aren't displayed on the wagtail admin page anymore. However i am able to search for them in the search box.any help is appreciated
I just started using django-cms 3.01 and django 1.6.4/python 2.7.6. My last experience with django was 1.4 and I've never used django-cms before now.
I am trying to follow the instructions in the official documentation on Extending the Page & Title Models, but I am experiencing an issue.
The custom field I need to add is very similar to the example, so I simply used their code exactly. Rand a syncdb, started the server and everything was going well. The field shows in the admin just fine. There is an entry in the admin menu for "Icon Extensions." I click add, and I get to the form to upload the file. I go to upload the file, and I receive the following error:
DoesNotExist at /admin/the_site_name/iconextension/add/
IconExtension has no extended_object.
...
Exception Type: DoesNotExist
Exception Value: IconExtension has no extended_object.
Exception Location: /Users/me/Sites/the_site_name/env/lib/python2.7/site-packages/django/db/models/fields/related.py in __get__, line 326
Most likely I'm just missing something simple, but I can't figure it out. Should I have a foreignkey linking it directly to the page? I thought it was handled automatically, but obviously I'm not completely getting it jsut yet.
Any help is appreciated.
You must edit extensions in the frontend editing toolbar. Add a button to toolbar as described in the section "Adding a Toolbar Menu Item for your Page extension" in the documentation you linked above.
My django_session table was growing very large and it seems to be due to a pingdom bot that I set-up hitting my login page. I tried creating a brand new django 1.4 app and the behaviour is replicated on any page that uses the django.contrib.auth.views.login page, including the default admin login page.
This surely can't be the desired behaviour. Is it a bug? Is there a fix?
(I have redirected the pingdom bot to another page that doesn't cause a new session to be created but I'd like to solve the django issue itself too).
I have seen the question here Huge Django Session table, normal behaviour or bug? and it doesn't seem to be the same issue
After a little bit of searching I found that this is done by the login view (line 55) in the set_test_cookie() method.
In the latest version of Django (git main) it has been removed however: https://github.com/django/django/commit/9d2c0a0ae6ce931699daa87735d5b8b2afaa20f9#django/contrib/auth/views.py
For the time being I would simply recommend you to use a modified version of the login page which doesn't use the set_test_cookie() method.