I like to deploy the Spreecommerce locally and want to implement my own changes. I have deployed successfully but I don't know where the actual sources files comes or running. I need help to sort this out. Please can any one help me.
Thanks in Advance
Bundler downloads dependent gems into a cache location, but you don't want to mess with that if you're looking to make code changes. Anything you change there will be lost later when you update your gems.
You'll want to familiarize yourself with the standard rails customization methods. In order of least-to-most intrusive:
Decorators - files in your host application's app folder structure (assets, controllers, models, overrides, views, etc) which change a single method on Spree's objects by using the syntax Spree::[whatever class].class_eval do and then using standard ruby method definitions (followed by end). These files match their Spree counterpart in the same folder, just in your app instead of Spree's source. And with _decorator added to the end of the filename. See an example here: https://github.com/binaryphile/spree_dibs_1.2/blob/master/app/controllers/spree/admin/payments_controller_decorator.rb
Overriding entire Spree files - copy the Spree source file to the same location in your app then make the necessary source changes. This will override Spree's file of the same name (no _decorator this time). You're taking responsibility for migrating all future code changes by Spree to that file into your copy, which is why this is less desirable.
Fork the Spree source - change your Gemfile reference to your version instead of Spree. Make your changes to this code directly and run it instead of regular Spree. This is highly undesirable, as it makes upgrading Spree versions very involved and difficult.
If you're planning on making the code reusable, you could also investigate making it into an internal or published extension. See the Spree docs on that approach.
Related
I'm completly new with Django and python (and alone as tech in my company, not able to ask help to previous dev). I have to maintain an existing app written in django still developing new services fully written in node, which is my most important task (and my skills). I have a problem that i have fixed some bugs in UX, fixing CSS mostly. And I don't understand how to build sass.
In manage.py, when i ask the list of commands the only things which is related to my problem is "collectstatic" which seems to not build but just collect static files (good naming so) in one folder. And obviously, it doesn't resolve my problem.
Any suggestion ? I'm lost in this big new thing. Many love on every body who can help me. Do you know if there is an integrated tool ? Do i need to use an external compiler which is just not documented ?
Django got nothing to do with compiling assets, you compile it your way in node using your favorite bundler like gulp or webpack and then introduce the final path to django. but people stumbled upon this and created bunch of helper libs, checkout django_webpack.
In case you felt overwhelm then save learning curve time and do like I said earlier, bundle it on your flavor and create a management command in Django that you can run the bundler from python context.
I'm very new to django and web dev in general. I'm following tutorial https://www.youtube.com/watch?v=n-FTlQ7Djqc&index=1&list=PL4cUxeGkcC9ib4HsrXEYpQnTOTZE1x0uc create a blog by 'The Net Ninja'. His django version is 1.x but I'm using 2.1
I have completed it and have successfully emulate it on my own by following along.
But I wanted to make another on my own.
After I created it the files in my static files(the pictures for background) are clashing with my previous project.
Now background photo of my new project shows in previous project (both projects have static files in similar named folder )
So am I supposed to use virtualenv and is this kind of clash normal??? please help
It depends on what you mean with "clash". If you configure both installations to point to the same static files location, then, yes, you might have some "clashes". You can just make them point to separate folders.
As for virtual environments, it's generally a good idea to have a separate one for each project. This way you can isolate your dependencies better. This is especially important if you're going to run different versions of Django concurrently where some third party apps might not work on all versions.
I use both webpack and django. Now I move bundled assets to /static/ directory of django each time, so I'd like to make more effective process.
I read some articles and many people recommend to use django-webpack-loader, but I don't fully understand what it does.
I've already read the official documents below.
https://owais.lone.pw/blog/webpack-plus-reactjs-and-django/
https://406.ch/writing/our-approach-to-configuring-django-webpack-and-manifeststaticfilesstorage/
I think it's for collecting bundled assets located outside of django projects, but it seems almost same as creating a symbolic link from django project to dist/ directory in webpack.
Is there any other useful feature in django-webpack-loader?
It's a handy little tool. This gist of webpack loader is create a mechanism to link up to your latest bundle in an automated fashion.
A "render_bundle" template tag is provided that outputs link to load in either your latest JS or CSS bundle.
The tag is based from a hash of the bundle code (so this will change if your bundle changes) therefore browsers will always load in the most up-to-date version of your static assets. This cache-busting technique is useful when testing on mobile devices or situations where performing a 'hard' refresh of the page is not straightforward.
I believe this is achieved by the template tag referring to the output of BundleTracker, which outputs metadata about the status of your webpack bundle in webpack-stats.json.
https://www.npmjs.com/package/webpack-bundle-tracker
I think you might be missing that webpack will append a random hash code (so new builds bust caches). Without some special logic, django won't know how to account for the hash.
In my opinion all the other stuff the other answerer mentioned are sort of extra bonuses to make your life easier.
I'm making a Django project consisting of several apps and I want to use a version number for the whole project, which would be useful for tracking the status of the project between each time it comes to production.
I've read and googled and I've found how to put a version number for each django app of mine, but not for a whole project.
I assume that the settings.py (in my case it would be base.py, because the settings are inherited for each environment: developmente, pre-production, production) would be the ideal file for storing it, but I would like to know good practices from other Django programmers, because I haven't found any.
Thank you in advance
I don't think I've ever needed to do this, but the two obvious choices would be either the settings file, as you state, or alternatively the __init__.py in the main project app.
You don't need it to relate to django, you can tag a commit in your source control to provide a marker of a particular version (as well as a separate branch for releases).
From the docs for git tagging
Git has the ability to tag specific points in history as being important. Typically people use this functionality to mark release points (v1.0, and so on).
You could use the same versioning number system as google if you so wish which relates to
year.month.day.optional_revision # i.e 2016.05.03 for today
Doing this would make it easier to track back to previous versions since it won't be overwritten in source code by newer version numbers.
I'm using the django registration app in my django site. And now I want to add more custom code. I think it would be better if I can modify directly to the original code of the django registration app.
How can I do that?
Should I just download the source code of the django registration app and then put into my project folder. From my understanding, it will check the files right under my project folder first before checking similar files under DJANGO_HOME\contrib.
Is it right?
Ideally, you should not modify the source unless you want to push the changes back to the original source.
Just create a new app and extend/override/copy whatever methods that are custom for your project.
The reason for this is that if django-registration updates their code, you're gonna run into maintenance overhead. If it's separate, you can still update it with pip (you are using virtualenv right?), and then all you need to change are your custom methods and classes.
Yes, you can simply place it in your project folder, and modify it to work as you wish. You can also remove the installed one since you will no longer need it in this case.
Do remember to included it in your INSTALLED_APPS in your settings file.
Disclaimer: generally, it is considered bad to edit source code of installed apps. Another application on the same host would not be aware of your changes (btw, take a look at virtualenv). You can forget you've changed somehting and get unexpected behavior. You will not track changes. Ie, it's too easy to break something. If you want to change an existing app, copy it to your project dir and then change.
From your other question, it looks you're asking about django-registration from ubernostrum. This app supports custom backends and events that would be probably enough for you.