I have just deployed a new app on heroku for the first time.
Unlike many others I had no troubles precompiling the assets. They are neatly precompiled and placed in
public/assets. I verified this in heroku bash terminal.
However when I open the project web page none of my assets are served. I verified that the hash to avoid cache stuff was correct.
I have in my application.rb added config.serve_static_assets = true but it made no difference.
There public/assets/manifest.json (pointing to the right files) but no yml and I think I read somewhere about a manifest.yml. Could this be the problem?
Any advice on how to debug this? Or what might be wrong.
Edit
In answer to the comment an example:
There is a file in the heroku app (checked with heroku bash)
public/assets/application-7744776478cb6ee3a23dd79bfcc293bd.css
my browser asks the heroku app for:
´assets/application-7744776478cb6ee3a23dd79bfcc293bd.css´
and the heroku app answers with 404 file not found.
I solved the issue by adding the gem rails_12factor
suggested in: heroku assets not found 404
Related
We are facing a very weird issue. We ship a django application in a docker container through Github Actions on each push. Everything is working fine except collectstatic.
We have the following lines at the end of our CD github action:
docker exec container_name python manage.py migrate --noinput
docker exec container_name python manage.py collectstatic --noinput
migrate works perfectly fine, but collectstatic just keeps on waiting if ran through the github action. If I run the command directly on the server then it works just fine and completes with in few minutes.
Can someone please help me figuring out what could be the issue?
Thanks in advance.
Now I am far from the most experienced but I did this recently and I have some suggestions of where to look. I'm definitely not the greatest authority though.
I wasn't using docker so I can't say anything about that. From the issues, I had here are some suggestions I can recommend to try.
Take note that all of this was for a self-hosted runner. Things would be very different otherwise.
Check to make sure STATIC_ROOT and MEDIA_ROOT variables are set correctly in the settings file.
If the STATIC and MEDIA root variables are environment variables make sure you are serving the correct environment variables file like a .env file which I used.
I used django-environ to serve my environment variables. From the docs, it says to have the .env file in the same directory as the settings file. Well if you are putting the project on a production server with github actions, you won't be able to put the .env file anywhere in the project because it will get overwritten every time new code is pushed.
So to fix that you need to specify the correct .env file from somewhere else on the server. Do that by specifying ENV_PATH.
https://django-environ.readthedocs.io/en/latest/
Under the section Multiple env files
Another resource that was helpful:
https://github.com/joke2k/django-environ/issues/143
I set up my settings file like how they did there.
I put my .env file in a proj directory I made in the virtualenvironment folder for the project.
I don't know if it's a good place to put it but that's how I did it. I didn't find much great info online for this stuff. Had to figure out a lot on my own.
Make sure the user which is running the github action has permissions to read the .env file.
Also like .env file, if you have the static files being collected into the base directory of your project you might have an issue with github actions overwriting those files every time new code is pushed. If you have a media directory where the user uploads files to then that will really be an issue because those files won't get overwritten. They'll just disappear.
Now if this was an issue it shouldn't cause github actions to just get stuck on the collect static command. It would just cause files to get overwritten every time the workflow runs and the media files will disappear.
If you do change the directory of where the static and media files are located as stated before, make sure all the variables for the paths are correct in the settings file and the .env file.
You will also need to update the nginx config file for the static and media root directories if you used nginx. Not sure about how apache does this.
You can do that with this command:
sudo nano /etc/nginx/sites-available/myproject
Don't forget to restart the nginx server after doing that.
If you are writing static and media files at a different location from the base project directory on the server, also check permissions on those directories. Make sure the user running the github action has permissions to write to those directories. I suspect that might cause it to hang but it very well might just cause an error.
Check all the syntax in the github actions yml file. Make sure everything is correct and it's not hanging cause it had an incomplete command or something like that.
But yeah, that's some things I had to take a look at. Honestly, none of this might be relevant for you. All of these issues should cause an error somewhere for the most part.
I couldn't really offer many external resources for you to look deeper into this because I'm just speaking from personal experience.
Hope I could help.
Heres my github repo for the project I did: https://github.com/pkudlanov/personal-portfolio-django
I hosted it on digitalocean on a linux server using nginx and gunicorn.
I am using using ManifestStaticFilesStorage. After performing collectstatic and moving over the files to prod, I still see old css file (with old MD5 hash string) being fetched.
settings.py:
STATICFILES_STORAGE = 'django.contrib.staticfiles.storage.ManifestStaticFilesStorage'
On prod, I can see staticfiles.json showing the correct (new) css file but still when I do 'view-source' from the web page, I can see old css being fetched.
What could I have missed?
Restart Django on prod after moving the files over.
(I don't know why that's required but thats the only thing that works)
Update (Aug 2022): I ran into the same problem after 5 years and bumped into my own post. This time restarting Django also did not help. But restarting Nginx helped (got the hint from #patrickm96's answer) - in case it helps
I had the same problem and restarting gunicorn helped me
Rails 4.1.1 production installation using Apache/Passenger configured to run rails app in a subdirectory "/myapp" instead of the root of the site.
All links in the app work fine, but in production references to assets in SCSS file, for example
background-image: image-url('logo.png');
get compiled to:
background-image: url("/assets/logo-<hash>.png");
instead of:
background-image: url("/myapp/assets/logo-<hash>.png");
I tried doing something like this when precompiling assets:
RAILS_ENV=production RAILS_RELATIVE_URL_ROOT=/myapp rake assets:precompile
but that had no effect.
I also tried setting config.relative_url_root in the config/environments/production.env file, with no luck.
The Rails guides say to set config.action_controller.relative_url_root, but that results in a missing method error.
I eventually gave up and embedded the image in the CSS file by using:
background-image: asset-data-url('logo.png');
which works, but only by avoiding the subdirectory problem altogether.
I know Rails makes you pay for not following conventions, but having an app in a subdirectory is not exactly outlandish.
I've seem all kinds of posts on this problem, but it's hard to get a straight answer. It seems to have been fixed a few times for earlier versions of Rails, but it's not clear if the fixes ever got into the standard Rails distribution.
In our case, we were able to make two changes, which seem to be working for us in Rails 4.1.6 :
1) In application.rb, assume there is a module named "MyAppName < Rails::Application". In here, we have
config.relative_url_root = "/myapp"
2) In config.ru:
map MyAppName::Application.config.relative_url_root || "/" do
run Rails.application
end
Without the config.ru update, things don't work properly.
After adding the jquery-ui-rails gem to another app deployed in a subdirectory, I had the same problem with the assets referred to by the built-in CSS for jQuery UI. I refused to modify the 3rd-party CSS files just to fix this problem, especially since Rails seems to be handling all paths (other than asset paths) correctly out of the box.
After pulling my hair out for some time, I don't know what prompted me to re-run the rake assets:precompile task exactly as given here. To my complete surprise, everything worked perfectly, both my own image URLs and jQuery UI's.
What made the difference? If I call the rake script from the app's bin folder as shown below, all the asset URLs are built incorrectly, without the subdirectory.
RAILS_ENV=production RAILS_RELATIVE_URL_ROOT=/myapp bin/rake assets:precompile
If instead I run rake via bundle exec, as follows, all the asset paths are generated correctly, including the subdirectory.
RAILS_RELATIVE_URL_ROOT=/myapp RAILS_ENV=production bundle exec rake assets:precompile
As to why this is happening, I can only conclude that running bin/rake does not load the right gems.
I'm trying to work through the "Getting Started with Django" heroku tutorial. Things are working when I run the framework locally with foreman, but when I try to run it on Heroku, it is failing when trying to find the settings module.
In a nutshell, I've done...
chris#xi:~: mkdir hero
chris#xi:~: cd hero
chris#xi:~/hero: django-startproject ku .
and then I create and edit the files per the instructions. Perhaps I have gotten something wrong?
in ~/hero, I created my Procfile and requirements.txt, as well as the ku directory that was created by django-admin
in ~/hero/ku I have settings.py and wsgi.py (created by django-admin and edited by me)
any idea what I'm not doing correctly?
found it after much trial end error. It turns out that I had an old .gitignore file in my home directory that ignored settings.py. Once I added settings.py to the project and re-pushed, everything started working.
I don't like putting settings.py into git because it contains machine-specific information, as well as security information. But I guess I will leave it for now, and when I have to do it for real, I can use the heroku config:set command to set up things like database users and passwords, or paths to DJANGO_SETTINGS_FILE, etc.
I wanted to start playing around with Django again (I'm not an expert in Python/Django, but I can make nice things work tho). I used Mezzanine once just to see how it worked. The 'mezzanine-project myproject' command worked like a charm as I had a nice small app running quickly. So, today I downloaded the new Mezzanine 1.3 along with Django 1.4.3 and all its dependencies (pillow, pytz, html5lib, etc) and tried to create another project so I could now work on it in a more consistent manner for personal purposes.
For my surprise, when I ran the server, I got lots of 404 errors pointing to missing /static/ files. Also, after creating the database (with manage.py createdb command), the only thing created was the static folder containing only the pictures of the predefined gallery that come along with Mezzanine. Also, there is no Log in or signup buttons as well.
I've tried making a clean install of all Python and its site-packages with the same result. I also tried copying/pasting the folders containing missing files from the /site-packages/mezzanine folder into my project, but the result was just reducing the number of 404 messages.
I've been doing an extensive research on this issue (with no luck but maybe because of the release being recent?) and even trying to contact someone on the Mezzanine IRC channel with no success.
I hope I'm not missing something silly. Do I have to change anything (note that I'm ok with the old mezzanine default settings) in my settings.py or in a specific file before running manage.py createdb command?
For the record: before running createdb, The only thing I edited was settings.py and changed the database parameters to make it work with my MySQL Server and commenting the local_settings configuration as I do not need it.
Some parameters that could be of help:
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(PROJECT_ROOT, STATIC_URL.strip("/"))
By default, DEBUG is set to False in settings.py, and DEBUG is set to True in local_setting.py
Given that, if you just commented out importing local_settings.py, DEBUG would be False.
Django's development server won't serve static files when DEBUG is set to False, see the staticfiles section of the Django docs for more details.