[Django] #16388: django unittest bug

[Django]

#16388: django unittest bug
+---
 Reporter:  freewave@…  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Testing framework
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+---
 enviroment: python2.7 + django1.3
 with the steps below:
 1、 django-admin.py startproject myapp
 2、 cd myapp
 3、 manage.py startapp foo
 4、 manage.py test

 error occurs:
 File "C:\Python27\lib\site-packages\django\test\simple.py", line 237, in
 setup_test_environment
 unittest.installHandler()
 AttributeError:'module' object has no attribute 'installHandler'


 problem?:
 the file “site-packages\django\utils\unittest” contains the code
 try:
 # check the system path first
 from unittest2 import *
 except ImportError:
 if sys.version_info >= (2,7):
 # unittest2 features are native in Python 2.7
 from unittest import *
 else:
 ...

 but unittest2 features are native in Python 2.7?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6904: Dictsort filter should sort case insensitive

[Django]

#6904: Dictsort filter should sort case insensitive
-+-
   Reporter:  michael@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Template system
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  0
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by anonymous):

 * ui_ux:   => 0
 * easy:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #4848: Feature Proposal: Allowing inline fields to be specified in the fields tuple (newforms-admin)

[Django]

#4848: Feature Proposal: Allowing inline fields to be specified in the fields
tuple (newforms-admin)
-+-
   Reporter:  leifbyron  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  newforms-  |   Keywords:  nfa-someday
  admin  |  newforms-admin inline models fields
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ckesselh):

 * cc: ckesselh (added)
 * ui_ux:   => 0
 * easy:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10938: add inlines into fieldsets

[Django]

#10938: add inlines into fieldsets
---+---
   Reporter:  ctao |  Owner:  aaugustin
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  inlines fieldsets
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  1|
---+---
Changes (by ckesselh):

 * cc: ckesselh (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16375: PEP 0263 for generated project and apps

[Django]

#16375: PEP 0263 for generated project and apps
-+-
   Reporter:  wildfire   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  UTF8
 Resolution:  wontfix|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 Since the templates don't contain non-ASCII characters, they don't need
 this header.

 Django assumes developers know Python; if they don't, they should read a
 Python tutorial first.

 Given that I'm the second person here to think it isn't a good idea, I
 will close the ticket.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
-+-
   Reporter:  russellm   |  Owner:  kkubasik
   Type:  New| Status:  new
  feature|  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  feature test models
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by kmike):

 * cc: kmike84@… (added)
 * ui_ux:   => 0
 * easy:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #8013: Localflavor for Colombia and Ecuador

[Django]

#8013: Localflavor for Colombia and Ecuador
-+-
   Reporter:  ikks   |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  Colombia Ecuador
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by BernhardEssl):

 * needs_better_patch:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #8013: Localflavor for Colombia and Ecuador

[Django]

#8013: Localflavor for Colombia and Ecuador
-+-
   Reporter:  ikks   |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  Colombia Ecuador
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by BernhardEssl):

 * version:   => SVN
 * needs_tests:  1 => 0


Comment:

 I updated the original patch with ISO keys and wrote tests.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16161: If extra static files are added into STATIC_ROOT, they are transformed to symlinks in the next run of ``collectstatic -l``

[Django]

#16161: If extra static files are added into STATIC_ROOT, they are transformed 
to
symlinks in the next run of ``collectstatic -l``
+-
   Reporter:  gnotaras  |  Owner:  aaugustin
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.staticfiles
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-

Comment (by jezdez):

 Another item for the TODO list Jacob mentioned on IRC:

 - change the collectstatic warning message to say something like "This
 will overwrite existing files in /home/jacob/myproj/static - are you
 sure"? (i.e. actually show STATIC_ROOT there)

 Since collectstatic uses the storage backend specified as
 `STATICFILES_STORAGE`, `STATIC_ROOT` might not be used at all. In that
 case checking if the storage backend is an instance of `FileSystemStorage`
 does the trick. IOW, only show STATIC_ROOT if there is a good chance that
 the storage actually uses it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16387: Localizing Fails

[Django]

#16387: Localizing Fails
-+
   Reporter:  konzept@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  GIS
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
Changes (by jezdez):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Yeah, looks like this needs a bit of `unlocalize`.
 https://docs.djangoproject.com/en/dev/topics/i18n/localization/#unlocalize

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16161: If extra static files are added into STATIC_ROOT, they are transformed to symlinks in the next run of ``collectstatic -l``

[Django]

#16161: If extra static files are added into STATIC_ROOT, they are transformed 
to
symlinks in the next run of ``collectstatic -l``
+-
   Reporter:  gnotaras  |  Owner:  aaugustin
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.staticfiles
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-

Comment (by jezdez):

 Having thought more about the issue Luke was mentioning, I don't believe I
 agree that his is an actual problem. In fact I might want old files (such
 as pre-compressed stylesheet files) to stay in `STATIC_ROOT` to make sure
 users with cached pages or templates referring to those files don't break.
 In any case, I believe that the simplest way of "fixing" the issue Luke
 mentioned is to simply to delete `STATIC_ROOT` manually, because Django
 can't really forsee whether the files should stay around or not.

 That actually makes me wonder if the simplest solution would be:

 - add a ``--clear`` option that would try to delete the content of
 `STATIC_ROOT` if the user wishes, with the downside of having to wait
 **much** longer for collecstatic to run
 - fix the linking support to actually check if the to be symlinked file
 doesn't actually have the same name as the link

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16387: Localizing Fails

[Django]

#16387: Localizing Fails
---+
 Reporter:  konzept@…  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  GIS
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+
 Setting {{{default_lon}}} and {{{default_lat}}} fails on {{{LANGUAGE_CODE
 = 'de-de'}}} because the JS
 
(https://code.djangoproject.com/browser/django/trunk/django/contrib/gis/templates/gis/admin/openlayers.js)
 localizes in line #71 and #140 the default values from {{{1164288.77309}}}
 to {{{1164288,77309}}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16161: If extra static files are added into STATIC_ROOT, they are transformed to symlinks in the next run of ``collectstatic -l``

[Django]

#16161: If extra static files are added into STATIC_ROOT, they are transformed 
to
symlinks in the next run of ``collectstatic -l``
+-
   Reporter:  gnotaras  |  Owner:  aaugustin
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.staticfiles
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by jezdez):

 * ui_ux:   => 0


Comment:

 Replying to [comment:16 kmtracey]:
 > I don't see deleting (or renaming) a file in source static trees to be
 at all the same thing as having added a file to the the target tree. The
 first is something that is a natural part of development, the 2nd is a
 should-not-do (unless it's done by another automated step that is always
 run after collectstatic). Requiring devs to remember that "oh, I
 deleted/renamed a static file, I need to do something special for deploy
 to work properly next time" is a recipe for disaster. I would have
 expected collectstatic to start out by deleting the old target tree, so as
 to ensure that what it produces correctly mirrors what is now in the
 source trees, with no stale leftover files. What's the rationale for NOT
 doing this?
 The rationale is simple: not having to copy/link all static files again on
 each run. It can take quite a while to run collectstatic on a medium to
 big Django site.

 > It seems to me it's what is needed in order to correctly support
 deleting/renaming source static files during development. Yes, it will
 blow away any files that have been somehow added into the static target
 tree after collectstatic finished the last time, but I see that as a
 should-not-do anyway, so I don't really understand why breaking things if
 that has been done is a bad thing.

 collectstatic tries to be smart about **adding** files to `STATIC_ROOT` by
 comparing the modification_time of the files it tries to copy/link, to be
 quicker, but I don't see a good way to check that a file is to be removed.
 E.g. how could we differ a file that is located in `STATIC_ROOT` but can't
 be found in one of the locations staticfiles collects files from?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16492 - in django/branches/releases/1.3.X/docs: howto howto/deployment ref/contrib/admin

[noreply]

Author: jezdez
Date: 2011-07-01 08:19:34 -0700 (Fri, 01 Jul 2011)
New Revision: 16492

Modified:
   django/branches/releases/1.3.X/docs/howto/deployment/modpython.txt
   django/branches/releases/1.3.X/docs/howto/deployment/modwsgi.txt
   django/branches/releases/1.3.X/docs/howto/static-files.txt
   django/branches/releases/1.3.X/docs/ref/contrib/admin/index.txt
Log:
[1.3.X] Fixed #15974 -- Correctly link to static files handling in deployment 
docs. Thanks, RogueBean.

Backport from trunk (r16491).

Modified: django/branches/releases/1.3.X/docs/howto/deployment/modpython.txt
===
--- django/branches/releases/1.3.X/docs/howto/deployment/modpython.txt  
2011-07-01 15:18:42 UTC (rev 16491)
+++ django/branches/releases/1.3.X/docs/howto/deployment/modpython.txt  
2011-07-01 15:19:34 UTC (rev 16492)
@@ -246,9 +246,9 @@
 * A stripped-down version of Apache_
 * Cherokee_
 
-If, however, you have no option but to serve media files on the same Apache
-``VirtualHost`` as Django, here's how you can turn off mod_python for a
-particular part of the site::
+If, however, you have no option but to serve media or static files on the
+same Apache ``VirtualHost`` as Django, here's how you can turn off mod_python
+for a particular part of the site::
 
 
 SetHandler None
@@ -257,9 +257,9 @@
 Just change ``Location`` to the root URL of your media files. You can also use
  to match a regular expression.
 
-This example sets up Django at the site root but explicitly disables Django for
-the ``media`` subdirectory and any URL that ends with ``.jpg``, ``.gif`` or
-``.png``::
+This example sets up Django at the site root but explicitly disables Django
+for the ``media`` and ``static`` subdirectories and any URL that ends with
+``.jpg``, ``.gif`` or ``.png``::
 
 
 SetHandler python-program
@@ -271,11 +271,14 @@
 SetHandler None
 
 
+
+SetHandler None
+
+
 
 SetHandler None
 
 
-
 .. _lighttpd: http://www.lighttpd.net/
 .. _Nginx: http://wiki.nginx.org/Main
 .. _TUX: http://en.wikipedia.org/wiki/TUX_web_server
@@ -285,22 +288,21 @@
 Serving the admin files
 ===
 
-Note that the Django development server automagically serves admin media files,
-but this is not the case when you use any other server arrangement. You're
-responsible for setting up Apache, or whichever media server you're using, to
-serve the admin files.
+Note that the Django development server automagically serves the static files
+of the admin app, but this is not the case when you use any other server
+arrangement. You're responsible for setting up Apache, or whichever media
+server you're using, to serve the admin files.
 
-The admin files live in (:file:`django/contrib/admin/media`) of the Django
-distribution.
+The admin files live in (:file:`django/contrib/admin/static/admin`) of the
+Django distribution.
 
-Here are two recommended approaches:
+We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle
+the admin files, but here are two other approaches:
 
-1. Create a symbolic link to the admin media files from within your
-   document root. This way, all of your Django-related files -- code 
**and**
-   templates -- stay in one place, and you'll still be able to ``svn
-   update`` your code to get the latest admin templates, if they change.
+1. Create a symbolic link to the admin static files from within your
+   document root.
 
-2. Or, copy the admin media files so that they live within your Apache
+2. Or, copy the admin static files so that they live within your Apache
document root.
 
 Using "eggs" with mod_python

Modified: django/branches/releases/1.3.X/docs/howto/deployment/modwsgi.txt
===
--- django/branches/releases/1.3.X/docs/howto/deployment/modwsgi.txt
2011-07-01 15:18:42 UTC (rev 16491)
+++ django/branches/releases/1.3.X/docs/howto/deployment/modwsgi.txt
2011-07-01 15:19:34 UTC (rev 16492)
@@ -55,12 +55,12 @@
 replace 'mysite.settings' with your correct settings file, and 
'/path/to/mysite'
 with your own project's location.
 
-.. _serving-media-files:
+.. _serving-files:
 
-Serving media files
-===
+Serving files
+=
 
-Django doesn't serve media files itself; it leaves that job to whichever Web
+Django doesn't serve files itself; it leaves that job to whichever Web
 server you choose.
 
 We recommend using a separate Web server -- i.e., one that's not also running
@@ -76,22 +76,29 @@
 ``VirtualHost`` as Django, you can set up Apache to serve some URLs as
 static media, and others using the mod_wsgi interface to Django.
 
-This example sets up Django at the site root, but explicitly serves 
``robots.txt``,
-``favicon.ico``, any CSS file, and anything in the ``/media/`` URL space as a 
static
-file. All other URLs will be served using

Re: [Django] #15974: docs: deployment/modwsgi: Link to static files howto missing

[Django]

#15974: docs: deployment/modwsgi: Link to static files howto missing
-+-
   Reporter:  django-|  Owner:  RogueBean
  trac.10.snej@… | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by jezdez):

 In [16492]:
 {{{
 #!CommitTicketReference repository="" revision="16492"
 [1.3.X] Fixed #15974 -- Correctly link to static files handling in
 deployment docs. Thanks, RogueBean.

 Backport from trunk (r16491).
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15974: docs: deployment/modwsgi: Link to static files howto missing

[Django]

#15974: docs: deployment/modwsgi: Link to static files howto missing
-+-
   Reporter:  django-|  Owner:  RogueBean
  trac.10.snej@… | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [16491]:
 {{{
 #!CommitTicketReference repository="" revision="16491"
 Fixed #15974 -- Correctly link to static files handling in deployment
 docs. Thanks, RogueBean.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16491 - in django/trunk/docs: howto howto/deployment ref/contrib/admin

[noreply]

Author: jezdez
Date: 2011-07-01 08:18:42 -0700 (Fri, 01 Jul 2011)
New Revision: 16491

Modified:
   django/trunk/docs/howto/deployment/modpython.txt
   django/trunk/docs/howto/deployment/modwsgi.txt
   django/trunk/docs/howto/static-files.txt
   django/trunk/docs/ref/contrib/admin/index.txt
Log:
Fixed #15974 -- Correctly link to static files handling in deployment docs. 
Thanks, RogueBean.

Modified: django/trunk/docs/howto/deployment/modpython.txt
===
--- django/trunk/docs/howto/deployment/modpython.txt2011-07-01 15:18:34 UTC 
(rev 16490)
+++ django/trunk/docs/howto/deployment/modpython.txt2011-07-01 15:18:42 UTC 
(rev 16491)
@@ -246,9 +246,9 @@
 * A stripped-down version of Apache_
 * Cherokee_
 
-If, however, you have no option but to serve media files on the same Apache
-``VirtualHost`` as Django, here's how you can turn off mod_python for a
-particular part of the site::
+If, however, you have no option but to serve media or static files on the
+same Apache ``VirtualHost`` as Django, here's how you can turn off mod_python
+for a particular part of the site::
 
 
 SetHandler None
@@ -257,9 +257,9 @@
 Just change ``Location`` to the root URL of your media files. You can also use
  to match a regular expression.
 
-This example sets up Django at the site root but explicitly disables Django for
-the ``media`` subdirectory and any URL that ends with ``.jpg``, ``.gif`` or
-``.png``::
+This example sets up Django at the site root but explicitly disables Django
+for the ``media`` and ``static`` subdirectories and any URL that ends with
+``.jpg``, ``.gif`` or ``.png``::
 
 
 SetHandler python-program
@@ -271,11 +271,14 @@
 SetHandler None
 
 
+
+SetHandler None
+
+
 
 SetHandler None
 
 
-
 .. _lighttpd: http://www.lighttpd.net/
 .. _Nginx: http://wiki.nginx.org/Main
 .. _TUX: http://en.wikipedia.org/wiki/TUX_web_server
@@ -285,22 +288,21 @@
 Serving the admin files
 ===
 
-Note that the Django development server automagically serves admin media files,
-but this is not the case when you use any other server arrangement. You're
-responsible for setting up Apache, or whichever media server you're using, to
-serve the admin files.
+Note that the Django development server automagically serves the static files
+of the admin app, but this is not the case when you use any other server
+arrangement. You're responsible for setting up Apache, or whichever media
+server you're using, to serve the admin files.
 
-The admin files live in (:file:`django/contrib/admin/media`) of the Django
-distribution.
+The admin files live in (:file:`django/contrib/admin/static/admin`) of the
+Django distribution.
 
-Here are two recommended approaches:
+We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle
+the admin files, but here are two other approaches:
 
-1. Create a symbolic link to the admin media files from within your
-   document root. This way, all of your Django-related files -- code 
**and**
-   templates -- stay in one place, and you'll still be able to ``svn
-   update`` your code to get the latest admin templates, if they change.
+1. Create a symbolic link to the admin static files from within your
+   document root.
 
-2. Or, copy the admin media files so that they live within your Apache
+2. Or, copy the admin static files so that they live within your Apache
document root.
 
 Using "eggs" with mod_python

Modified: django/trunk/docs/howto/deployment/modwsgi.txt
===
--- django/trunk/docs/howto/deployment/modwsgi.txt  2011-07-01 15:18:34 UTC 
(rev 16490)
+++ django/trunk/docs/howto/deployment/modwsgi.txt  2011-07-01 15:18:42 UTC 
(rev 16491)
@@ -55,12 +55,12 @@
 replace 'mysite.settings' with your correct settings file, and 
'/path/to/mysite'
 with your own project's location.
 
-.. _serving-media-files:
+.. _serving-files:
 
-Serving media files
-===
+Serving files
+=
 
-Django doesn't serve media files itself; it leaves that job to whichever Web
+Django doesn't serve files itself; it leaves that job to whichever Web
 server you choose.
 
 We recommend using a separate Web server -- i.e., one that's not also running
@@ -76,22 +76,29 @@
 ``VirtualHost`` as Django, you can set up Apache to serve some URLs as
 static media, and others using the mod_wsgi interface to Django.
 
-This example sets up Django at the site root, but explicitly serves 
``robots.txt``,
-``favicon.ico``, any CSS file, and anything in the ``/media/`` URL space as a 
static
-file. All other URLs will be served using mod_wsgi::
+This example sets up Django at the site root, but explicitly serves
+``robots.txt``, ``favicon.ico``, any CSS file, and anything in the
+``/static/`` and ``/media/`` URL space as a static file. All 

[Changeset] r16490 - django/trunk

[noreply]

Author: jezdez
Date: 2011-07-01 08:18:34 -0700 (Fri, 01 Jul 2011)
New Revision: 16490

Modified:
   django/trunk/MANIFEST.in
Log:
Fixed the manifest template to correctly ship admin's static files.

Modified: django/trunk/MANIFEST.in
===
--- django/trunk/MANIFEST.in2011-07-01 15:18:27 UTC (rev 16489)
+++ django/trunk/MANIFEST.in2011-07-01 15:18:34 UTC (rev 16490)
@@ -14,7 +14,7 @@
 recursive-include django/conf/locale *
 recursive-include django/contrib/*/locale *
 recursive-include django/contrib/admin/templates *
-recursive-include django/contrib/admin/media *
+recursive-include django/contrib/admin/static *
 recursive-include django/contrib/admindocs/templates *
 recursive-include django/contrib/auth/fixtures *
 recursive-include django/contrib/auth/templates *

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15077: Error in documentation for running Django on a shared-hosting provider with Apache

[Django]

#15077: Error in documentation for running Django on a shared-hosting provider 
with
Apache
-+-
   Reporter:  MarkusH|  Owner:  Horst Gutmann
   Type:  Bug|  
  Milestone: | Status:  closed
Version:  1.2|  Component:  Documentation
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:  htaccess, dceu2011
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by jezdez):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [16489]:
 {{{
 #!CommitTicketReference repository="" revision="16489"
 Fixed #15077 -- Clarified FastCGI documentation with regard to shared
 hosting providers. Thanks, Horst Gutmann.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16489 - django/trunk/docs/howto/deployment

[noreply]

Author: jezdez
Date: 2011-07-01 08:18:27 -0700 (Fri, 01 Jul 2011)
New Revision: 16489

Modified:
   django/trunk/docs/howto/deployment/fastcgi.txt
Log:
Fixed #15077 -- Clarified FastCGI documentation with regard to shared hosting 
providers. Thanks, Horst Gutmann.

Modified: django/trunk/docs/howto/deployment/fastcgi.txt
===
--- django/trunk/docs/howto/deployment/fastcgi.txt  2011-06-30 09:19:16 UTC 
(rev 16488)
+++ django/trunk/docs/howto/deployment/fastcgi.txt  2011-07-01 15:18:27 UTC 
(rev 16489)
@@ -225,6 +225,23 @@
 Django will automatically use the pre-rewrite version of the URL when
 constructing URLs with the ``{% url %}`` template tag (and similar methods).
 
+Using mod_fcgid as alternative to mod_fastcgi
+--
+
+Another way to serve applications through FastCGI is by using Apache's
+`mod_fcgid`_ module. Compared to mod_fastcgi mod_fcgid handles FastCGI
+applications differently in that it manages the spawning of worker processes
+by itself and doesn't offer something like ``FastCGIExternalServer``. This
+means that the configuration looks slightly different.
+
+In effect, you have to go the way of adding a script handler similar to what
+is described later on regarding running Django in a :ref:`shared-hosting
+environment `. For further details please refer to the
+`mod_fcgid reference`_
+
+.. _mod_fcgid: http://httpd.apache.org/mod_fcgid/
+.. _mod_Fcgid reference: http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
+
 lighttpd setup
 ==
 
@@ -306,6 +323,8 @@
 
 .. _setting up Django: http://www.cherokee-project.com/doc/cookbook_django.html
 
+.. _apache_shared_hosting:
+
 Running Django on a shared-hosting provider with Apache
 ===
 
@@ -349,6 +368,18 @@
 from django.core.servers.fastcgi import runfastcgi
 runfastcgi(method="threaded", daemonize="false")
 
+This works if your server uses mod_fastcgi. If, on the other hand, you are
+using mod_fcgid the setup is mostly the same except for a slight change in the
+``.htaccess`` file. Instead of adding a fastcgi-script handler, you have to
+add a fcgid-handler:
+
+.. code-block:: apache
+
+AddHandler fcgid-script .fcgi
+RewriteEngine On
+RewriteCond %{REQUEST_FILENAME} !-f
+RewriteRule ^(.*)$ mysite.fcgi/$1 [QSA,L]
+
 Restarting the spawned server
 -
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16360: Add a standard entrypoint for WSGI to project template

[Django]

#16360: Add a standard entrypoint for WSGI to project template
---+--
   Reporter:  jezdez   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  Core (Other)
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+--

Comment (by jezdez):

 #12091 is definitely out of the scope of this ticket. The attached patch
 only extends the already existing support for WSGI to be easier to combine
 with other WSGI components.

 #8927 and #12075 cover other parts of the stack that wouldn't be touched
 by this ticket in any case. In other words, those tickets can happen even
 if this ticket is applied.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16386: Handle subclasses in signal dispatcher

[Django]

#16386: Handle subclasses in signal dispatcher
-+--
 Reporter:  patrys   |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Core (Other)
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+--
 Currently the signal dispatcher stores just the identity of the passed
 object instead. Because of that the `_live_receivers` method can only
 perform equality tests. The result is that the moment you use Python
 inheritance for models, the signals stop working.

 You can work around that by setting sender to `None` but it adds a bit of
 an overhead due to the fact that your handler is called for each and every
 object and there are places where you can't change how signals are
 connected (like the generic relations).

 Therefore I propose modifying the `_make_id` function a bit so when passed
 a type (class) or a list/tuple of types it returns it verbatim without
 identity casting. Then `_live_receivers` could test for `issubclass`
 dealing with classes.

 While this would technically result in a different behavior from what
 Django 1.3 does, I doubt it would be a problem. I don't think there are
 many cases when you want a signal from a base class but not from
 subclasses and the few remaining uses can manually test for that in the
 handler.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
   Reporter:  jacob  |  Owner:  konk
   Type:  New| Status:  assigned
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version: |   Severity:  Normal
 Resolution: |   Keywords:  database
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by davidhalter88@…):

 * cc: davidhalter88@… (added)
 * ui_ux:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16368: Custom sites model overridden by contrib.sites.model.Site

[Django]

#16368: Custom sites model overridden by contrib.sites.model.Site
-+-
   Reporter: |  Owner:  nobody
  briehan.lombaard@… | Status:  new
   Type:  Bug|  Component:  contrib.sites
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by briehan.lombaard@…):

 I just did a  {{{patch -uR}}}  which as I understand it reverts the
 changes from r14563.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16368: Custom sites model overridden by contrib.sites.model.Site

[Django]

#16368: Custom sites model overridden by contrib.sites.model.Site
-+-
   Reporter: |  Owner:  nobody
  briehan.lombaard@… | Status:  new
   Type:  Bug|  Component:  contrib.sites
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by BernhardEssl):

 Strange on trunk it works fine for me without the changes in r14563. Did
 you undoing the changes from r14563 or patching the files with r14563?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16382: WizardView: Incorrect step numbering

[Django]

#16382: WizardView: Incorrect step numbering
-+---
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.formtools
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by BernhardEssl):

 * has_patch:  0 => 1


Comment:

 added a patch for the doc.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16368: Custom sites model overridden by contrib.sites.model.Site

[Django]

#16368: Custom sites model overridden by contrib.sites.model.Site
-+-
   Reporter: |  Owner:  nobody
  briehan.lombaard@… | Status:  new
   Type:  Bug|  Component:  contrib.sites
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by briehan.lombaard@…):

 Applying the patches from r14563 on a working copy of 1.3 does not fix the
 issue for me. I tried on trunk as well and that seems to leave the code in
 a broken state.

 For what it is worth when I rename my 'sites' app to something else the
 problem goes away. If I'm not allowed to have a Django app called 'sites'
 (even when I'm not using django.contrib.sites) then surely Django needs to
 enforce that somehow instead of allowing me to do so and then trampling
 all over my imports.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16382: WizardView: Incorrect step numbering

[Django]

#16382: WizardView: Incorrect step numbering
-+---
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.formtools
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by jezdez):

 * stage:  Unreviewed => Accepted


Comment:

 This seems like a doc bug, should be using something like:

 {{{
 Step {{ wizard.steps.step1 }} of {{ wizard.steps.count }}
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16283: manage.py depends on django.contrib.contenttypes et al.

[Django]

#16283: manage.py depends on django.contrib.contenttypes et al.
+--
   Reporter:  TheRoSS   |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.auth
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--

Comment (by jezdez):

 I could see the validate command calling a specific hook in the app
 classes (e.g. a `validate` method) once the app-loading branch lands.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16385: NoSQL support

[Django]

#16385: NoSQL support
-+-
   Reporter:  jonash |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version: |   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 Please don't dump a bunch of patches to Trac but create separate ones for
 each feature. Don't hesitate to add a "nosql" keyword or something similar
 to the tickets to be able to group them.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.