Django compressor renames my beautiful file names in ugly hashes in dev mode, I don't want to compress it, only process scss to css. How to config a django compressor to not rename sass files after processing them, while project runs with DEBUG = True?
Disable it in dev mode. In production you shouldn't need to care.
(It might be prudent to test dev with compression switched on before you deploy, however.)
Related
I have made some changes to my Ubuntu server running Django with Apache. I modified some HTML, JS and CSS files, but nothing has changed.
Things I have tried:
-Clearing browser cache
-Renaming files to try and circumvent cache.
-Ran manage.py collectstatic
-Restarted Apache
-Rebooted server
I was under the impression that changes to HTML files were reflected immediately in Django, so I am really baffled as to how it could still be serving the old version of the file. I have already checked that there are no duplicated files.
I must be forgetting something. Any ideas, anyone?
I'm setting Django on production server and have this strange error(on picture below)
As you can see pythonpath seems to be ok(first row is my project folder), I definitely have module urls.py inside my project/project folder, I have init file there and my ROOT_URLCONF = 'project.urls'(I also tried without project name, but it didn't help either).
So, that is strange why it can't find it :(
I have to say that I tried to create a new project on server and then it seems to be ok, but with this project that is copied from local server it is behaving like this.
Printscreen of error:
The only problem I can think of is the process of package creation. What process have you followed to deploy your Django application?
If you have compiled the Django application on your local machine or CI server and then deployed the compiled package then you will run into Import module issues because pyc files will contain hard coded paths of your local machine or CI servers. To fix it before compiling the python files you should create the same hierarchy on your local/CI server and then compile and deploy.
Hope this helps.
[Edit]
I agree hardcoded paths in pyc files is PITA and we have been doing this in our production environment once we discovered it.
However I do not agree with you to re generate pyc files on the server because as your application will grow and you move towards a large application it will become very slow.
You don't have to keep your development environment directory to follow production directory structure. Instead you can have any directory path on development machine and create a separate bash script which will create a package for you by creating a directory structure that you follow on production. Bash script will have the logic of
Creating a directory structure similar to production
Checking out the code from source control
Compile the code using python -m compileall .
Create a tarball
You can untar this tarball on production server and your application should run fine.
For more information about package creation in python and best practices, check out this video
It doesn't look like your project is in your path, actually. The traceback is only showing Django packages.
I have a django project under a virtualenv.
I included the django-zurb-foundation 5.3.0 package to use foundation but this version only include static css files.
It's my first time using django and normally i use foundation with sass using bower and grunt.
How can i do to use the sass version of foundation?
What should be the files tree?
UPDATE
i installed django compressor and i got it work on local, it works perfectly, but i cannot get it to work on my production server:
on local env i have a CACHE folder with the css static files in it and the html page call correctly the file from there.
On the prod site instead, it doesnt create the CACHE folder and it doesnt render the path to it and it keeps the path to the scss file.
What am i doing wrong?
It seems like compressor isnt working on the prod server, i'm afraid i'm doing something wrong with django settings.py since i'm new to it.
any help?
I have heard of a few people using django-bower with foundation, personally I have not played with it but its worth looking into if you have not already.
I really can't find a reason to use a third party Django application to do that, using front-end frameworks like foundation or Bootstrap is as simple as compiling the less or sass source files to a css file and include it in your html (<link rel="stylesheet"...).
With Django you can use Bower and Grunt without any problem because they're independent and totally configurable to fill your needs. What I do with bower is to create a .bowerrc file at the same level of the bower.json file with the directory setting pointing to the main static folder, something like:
{
"directory": "my_django_app/static/bower_components"
}
Talking about the django-compressor app all that I can say is I don't recommend to use it in a production environment, it has some performance problems and personally I prefer the static files to be responsibility of the front-end dev instead of the back-end dev. For example you will need to have source maps for your javascript for debugging purposes and I don't remember if it's possible with this plugin.
Instead of using the django-compressor you can use a grunt plugin to to it, I've done one that may help you to do so: https://www.npmjs.org/package/grunt-django-compressor
I have a Django app running on Heroku that uses Bower to manage front-end dependencies. These dependencies, along with my application, are optimized with RequireJS and served up using Amazon S3. Is there an easy way for me to know what files in my bower_components directory can be safely deleted from my static file server?
I would leave your bower_components folder in your root, untouched and ignored by your VCS. Then use something like Grunt to copy the selected files into a scripts folder somewhere and then use RequireJS to build those.
This allows you to easily update your bower components and prevents you needing to commit needless repository cruft into your repo.
You can use the Grunt concat or copy task to do this or try the grunt-bowercopy task that will also run a bower install for you
The best solution I have found so far is to use django-pipeline to process front-end assets. django-pipeline will:
...help you by excluding much of the extra content that Bower includes
with its components, such as READMEs, tests and examples, while still
including images, fonts, CSS fragments etc.
(from Using Pipeline with Bower)
I have a django project which is installed by customers on their servers. I've got a few more apps which are optional plugins of functionality that can be installed/uninstalled.
I'd like a simple way to package these plugin apps to make the install/uninstall painless. I dont want them to copy the template files to one directory, app to another one, media to a third one and so on. I would prefer that they need not edit settings.py, though its okay if it can't be helped.
The ideal situation would be if they could simply unzip to a location on the python path (maybe a special plugin directory?), and delete it to uninstall. Is there an easy way to package the apps so that they can be installed this way?
I'll skip over discussion of Python packaging (distutils, setuptools, pip, etc), since it sounds like you'd prefer using simple zip files or tarballs. I'll address the "pain points" you mentioned one at a time:
Template files: As long as you have 'django.template.loaders.app_directories.load_template_source' included in the TEMPLATE_LOADERS setting of your projects, you shouldn't have to worry about this one. Each of your apps can have a "templates/" subdirectory, and templates in there will be loaded just as if they were in your project-wide templates directory.
Media files: App media is a pain. For development, you can use a custom serve_media view that operates similarly to the app_directories template loader (looks for media in each app). In production, you have to either copy the files, use symbolic links, or use webserver-level aliases. There are several utility apps out there that try to smooth over this problem; I now use django-staticfiles.
Editing settings.py: No simple way around this one. For its models, template tags, management commands, etc to work, an app has to be listed in INSTALLED_APPS. What you could do is write some custom code in your settings.py that lists the contents of a certain directory and dynamically adds the packages it finds there to INSTALLED_APPS. A little bit dangerous (think carefully about who has permissions to place files in that directory, because they have the keys to your kingdom), and new files there will only be detected on a server reload, but it should work.
I think if you put together those solutions, it's possible to achieve your ideal situation: unzip to install, delete to uninstall.
Editing settings.py: Your plugin can read its settings from its own settings file in its own directory. They'd only need to edit the root settings.py to add/remove the plug-in path from "INSTALLED_APPS".