I would like to use the collectstatic option in my openshift django instance but it appears to be copying loads of unneeded files.
An example line of output
Pretending to copy '/var/lib/openshift/519017e25973ca1ead00035b/app-root/runtime/dependencies/python/virtenv/lib64/python2.7/site-packages/Django-1.5.2-py2.7.egg/django/contrib/contenttypes/locale/da/LC_MESSAGES/django.po'
Here are some snippets from settings.py
if 'OPENSHIFT_HOMEDIR' in os.environ:
# Python dotted path to the WSGI application used by Django's runserver.
WSGI_APPLICATION = 'wsgi.application'
DEBUG = False
DB_ROOT = os.environ['OPENSHIFT_DATA_DIR']
STATICFILE_DIR = os.path.join(os.environ['OPENSHIFT_REPO_DIR'], 'wsgi', 'static', 'mysite')
TEMPLATE_DIR = os.path.join(os.environ['OPENSHIFT_REPO_DIR'], 'wsgi', 'templates')
STATIC_ROOT = os.path.join(os.environ['OPENSHIFT_REPO_DIR'], 'wsgi', 'static')
STATICFILES_DIRS = (STATICFILE_DIR,)
"ls -R $OPENSHIFT_REPO_DIR/ | grep virtualenv" yields no results
ls -R $OPENSHIFT_REPO_DIR../.. | grep virtenv does show a bunch of old virtenvs
Also, this seems strange:
> ls -la $OPENSHIFT_HOMEDIR
drwxr-xr-x. 11 xxxx xxxx 4096 Jan 26 11:45 python
lrwxrwxrwx. 1 root root 50 Jun 7 2013 python-2.7 -> /var/lib/openshift/519017e25973ca1ead00035b/python
It looks like the virtualenv is somehow being included (perhaps via a symlink) in the STATICFILE_DIRS setting. If you do ls -R on STATIC_ROOT do you see anything that should be there?
For others who may experience the same issue.
This was caused by the version of settings.py on openshift being out of sync with my local copy. I had set the STATICFILE_DIR incorrectly and checked it in at some point.
In Django the STATIC_ROOT is the location where the static files get copied to when you run collectstatic. STATICFILES_DIRS is where collectstatic looks for static files to collect. In your case you have STATIC_ROOT set to $OPENSHIFT_REPO_DIR/wsgi/static and STATICFILES_DIRS set to STATICFILE_DIR which is set to $OPENSHHIFT_REPO_DIR/wsgi/static.
So you are copying files from wsgi/static and placing them in wsgi/static. This seems that it might be causing a type of circular situation where it will copy the same files over and over again.
Make sure that STATIC_ROOT is not included in STATICFILES_DIRS.
Related
When I give the command "python manage.py collectstatic" it gives the following problem
"0 static files copied to '/home/leonard368a/leonard368a.pythonanywhere.com/static', 119 unmodified."
does anyone have any way to solve this?
line of command:
STATIC_URL = '/static/'
STATICFILES_DIRS = [
os.path.join(BASE_DIR, 'static')
]
STATIC_ROOT = "/static/"
Collectstatic command use, when you want to deploy your project on server, command copy all static file on local to server this is main use of this command and it's also be use in local but main perpose is copy all file and put on server file manager,
In your case you use the
STATICFILEES_DIRS and STATIC_ROOT are same so in local file system copy static dir to static that why you need to change STATIC_ROOT='asset' or STATIC_ROOT = os.path.join(BASE_DIR, 'asset') in your root dir
static file configration in python any where
collect static in python any where
If it work let me know
After deployment today, for some reason, the project no longer shows style from items that would have been collected during the collectstatic process. I have full access to the files from any browser. I have checked all permissions. I have browsed to the site from the development server, and other machines to eliminate software\font possibilities. No idea what's going on here.
I serve the files from a different server. Other django projects are unaffected. No other django projects use anything like wagtail though. Pulling my hair out at this point and probably just missing something simple. What am I missing?
base.py config
STATIC_ROOT = '/var/www/html/static.xxxxxx.net'
STATIC_URL = 'http://static.xxxxxx.net/'
MEDIA_ROOT = '/var/www/html/media.xxxxxx.net'
MEDIA_URL = 'http://media.xxxxxx.net/'
Checking for file existence on server:
-rw-rw-r-- 1 xxxxxx xxxxxx 13648 Aug 24 09:18 /var/www/html/static.xxxxxx.net/wagtailadmin/css/userbar.3d5222a7eba2.css
Checking CSS relative references
-rw-rw-r-- 1 xxxxxx xxxxxx 68812 Aug 24 09:18 /var/www/html/static.xxxxxx.net/wagtailadmin/css/../../wagtailadmin/fonts/opensans-regular.45f80416d702.woff2
Django Debug Toolbar shows 4 static files used for both the production and development environments. Everything is identical.
In the chrome inspect view, if I replace a relative CSS stylesheet link in the development environment with a link from the file server, it breaks the same way.
From:
/static/wagtailadmin/css/userbar.css
To:
http://static.xxxxxx.net/wagtailadmin/css/userbar.css
Again, I can stick that address in my browser, any browser, and I see the stylesheet. I really have no idea how my file server could be stopping browsers from processing CSS, but that's what it's starting to look like.
Update: in the chrome inspect view, if I remove a css reference that uses a stylesheet from my fileserver, the page loses all the style\colors\etc. If I reapply the link to my server, it applys the styles again. It seems to apply all the style except icons\glyphs.
Update 2: If I change to STATIC_URL = '/static/' I get the styles... Until I turn debug back off :-/
Wagtail's recommended setup for STATIC_ROOT, STATIC_URL, MEDIA_ROOT, and MEDIA_URL is typically much simpler and the ..._URL declarations are typically not absolute references. I set things up in base.py like this:
PROJECT_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
BASE_DIR = os.path.dirname(PROJECT_DIR)
STATICFILES_FINDERS = [
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
]
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static')
STATICFILES_DIRS = [
os.path.join(os.path.join(BASE_DIR, directory_structure_down_to..., 'static'),
--- include as many lines like above as necessary here ---
]
MEDIA_URL = '/media/'
MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
If you use wagtail-react-streamfield, update it. The font wagtail.woff is duplicated there and it gets picked up first (before wagtail's original one) by Django's static subsystem when collecting statics.
The problem I am facing is that my Django project can't find static files.
I was struggling with this issue for quite a while hence,
now I figured where the problem is however, I have no idea how to fix it.
Real static files location:
ls /code/jk/static/jk/css/main.css
ls /code/jk/static/jk/js/main.js
When running: RUN (python /code/jk/manage.py collectstatic --noinput)
I noticed that this provides me a wrong location:
...
61 static files copied to '/code/jk/jk/static', 2 unmodified.
...
There is redundant '/code/jk/jk/static' in the path and I have no idea how to change it.
settings.py
...
STATIC_DIR = os.path.join(BASE_DIR, 'static')
STATIC_URL = '/static/'
STATICFILES_DIRS = [STATIC_DIR]
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static')
MEDIA_DIR = os.path.join(BASE_DIR, 'media')
MEDIA_URL = '/media/'
MEDIA_ROOT = MEDIA_DIR
...
I am using Django application in docker as following:
Dockerfile
FROM python:3
ENV PYTHONUNBUFFERED 1
RUN mkdir /code
WORKDIR /code
COPY . /code/
RUN (pip install -r reqirements.txt)
RUN (python /code/jk/manage.py migrate)
RUN (python /code/jk/manage.py collectstatic --noinput)
RUN (python /code/jk/manage.py migrate)
# clean packages
RUN apt-get clean
RUN rm -rf /var/cache/apt/archives/* /var/lib/apt/lists/*
ENTRYPOINT ["/code/jk/start_gunicorn.sh"]
start_gunicorn.sh
#!/bin/bash
cd /code/jk/
touch ./gunicorn.log
touch ./gunicorn-access.log
tail -n 0 -f ./gunicorn*.log &
#export DJANGO_SETTINGS_MODULE=projectx.settings
exec gunicorn jk.wsgi \
--bind 0.0.0.0:8000 \
--workers 3 \
--log-level=info \
--log-file=./gunicorn.log \
--access-logfile=./gunicorn-access.log \
"$#"
1 - The directory collectstatic collects assets in and directories you store your assets sources in aren't the same.
There are two kinds of directory you must know about with django.
The directories to store your static files sources, from the applications. Usually those are static subdirectories in your applications but you can add your own by setting the STATICFILES_DIRS settings variable.
The directory your static files will be collected into for production and serving. This is defined by STATIC_ROOT and is not the same as the other directories I talked about. In my personnal case, I usually use /path/to/project/staticfiles so I can still use /path/to/project/static to store sources.
Here you seem to mistake both. If I'm not wrong, your /code/jk/static is the directory you expect to get your assets collected into. Yet, you also put some of your sources in it. You shouldn't add assets by hand in this directory, which is collectstatic's job to retrieve them from your sources locations.
[EDIT]: You also should not use a directory as both your STATIC_ROOT location and a location to store your assets sources.
2 - Collectstatic doesn't move your assets to the wrong location, actually it acts exactly as how you defined it.
Assuming that you expect your assets to be collected into /code/jk/static, you should define STATIC_ROOT like this :
# Note: BASE_DIR value should be `/code/jk`
STATIC_ROOT = os.path.join(BASE_DIR, 'static')
And not like this :
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static')
The later defines PROJECT_ROOT as "The directory containing the current __file__ which should be settings.py". Your settings.py should be contained in /code/jk/jk which is therefore your PROJECT_ROOT value.
So when you define your STATIC_ROOT like a static subdirectory of your PROJECT_ROOT it's perfectly normal to get your assets stored in /code/jk/jk/static.
I have a MyApp/static/MyApp directory.
When I run ./manage.py collectstatic, I expect the MyApp directory be copied to STATIC_ROOT, but it doesn't.
I have DownloadedApp/static/DownloadedApp as well and its copied to STATIC_ROOT fine.
What am I missing?
What are the STATIC_ROOT, STATICFILES_FINDERS, and STATICFILES_DIRS in your settings.py?
When collectstatic is run, the default STATICFILES_FINDERS value django.contrib.staticfiles.finders.FileSystemFinder will collect your static files from any paths that you have in STATICFILES_DIRS.
The other default STATICFILES_FINDERS value django.contrib.staticfiles.finders.AppDirectoriesFinder will look in the /static/ folder of any apps in your INSTALLED_APPS.
All of the static files that are found will be placed in the specified STATIC_ROOT directory.
Check out this link to the collectstatic docs
And this link an explanation of the various static settings in settings.py
You can also use python manage.py findstatic to see which directories collectstatic will look in.
just do this and make the naming convention same
STATIC_URL = '/static/'
STATICFILES_DIRS = [
os.path.join(BASE_DIR, 'static')
]
STATIC_ROOT = os.path.join(BASE_DIR, 'assets')
static directory contains all off your project assets
assets directory will create automatic when u run this cmd
python3 manage.py collectstatic
this will copy all static folder content into assets folder
hope this helps :)
That just happened to me and I accidentally put the app's static files directory in the .gitignore file. So on my local machine it got collected just fine, but in production the static files were actually missing (gitignored).
your are missing the STATIC_ROOT where your static files going to be copied just
add this line in your settings.py
STATIC_ROOT=os.path.join(BASE_DIR,'staticfiles')
your settings.py looks like this :
STATIC_URL = '/static/'
STATIC_ROOT=os.path.join(BASE_DIR,'staticfiles')
#added manully
STATICFILES_DIRS = [
os.path.join(BASE_DIR, "static")
]
remember to add STAIC_ROOT path in urls.py
from django.contrib import admin
from django.urls import path, include
from django.conf import settings
from django.conf.urls.static import static
urlpatterns = [
path('admin/', admin.site.urls),
path("" ,include("home.urls")),
]+static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)
After all of it you can run :
python manage.py collectstatic
it will create a staticfiles folder for you in your Dir
This happened to me because while investigating a bug occurring on certain dates, changed my computer date and time.
Hence it disturbed things like collectstatic, and also my browser history.
Don't change your computer date and time.
I was under the impression the comparison would be content based. It turned out to be date based. So, don't mess with your files after collecstatic.
One Quick work-around, although this does not fix it or explain WHY it's happening, is to:
go to your project's file directory & rename your project's
'static' folder to something else like 'static-old'
create a new,empty folder called 'static' in your project directory
now if you run python manage.py collectstatic it will see that nothing is
in your static folder and will copy ALL static files over.
if you have setup everything properly for static and you are using nginx then enter this command
sudo nginx -t
You will see error why your static files aren't being served and fix that specific error
In my case I gave wrong path in my nginx config
location /static {
root /home/ubuntu/myproject/app/static/;
}
I'm using the Django1.3 and python2.7.1.
The collectstatic is a new feature in Django1.3,so i try to use it in my project.
After setup the STATICFILES_DIRS and STATIC_ROOT, STATIC_URL to include each app static directory,
STATIC_ROOT = os.path.join(ROOT_DIR, 'static/')
STATIC_URL = '/static/'
STATICFILES_DIRS = (
# Put strings here, like "/home/html/static" or "C:/www/django/static".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.
os.path.join(ROOT_DIR, 'common/static/'),
os.path.join(ROOT_DIR, 'apps/brokee/static/'),
os.path.join(ROOT_DIR, 'apps/home/static/')
)
i run the command:
python manage.py collectstatic
The static files are copied to the /static/ folder,but I found that all javascript file's name become lowercase.I try it several times and the same result got.
I wonder if it is a bug or something I don't know.
See this ticket https://code.djangoproject.com/ticket/15636