I'm new to this, and experimenting with a Django site that has both a main folder and a static media folder. I'm trying to install django-bootstrap, but not sure how to go about it.
I'm using the instructions in this Django Bootstrap page.
First, do I run
pip install -e git+git://github.com/earle/django-bootstrap.git#egg=bootstrap
from the terminal in the main folder, or static media folder?
Second, where do I insert the usage code?
from bootstrap.forms import BootstrapForm, Fieldset
class LoginForm(BootstrapForm):
class Meta:
layout = (
Fieldset("Please Login", "username", "password", ),
)
username = forms.CharField(max_length=100)
password = forms.CharField(widget=forms.PasswordInput(), max_length=100)
The above is obviously only for login fields, but will I need to include that import language in many files, or just one main one?
EDIT for clarity: My host is WebFaction, which uses a Domain + Webapp = Website structure for site hosting. One of their recommended methods for Django installs is to set up the main Django site in one webapp, and a static media folder in another: see here for details.
I am not the site creator or installer, but have copied the site over into a test version so I can mess with its design while the programmer is unavailable for an extended period. I'm looking into Django Bootstrap as a way to make it easier to redesign the site. My skills are obviously limited, but I'm willing to read/learn!
Django-bootstrap is a Django "app", installed as a python package. Since webfaction doesn't do virtualenv, you should be ok* to just ssh in and run
pip install -e git+git://github.com/earle/django-bootstrap.git#egg=bootstrap
from wherever. This will install django-bootstrap to your global python site-packages folder.
Next, you'll need to make sure django knows about it, which you do by editing the settings file and adding it to INSTALLED_APPS, e.g.
INSTALLED_APPS = (
# ... other things
'bootstrap',
# ... maybe more things
)
Any python file that uses the BootstrapForm and Fieldset classes, will require the import statement at the top of it. A python module (file) will only know about a) what you declare directly in it, and b) what you explicitly import. I don't know how you got anywhere using python without knowing that, because it's pretty important. Consider reading up on the subject.*
Anyhow, the only thing django-bootstrap seems to do is change django's form-rendering code to output HTML that is more compatible with Bootstrap. You will still need get twitter-bootstrap yourself, and make sure that you use the media, i.e. the css, js and images, from it. Put the bootstrap media in your static app.
http://twitter.github.com/bootstrap/
*Edit: I just read the last bit of your post and now I feel like a big meanie. So, here are some extra resources that I recommend you read through.
Python samples: http://wiki.python.org/moin/SimplePrograms
Django's Tutorial: https://docs.djangoproject.com/en/1.3/intro/tutorial01/
I'm afraid I don't quite understand the question. pip install will install this in de site-packages folder, not in the location you are running the command from.
The code is a form so would go into a forms.py within the app you are trying to make. That form inherits from BootstraForm, so you would just use the LoginForm where you want and it would be a BootstrapForm.
Related
I found a similar question, with this reply: "...django-simple-blog is an app, meaning you install it within an existing project."
But I need more explanation. Can someone explain to me how to "install" an app within an existing Django project? And what it means to do so? (I use Pycharm).
Django allows us to add multiple apps.
For eg.: if we want to add multiple social authentications, we can install django-allauth
install a thirdparty app
pip install django-allauth # or any other app you like.
or create a new one
django-admin startapp simpleblog
then we modify our settings.py in our django project.
INSTALLED_APPS = [
...,
'allauth', # add the app name here.
'simpleblog',
]
You can refer following to learn more about Django:
https://docs.djangoproject.com/en/2.1/
https://tutorial.djangogirls.org/en/
https://www.twoscoopspress.com/products/two-scoops-of-django-1-11
I have a project that I've built over the last several years, and it was started in Django 1.4. The server that runs this project is due for replacement, so I'm in the process of migrating to the new server.
I'm considering taking this opportunity to upgrade the project to Django 1.7. I've been looking over the notes, and I know I will have some work to do regarding url tags, and some other things. But, it looks like the main structure of projects has changed. In my project, the settings.py, static folder, and the project wide urls.py files/folder were all within the project's root directory. However, in 1.7 (and probably a few version earlier) it seems these files/folders are moved to an app folder within the main project.
For example, my 1.4 project has a project structure of:
project folder:
- urls.py # all other app urls.py files are included in this main urls file
- static # all static files for the whole project reside here
- settings.py # project settings
./app:
- urls.py #app specific urls
But now, it seems the default project structure has changed to this:
project folder:
- # there's nothing here other than the "manage" script
./project:
- # an 'app' with the same name as the project now holds project wide files
- urls.py # project wide urls file?
- settings.py # project wide settings? within this app folder?
- static # project wide static files to be held here?
So, will I even be able to run my project in 1.7 given the new project structure?
You can have whatever project structure you desire in Django. So you will be able to run your project barring any other upgrading issues. One of the best current examples of project structure is the Django Cookiecutter by PyDanny.
Besides abstract user classes, authentication, and migrations ( and the commands like syncdb / schemamigration that go with it) nothing should really stand in your way to upgrade. Some things have been depreciated but they're well documented and easy to fix. In each release, they've ensured the upgrade path and backwards compatibility is clear and as good as possible.
I'd recommend following the best practices with 1.5, 1.6, and 1.7 that have changed the way the community writes Django applications. My favorite resource for to learn about them is Two Scoops of Django. PyDanny is one of the authors. There are two versions, for 1.5 and 1.6, and each goes over the major differences between the previous version and how the new features have changed the way you should write Django apps. By reading both you could get a clear view of how to upgrade your app from 1.4 to 1.5 to 1.6. Beyond that, the release notes of each version, and the django-cookiecutter are great places to see whats changed and what the new best practices are.
I want to be clear that this is a distilled version of the answers found at the link provided by harshil above. I am adding it here in case the URL breaks in the future as it helped me.
ADD A SECRET_KEY TO YOUR SETTINGS.PY
Changed in Django 1.5, Django now requires every project to have a SECRET_KEY.
THE CONCEPT OF APPLICATIONS AND APPLICATIONS REGISTRY IN 1.7:
This is a new concept introduced in 1.7 where Django maintains a registry of your installed applications, hence making it really easy to manage and introspect all your apps. The best part I liked about this feature is that it makes it super easy to manage subapps and also run initialization code when each app is ready.
You can learn more about this here: https://docs.djangoproject.com/en/1.7/ref/applications/
UPGRADING DJANGO TEMPLATE URL TAGS TO USE NEW SYNTAX INTRODUCED IN DJANGO 1.5:
If you were already using Django’s {% load url from future %}, you can skip this step, but in case you weren’t you must now change your url tags from {% url view_name args %} to {% url 'view_name' args %}.
There is this awesome sed command that you can use to convert all your url tags to the new format. You can either run this command from your template directory
sed -i -r -e "s#\{% url ([a-zA-Z0-9_.:-]+)#\{% url '\1'#g" *
or in order to run it recursively you can run the following:
find . -type f -print0 | xargs -0 sed -i -r -e "s#\{% url ([a-zA-Z0-9_.:-]+)#\{% url '\1'#g"
Credit goes to Enrico for posting this shortcut on stack here.
APP LABELS
While migrating from Django 1.4 I had issues where the new django migrations (which is the next topic) had issues recognizing which ‘app’ a given model belonged to. As a rule of thumb, I would just add app_label to all the models Meta class and set it to the package (folder) name.
MIGRATIONS
With Django 1.7 you no longer need south, since migrations are now built-in. The best way to migrate from south to django migrations is to delete all the migration files from your migrations folder (leave the __init__.py in there).
Run the following to generate all the new migrations:
python manage.py makemigrations
followed by migrate (if django sees that the table already exists then it won’t run those migrations)
python manage.py migrate
URLS.PY
You might have the following in all your urls.py
from django.conf.urls.defaults import patterns, include, url
You will want to replace that with:
from django.conf.urls import patterns, include, url
HTTPRESPONSE
If there is any code that sets the mimetype of the HttpResponse manually you will need to change it to content_type.
HttpResponse({"message": "hello world!"}, mimetype="application/json") becomes HttpResponse({"message": "hello world!"}, content_type="application/json")
GET_QUERY_SET
The get_query_set method has been deprecated in preference for get_queryset. So you will need to change that as well if you were overriding the get_query_set method previously.
CACHING
If you were using ORM caching like johnny-cache, you will need to either kill that, roll your own or upgrade to something like django-cachalot.
PLUGINS:
Remember to upgrade all your requirements and plugins. A lot of the older plugins might not be compatible with Django 1.7.
Upgrade to Celery >= 3.1.16
Here is a good list of things to keep in mind when upgrading from 1.4 http://labs.seedinvest.com/backend/upgrading-from-django-1-4-to-django-1-7/
this article suggest the best way to do it, is one version step at a time:
This section will make it clear that you should only ever upgrade one release at a time. You should not upgrade from 1.4 to 1.7 directly. Instead, make the jump from 1.4 to 1.5 first, then proceed to 1.6, and so on. This is in keeping with the idea of taking small steps.
see:
http://andrewsforge.com/article/upgrading-django-to-17/part-4-upgrade-strategies/
However, it probably depend on the time a project can be 'on hold' during refactoring it to a newer version probably mean the progress of new features and so on has to be 'on hold'.
I guess doing it all at once, is a big step, so a lot of work at once, but dividing it in small steps (version by version) means shorter tracks, but the overall track will probably be longer.
I'm trying to install the following django app from the cheeseshop:
https://bitbucket.org/codekoala/django-articles/overview
This is my first day of Django-ing and I'm unsure what to do to get the app's folder populated inside my project.
So far, I've pip installed the app into my virtualenv. This is verified by opening a python shell and getting no errors when I run "import articles"
I've edited the settings.py file and added it to the list of installed apps. I believe this to be OK as I can then run runserver without any "module not found" errors.
syncdb also ran fine.
Where do I go from here?
ie, I would like to have a section of the website called News which uses this app. I have no routes or other apps configured yet, just a clean Django with psycopg2.
EDIT: Enabling the default admin site, I can manage the Articles there, but still unsure of how these will be displayed on the site when I have no app folder created for them. When trying to startapp articles, I'm warned it's conflicting name with an existing module..
No need to create a new app called articles. As you are able to import articles via the python console you have successfully installed it. You can find it in your virtualenv folder in the folder site-packages:
/path_to_your_virtualenv/.virtualenvs/<virtualenvname>/lib/<pythonversion>/site-packages
You can use this app, installed via pip, as it is an app which lives in your project folder.
You just need to include the articles urls in your own urls.py. Since you say you want it under News, this would do fine:
urlpatterns = patterns('',
(r'^news/', include('articles.urls'),
)
Note though that the readme for the articles app implies that you'll need to create your own base template for it to inherit from. Just create a base.html file in a directory called templates under your project, give it a basic HTML structure, and put in {% block content %}{% endblock %} in the relevant place (and the same for the other blocks mentioned in the readme).
You should probably do the Django tutorial anyway, to understand exactly what's going on with the URL and the templates.
I'm trying to write a custom command that works outside of Django projects. I was thinking I could follow the coding patterns of Django's own such commands (e.g., startproject), include my command in an app and install it.
Alas, it seems django cannot see this command, as perhaps it doesn't scan site-packages for custom commands.
Is there a way to make this work or am I sadly correct?
UPDATE: I should note that the goal I was trying to accomplish (writing a command that starts projects based on custom templates) is supported in the coming 1.4 release of Django: https://docs.djangoproject.com/en/dev/ref/django-admin/#django-admin-startproject (see the --template option).
Based on this code from django.core.management, it does appear that django only searches for project-less commands in its own packages, and will then only find command by scanning INSTALLED_APPS, which means a project is required.
You can use a custom manage.py.
You do need a project. A project is, although, nothing more than a python package with a settings.py (and maybe a urls.py file)
So you could just create a project, with whatever commands you want, and in your setup script include a binary script that is nothing more than a manage.py in disguise.
I use it to have a manage.py in the bin path of a virtualenv, but you can call it something else and have that "django" project installed in your system python.
I don't quite understand from your post, for what purpose do You want to write such command using Django's manage.py. But suppose you want (as I was) to run some script, that works with Django models, for example. You cannot run such script without setting Django environment.
I do the following:
put my code in script.py
manage.py shell
execfile('script.py')
Maybe, this helps.
If anyone knows how to make django-cms play with grappelli, please give some tips
Well I've just gone through a fairly epic adventure, the story of which might be of some use to you. The end point of said adventure was getting django-cms 2.1.3 working with django-filebrowser-no-grappelli . Whilst that may sound in fact like the opposite of what you want, I ended up there because what I really wanted was to get django-cms working with filebrowser. Without grappelli though the standard django-filebrowser does not work as expected. But with grappelli django-cms does not work as expected. So therein lay the rub, to quote shakespeare. Getting django-cms working with filebrowser was relatively straight forward except for the fact that when trying to upload files with uploadify (which is shipped with filebrowser), after selecting the files in the file dialog, nothing happened. Eventually I figured out that this was because the jquery library was being loaded twice: once by filebrowser for use with uploadify, and once by django-cms. So by commenting out the second line in this file:
your site packages dir/cms/templates/cms/toolbar/toolbar.html
which loads jquery.min.js, uploadify worked as expected. Soooo...if you just want to get django-cms working with grappelli so you can use filebrowser, the above might be helpful. Here is my settings file for reference.
My solution is to implement 2 subdomains, 'www' and 'cms', in each of which a separate instance of the Django site is running with a different STATIC_ROOT and a modified INSTALLED_APPS. grappelli runs in the 'www' subdomain. It is not running in the 'cms' subdomain, so that you can use django-cms there.
Set up a subdomain: cms.example.com
Modify your webserver to serve this subdomain. Use the same settings as your main django site but point to a different script handler. e.g. if using wsgi direct the server to run wsgi_cms.py
cp wsgi.py wsgi_cms.py. Edit wsgi_cms.py and change the line
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
to os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings_cms")
settings_cms.py :
:
from settings import *
INSTALLED_APPS.remove('grappelli.dashboard')
INSTALLED_APPS.remove('grappelli')
STATIC_ROOT = os.path.join('/what/ever/static_cms/')
STATIC_URL = '/static_cms/'
ADMIN_MEDIA_PREFIX = STATIC_URL + 'admin/`
modify settings.py: change INSTALLED_APPS from a tuple to a list
restart web servers
./manage.py collectstatic --settings=myproject.settings_cms
your regular site continues as normal. To edit django-cms pages with grappelli disabled go to http://cms.example.com/admin/cms/page/
I've once made a django-cms fork on github that supports grappelli, it's a bit outdated, but maybe helps you to get started or probaly you'd like to contribute.