Graham ...
I appreciate the criticism -- I had to build for both mod_python and
mod_wsgi and there was some bleed through.
- Craig -
On Wed, Dec 15, 2010 at 17:11, Graham Dumpleton
<graham.dumple...@gmail.com>wrote:
>
>
> On Wednesday, December 15, 2010 11:10:06 PM UTC+11, Craig Trader wrote:
>
>> Here's how I solved this problem for my own applications. Note that I use
>> VirtualEnv to ensure that each application gets exactly the Python
>> environment I want it to have. If you don't use VirtualEnv, it will make
>> the WSGI startup script simpler. Assume that my application is installed
>> with the following layout:
>>
>> /data/web/foo/ -- base directory for foo (and the root of a VirtualEnv
>> environment)
>> bin/ -- VirtualEnv scripts, including 'python' symlink
>> lib/ -- Python libraries, including Django
>> apache/apache.wsgi -- Apache WSGI startup script
>> site/foo -- where the Foo site is installed (containing applications
>> like bar, baz, etc.)
>> site/foo/static -- where static content is stored
>>
>> First, the Apache virtual host configuration:
>>
>> <VirtualHost *:80>
>> ServerName foo.example.com
>> ServerAdmin f...@example.com
>>
>> ServerSignature email
>>
>> LogLevel debug
>>
>> WSGIProcessGroup foo
>> WSGIDaemonProcess foo processes=2 threads=5 home=/data/web/foo
>> display-name=foo
>>
>> DocumentRoot /var/www
>>
>> WSGIScriptAlias / /data/web/foo/apache/django.wsgi
>> <Directory /data/web/foo/apache>
>> Order allow,deny
>> Allow from all
>> </Directory>
>>
>> Alias /static/ /data/web/foo/site/foo/static/
>> <Directory /data/web/foo/site/foo/static/>
>> SetHandler None
>>
>
> Don't need this SetHandler directive. That was need for mod_python but not
> with mod_wsgi.
>
>
>> Order allow,deny
>> Allow from all
>> </Directory>
>> </VirtualHost>
>>
>> And now the WSGI startup script (most of this is just to make VirtualEnv
>> work):
>>
>> import os, sys, site
>>
>> here = os.path.abspath( os.curdir )
>>
>
> From here:
>
>
>>
>> ALLDIRS = [
>> os.path.join( here, 'site' ),
>> os.path.join( here, 'lib', 'python2.6', 'site-packages' ),
>> ]
>>
>> # Remember original sys.path.
>> prev_sys_path = list(sys.path)
>>
>> # Add each new site-packages directory.
>> for directory in ALLDIRS:
>> site.addsitedir(directory)
>>
>> # Reorder sys.path so new directories at the front.
>> new_sys_path = []
>> for item in list(sys.path):
>> if item not in prev_sys_path:
>> new_sys_path.append(item)
>> sys.path.remove(item)
>> sys.path[:0] = new_sys_path
>>
>
> to here, should be able to be simplified to:
>
> activate = os.path.join(here, 'bin', 'activate_this.py')
> execfile(activate, dict(__file__=activate))
>
> sys.path.insert(0, os.path.join(here, 'site'))
>
> I no longer object to the activate_this.py script even though it modifies
> sys.prefix. Although technically that could be problematic, hasn't shown
> itself to be in practice.
>
> Graham
>
>
>>
>> os.environ['DJANGO_SETTINGS_MODULE'] = 'foo.settings'
>>
>> import django.core.handlers.wsgi
>> application = django.core.handlers.wsgi.WSGIHandler()
>>
>> In my settings.py file, I have the following:
>>
>> import os, sys
>>
>> SITEDIR = os.path.dirname( os.path.dirname( os.path.abspath( __file__ ) )
>> )
>>
>> MEDIA_ROOT = os.path.join( SITEDIR, 'foo', 'static' )
>> MEDIA_URL = '/static/'
>> ADMIN_MEDIA_PREFIX = '/media/'
>>
>> ROOT_URLCONF = 'foo.urls'
>>
>> TEMPLATE_DIRS = (
>> os.path.join( SITEDIR, 'foo', 'templates' ),
>> )
>>
>> INSTALLED_APPS = (
>> 'django.contrib.auth',
>> 'django.contrib.contenttypes',
>> 'django.contrib.sessions',
>> 'django.contrib.sites',
>> 'django.contrib.messages',
>> 'django.contrib.admin',
>> 'foo.bar',
>> 'foo.baz',
>> )
>>
>> My urls.py file looks like this:
>>
>> from django.conf import settings
>> from django.conf.urls.defaults import *
>> from django.contrib import admin
>> from django.shortcuts import render_to_response
>>
>> # Uncomment the next two lines to enable the admin:
>> admin.autodiscover()
>>
>> def home( *args, **options ):
>> return render_to_response( 'index.html' )
>>
>> urlpatterns = patterns( '',
>> url( r'^$', home, name='site_index' ),
>> ( r'^admin/', include( admin.site.urls ) ),
>> ( r'^foo include( 'stackexchange.foo.urls' ) ),
>> ( r'^bar include( 'stackexchange.bar.urls' ) ),
>> ( r'^static/(?P<path>.*)$', 'django.views.static.serve',
>> {'document_root': settings.MEDIA_ROOT } ),
>> )
>>
>> You only need the 'static' definition for when you're testing using
>> 'runserver'; Apache intercepts all of the /static/ URLs before Django sees
>> them in production.
>>
>> I hope this helps.
>>
>> - Craig -
>>
>> On Wed, Dec 15, 2010 at 03:17, NoviceSortOf <dljons...@gmail.com> wrote:
>>
>>> On Dec 15, 8:08 am, mongoose <darren...@gmail.com> wrote:
>>> > > I'm trying to run projects on the back of it. For examplehttp://
>>> baseurl.com/mongoose/
>>> > > The projects run but the URL don't work properly because they all
>>> > > reference the base url. So for 'About Me' page it points tohttp://
>>> baseurl.com/aboutinsteadofhttp://baseurl.com/mongoose/about
>>> >
>>> > > Is this something i need to change in django or apache? Is what I'm
>>> > > trying to do even possible?
>>>
>>> I wrestled with something like this - as we needed a static homepage
>>> based on a django backend for one site.
>>>
>>> Per my recollection what I did was.
>>>
>>> * Apache httpd.conf required a location match adjustment something
>>> like.
>>>
>>> <LocationMatch "\.(jpg|gif|png|php|html)$">
>>> SetHandler None
>>> </LocationMatch>
>>>
>>> * My url.py file needed this line
>>> (r'^$', direct_to_template,{'template': 'index.html'}),
>>>
>>> * As well I landed up having to put the index.html into both
>>> full static form in the .com root as well in the django template
>>> folder.
>>> This was neccesary so people could load into the site as
>>> "www.somewhere.com"
>>> and while once in the django backend
>>> "www.somewhere.com/index.html" would load for further
>>> navigating.
>>>
>>> I hope that makes sense, there was a downside to this in that
>>> our web provider Verio's site management front end does not work
>>> with us resetting the SetHandler in the root. In any case
>>> most management of this site is done on the command line level.
>>>
>>> Not a perfect solution but one that works, I'm open for other
>>> suggestions.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django users" group.
>>> To post to this group, send email to django...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> django-users...@googlegroups.com.
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/group/django-users?hl=en.
>>>
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
