Django admin CSS randomly gone - django

I was working on the admin interface of my Django project, trying to get the right fields to show up in the right form, then on one of the reloads the CSS stopped loading, the Chrome inspector tells me the CSS files return a 404 error. I don't know what happened and can't figure it out.
It's not a static files issue - the project doesn't use static files at all, and the staticfiles app has been commented out in settings.py (this is not recent, the CSS has been working for weeks without it). Debug is set to True (this also is not recent), however the project isn't served by runserver anyway.
I've tried destroying and recreating the virtual machine the project is running on, which means literally everything except the project's own files is 100% fresh. Problem still persists.
The question is, what can I do to get CSS working again?

Related

Django Admin Styling corrupted

I recently made some changes to my django site, one big one being upgrading from Django 2.2 to 3.1. Now my admin site styling is all messed up. I can't figure out what went wrong or how to fix. Any pointers would be appreciated!
See image of what it looks like after update....
The main home page for admin looks fine, but when I click on one of the models to view, the formatted is definitely not correct.
Also, some not all, of my images on the site are saying 404 not found...
It looks like your browser is caching the CSS / JS from the old version, you can clear your cache and reload. In chrome use ctrl + shift + r to reload.
I was facing the same problem, First I thought it was a Cache issue but it wasn't.
I checked the page source and found a css file being applied to the page which wasn't even present on my drive.
In my case the file was:
static/admin/css/nav_sidebar.css
So I created new file in static/admin/css named nav_sidebar.css,
then copy pasted the code which I got from page source and
added "display:none;" in the #nav-sidebar section(line:34) and [dir="rtl"] #nav-sidebar section(line:45 in my case).
You can find the Original code here by using Google Chrome's inspect tool.
Where to find the code
I had the same issue after bumping django from v3.0 to v3.1. I run python manage.py collectstatic to update css which solved my issue
I was experiencing the same styling as the OP's screenshots.
I had upgraded incrementally from 2.2 -> 3.0 -> 3.1 -> 3.2. I only experienced the styling issues in 3.2
The issue was that there were legacy admin styles committed to the repo in the static folder. To resolve, all I did was delete the committed admin styles, and Django then appeared to use its own styling
I was upgrading from 3.0 to 3.2 and I tried a couple of the answers here without luck. At the end, the following procedure solved it for me:
manually delete the content of the directory STATIC_ROOT (see in settings.py what you named the folder)
run the command python manage.py collectstatic This will repopulate the directory with the newst files
hard refresh your page (ctrl + F5)
I think the other answers here are necessary, but I'll add one more: You might have to bust caches in your server itself. In our example, nginx was configured to provide really long caches to our static files, so we just had to reset it to make changes come through.
Ok maybe I am late to the party but it may help others,
What works for me is:
Set STATIC_ROOT in settings.py (I guess it should be already there as project is old one)
Comment STATIC_DIR in STATICFILES_DIRS list (otherwise it will give error) and run python manage.py collectstatic
Clear browser cache.

Django app copied to new location is still accessing old files, because it is using the wrong settings.py

Django version 1.4, using Supervisor, NGINX, gunicorn, and postgresql 8.4. The project where an app was located has been moved to a different server which also has the domain now. I had another project hosted on this same server, and I want to move my app over to that project with all database data intact.
I moved the app files (models.py, views.py, etc.) to a folder in the destination project, moved the templates to corresponding folders, added the app to the destination project's settings.py, and ran manage.py syncdb. Using PGAdmin's backup and restore I moved all of the data over. After updating some relative references in the python files I was able to access all of the database data (which seems entirely intact) in the Django admin site.
Now the problem: the new urls seem to work fine, but it is using the old project's .py files and all templates. I even commented out the app in the settings files of both new and old projects and all it did was hide the admin site from me.
To identify the problem I inserted a typo into the old project views.py, and got it to throw a traceback, which let me see that it was using the old project's settings.py instead of the new one. How do I make the app switch to the new project settings.py? How is it even finding the old one?
I realize after the fact that this question probably belongs on Server Fault instead of Stackoverflow. I did figure this out, though, and posted the answer on SF:
https://serverfault.com/a/722742/311615

hostgator not recognizing urls.py of Django project

I am working within the File Manager of Hostgator and have already set up a Django project which displays "It worked! Congratulations on your first Django-powered page." Following this, I ftp'ed my local Django project (which works fine on the local server) into File Manager and stored it into a temp folder, copying over the changes to the urls.py, views.py, and settings.py files of the new Django project along the settings path.
However, nothing appears to be changing on the website - it's still on the "Congratulations" page. I've tried moving various templates into different places to see if it responds, but that doesn't appear to be doing the trick. Thoughts?
You need to read documentation about how to manage your project on the hostgator servers

Admin media disappear while running django trunk in development mode

I got into django recently and start playing around with the tutorials & documentation (with the development version). Everything has been fine till I decide to update again to the latest django trunk and well my admin media are not showing up at all!
After some troubles, I managed to get admin media showing by commenting out django.contrib.staticfiles. However as I do use the staticfiles app to manage my site static files, I need it to be enabled. After some troubles, I manage to get both admin media and staticfiles showing by using manage.py collectstatic to collect the admin media files to my static folder.
However is there a way for me to serve admin media in DEBUG mode easily like last time without using collect static command? as I don't want to call the collectstatic every time when django admin media files got changed in trunk? (though I don't know how often/rare that is)
Django trunk is changing how static files are served, and in fact new changes landed this morning.
You'll want to get latest again, and then start here: http://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/

Django admin logging out on model save

I'm running a Django app for my root public_html folder, and it's working fine. But there's a problem with one of my other apps. The problematic app is accessed through a redirect to a subdirectory (e.g. http://workingsite.com redirects to public_html, http://brokensite.com redirects to public_html/foo)
The problem is that the session expires whenever anything needs to be saved in the Django admin (either added or changed). If you try again, sometimes it works. This does not happen on my own machine when I run the Django dev server.
The timezone in both of the app settings.py files is the same, which is the same as the timezone in both of the .htaccess files.
The apps are almost identical, except the working app uses WYMEditor and the broken one uses TinyMCE as its text editor. Don't know why that would do anything to cause the problem, but I included it just in case. Also, I've made a custom CSS file for the admin backend in the broken app (again, shouldn't cause a problem).
Seems to have been a configuration issue with the company I was hosting with - it's not happening anymore.