To keep your Django applications neatly filed into a subfolder (such as apps/), first add the following to your settings.py:
import os
PROJECT_ROOT = os.path.dirname(__file__)
Then in manage.py:
Right under #!/usr/bin/env python add:
import sys
from os.path import abspath, dirname, join
from site import addsitedir
Right before if __name__ == "__main__": add:
sys.path.insert(0, join(settings.PROJECT_ROOT, "apps"))
Now to figure out what to do in production…
This is almost too easy. The only thing you need to do on top of what needs to be done for a Rails project is to add the following to a file called passenger_wsgi.py in the root folder of your project.
import os, sys
sys.path.append('/path/to/your/DjangoProjects')
os.environ['DJANGO_SETTINGS_MODULE'] = 'example_com.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
Then you create a basic virtual host configuration like you would for a PHP site:
<VirtualHost *:80>
ServerName example.com
DocumentRoot "/path/to/example_com/public/"
</VirtualHost>
I have yet to try this on a production server, but it works perfectly on my local machine. It even works with the Passenger preference pane!
This is primarily for making iPhone-only versions of an existing site/application.
<meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0" />
<!-- For iPhone: -->
<link media="only screen and (max-device-width: 480px)" href="small-device.css" type= "text/css" rel="stylesheet">
<!-- For everything else: -->
<link media="screen and (min-device-width: 481px)" href="not-small-device.css" type="text/css" rel="stylesheet">
html { -webkit-text-size-adjust: none; }
If you want your site/application to run in full screen mode (and separated from the normal mobile Safari) when running from a home screen shortcut, add this meta tag:
<meta name="apple-mobile-web-app-capable" content="yes">
Don’t forget to add a nice icon for people who bookmark your site on their home screens.
<link rel="apple-touch-icon" href="/img/touch_icon.png">
svn co http://django-hotclub.googlecode.com/svn/trunk/ [name_of_site]
cd [name_of_site]/projects
cp -R complete_project [name_of_project]
cd [name_of_project]
rm -rf `find . -type d -name .svn`
echo "ROOT_URLCONF = '[name_of_project].urls'" > localsettings.py
Now import the contents of [name_of_site]/projects/[name_of_project]/ into your choice of source code management systems and start developing your Pinax-based project. Put all new apps, templates, and media inside that folder. You can base your templates and media on the ones you copied when you duplicated the complete_project/ folder, or wipe them out and start from scratch.
When you’re ready to deploy, check here and here.
First, load some data via the admin that should always be there when someone installs the app.
Next, dump that data out into JSON format into a fixture:
./manage.py dumpdata [app_name] > [app_name]/fixtures/initial_data.json
Now whenever someone installs the app and runs syncdb, they’ll get that initial data loaded into their database.
sudo apt-get install libapache2-mod-wsgi
Virtual host configuration:
<VirtualHost *:80>
ServerAdmin you@example.com
ServerName example.com
DocumentRoot /home/you/public_html/example_com/public
# Django settings
WSGIScriptAlias / /home/you/public_html/example_com/wsgi_handler.py
WSGIDaemonProcess example_com user=you group=you processes=1 threads=10
WSGIProcessGroup example_com
# Non-Django directories
Alias /static /home/you/public_html/example_com/public/static/
<Location "/static">
SetHandler None
</Location>
</VirtualHost>
Put a file called wsgi_handler.py in your project folder:
import os, sys
sys.path.append(os.path.dirname(os.path.abspath(__file__)) + '/..')
os.environ['DJANGO_SETTINGS_MODULE'] = 'example_com.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
Create a repository on GitHub
Go into the Bundle Editor and drag your bundle to your desktop and cd into it in the terminal. This is the key to the whole thing. If you just go into the bundle where it lives in TextMate, you might not get everything it needs. Dragging the file to the desktop makes it a nice, happy package ready to help other people.
Follow GitHub’s instructions to set up and push to the remote repository. Don’t forget to git add . to get everything in there.
Delete your original bundle and then clone from GitHub like so:
cd ~/"Library/Application Support/TextMate/Bundles/"
git clone git://github.com/trey/trey-tmbundle.git "Trey.tmbundle"
osascript -e 'tell app "TextMate" to reload bundles'
When you make changes to your Git-ified bundle in the Bundle Editor, you’ll need to Reload Bundles for the changes to show up in your repository. Then you’ll need to git add . and commit / push as you would a normal repository.
If you write a blog whose primary purpose is to help people find and remember information (mostly myself in this case), then it’s probably a good idea to flag certain posts as out-of-date so as not to mislead people who are on a quest for knowledge. That is, of course, if you know it’s outdated. Maybe someone will tell you.
In any case, here’s how you can do it using Custom Fields in WordPress.
Find a post that’s out of date and edit it. Down towards the bottom of the page, there’s a section labeled Custom Fields, click it to open it, and enter something like this:
Use whatever name you want for the key and value, but be sure to change the related fields in the other places I’m about to mention.
I want the notice to show up on the post’s permalink page, so in single.php, I put this right after the start of ‘the loop’:
$status = get_post_meta($post->ID, 'status', true);
As you can probably guess, that just grabs the content for the ‘status’ key for the current post and stores it in the variable $status. Easy. If the post doesn’t have the value, the get_post_meta tag is nice enough to fail quietly (as far as I can tell).
Now that you have this very valuable information, you can change CSS, add a warning message, or whatever your little heart desires.
For example:
if ($status == 'outdated') include (TEMPLATEPATH . '/outdated.php');
This is so you can use something like /blog/ for a list of your blog entries, and the home page for a static page (or something fancier).
Under Settings > Reading > Posts page, pick the page template you want to use.
If you’re using a static page template for the home page, be sure not to name it home.php. Name it something like homepage.php and choose that template for the home page (you can still call it “Home” inside the template).
The “Posts page” will use index.php whether you like it or not. I couldn’t find a way to override that inside of Post management in WordPress.
Keep WordPress core files entirely separate from your content (themes, plugins, uploads).
There are a couple of ways to keep your WordPress install up-to-date. The easiest way is to install it as an svn:external. In the root of your (Subversioned) site:
svn propedit svn:externals .
Then paste in:
wordpress http://svn.automattic.com/wordpress/tags/[current_tag_number]
Replacing [current_tag_number] with the current tag number (check wordpress.org/download/ to see the latest). Alternately, you can just download WordPress and put it in a wordpress folder (or wp or whatever you prefer) in the root of your site.
Now copy the default wp-content folder from the fresh copy of WordPress to the root of your site:
cp -R wordpress/wp-content .
Delete the existing .svn folders from your fresh new wp-content.
cd wp-content
rm -rf `find . -type d -name .svn`
Now create your wp-config.php
cd ..
cp wordpress/wp-config-sample.php wp-config.php
Edit the file and add your database info. While you’re in there, add these settings to the top of the file:
// Custom wp-content folder:
define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/wp-content' );
define('WP_CONTENT_URL', 'http://' . $_SERVER['SERVER_NAME'] . '/wp-content');
define('WP_HOME', 'http://' . $_SERVER['SERVER_NAME'] . '');
define('WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/wordpress');
Those settings do a number of cool things. First, you’re allowing WordPress to use your fresh copy of wp-content in the root of your site instead of the one that lives inside of the wordpress folder. Second, you’re specifically setting some WordPress variables that are normally defined in its database in PHP, so that you won’t have to readjust your settings between development (on your local machine) and where it lives in the wild. Third, you’re telling WordPress where to find it’s core files since you’ve put them in a subfolder (/wordpress).
Now copy index.php from WordPress to the root of your site:
cp wordpress/index.php .
Edit the file and change the line that says:
require('./wp-blog-header.php');
To this:
require('./wordpress/wp-blog-header.php');
If you want fancy URLs (you do), create an .htaccess file:
touch .htaccess
chmod 666 .htaccess
Duplicate the default theme:
cp -R wp-content/themes/default wp-content/themes/[your_new_theme]
Replacing [your_new_theme] with what you want your new theme to be called.
cd wp-content/plugins/
rm -rf akismet
Or, if you’re already committed your code:
svn rm akismet
svn ci -m "Moving Akismet to external."
Then setup the external link:
svn propedit svn:externals .
Paste in:
akismet http://plugins.svn.wordpress.org/akismet/trunk/
Now commit your code and get to it. If you get lost, check out wp-template for an example.
svn propedit svn:externals .
Change the tag number, then svn update and you’re good to go.
If you’re not using svn:externals, just dump a new copy of WordPress over the one that’s already in /wordpress. There’s no way you can hurt your existing content, because that’s all in the /wp-content folder in the root of your site.