The issue is becoming clearer to me too. I’m going to start off with a short rant which will seem like a tangent but then we will continue troubleshooting my static files configuration.
Setting up static files properly has been a pain point for me in the past for as long as I have been using Django (as a hobbiest not a professional developer).
My understanding of Django’s architecture, each web app should have its own static files in development. Then when deployed to production, collectstatic is invoked to gather all the static folders from all the individual web apps and then put them in one place for the web server to handle. That makes sense. But when setting up the static file configuration, when I have a question, different developers on the web on Stack Overflow or teachers in different Udemy courses, all use different static file configurations. So if one proposed solution I find online doesn’t work, I then proceed to try a different static configuration until I get it to work. After having run collect static a few times, it’s too late because now my source code has 5 static directories (2 in the top-level project directory, 1 in the directory that includes settings.py, and 2 more for each of my 2 web apps - - so 7 total). Some directories are hidden with .gitignore and others are not. In one of my other projects, when I was first starting out, when I wanted to make a change to a CSS file, I made a change to the code, but the effect on the webpage was unapparent. So to experiment, I tried making changes in 5 other places until I finally got it to work. Additionally, if I forgot to clear my CSS cache, that could be part of the problem as well. In my main Django project which is mostly finished and deployed in production, I know which CSS file I need change locally and then when I push to prod, the Heroku Python / Django buildpack runs the collect static command automatically and everything just works. I don’t even have to think about it. But here I am today working on a brand-new project, and the static file configuration is completely different and I am unsure which CSS files I need to make changes to or which static folder is the one which Django needs to refer to to get CKEditor to work.
The official Django tutorial that you linked to Ken recommends this (as a general example for the polls app):
STATICFILES_DIRS = [
That’s basic. Everywhere else on the web (Udemy courses, and SO) use dynamic path references using the Python builtin
os module. Here are my 5 static file declaration lines in my current settings.py:
STATIC_URL = '/staticfiles/'
STATICFILES_DIRS = [ os.path.join(BASE_DIR,'static') ]
STATIC_ROOT = os.path.join(BASE_DIR, 'static')
STATICFILES_STORAGE = 'django.contrib.staticfiles.storage.StaticFilesStorage'
CKEDITOR_BASEPATH = "/staticfiles/ckeditor/ckeditor/"
For the CKEditor base path line, it looks like the authors of the app may have ‘taken the liberty’ of using (or assuming?)
/staticfiles/ is the active static directory. Maybe they assumed that the end users of the web app are smart enough to understand how to handle Django static files and change it accordingly to meet their unique usecase. Evidently I am not that smart. In my setup as you can see in the above snippet, I build the
STATICFILES_DIRS string using the
.join() casting technique (as most other people on the web do that the official Django docs don’t address). Yet I also have a
STATIC_URL set to
'/staticfiles/'. So which is it? My question at this point boils down to this @KenWhitesell or anyone else following along this sordid commentary: Which one is needed and which one should I modify or get rid of?
I already tried changing
"/static/ckeditor/ckeditor/". That didn’t resolve the issue.
I have the following note in my settings.py which I have commented out but kept it there for my future reference:
# I got the below from:
STATICFILES_STORAGE = "whitenoise.storage.CompressedStaticFilesStorage"
The reason why I kept that in as a comment in my settings.py is because I spent considerable time troubleshooting my static files configuration while mashing the keyboard several weeks ago and using that
whitenoise element was an actual potential candidate for inclusion because I thought it could be a working solution.