Re: broken image on my django production site. Why is it?

[Collin Anderson]

Hello,

You may need to install something like dj-static to serve your files.

Collin

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/16d1430f-b32f-4f3d-b12c-18e9920b4e69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: broken image on my django production site. Why is it?

[Kakar Nyori]

I think, you should add "static"/ in your html:



Or else change your directory settings.


On Sat, Nov 1, 2014 at 8:21 PM, rdyact <uunb2...@gmail.com> wrote:

>
> <https://lh5.googleusercontent.com/-FFtVl5q2M_s/VFTzY-YR7iI/Gyw/5ITM6qKL25Y/s1600/medialinkerror.png>
> I just product my site using Heroku and I got a odd problem with my media
> images broken. Here is my site structure on Heroku.
>
>  -- app
> -- manage.py
> -- mysite
>-- settings
>  -- __init__.py
>  -- base.py
>  -- production.py
> -- static
>-- media
>   -- product
> -- images
>   --
>-- static_dirs
>-- static_root
>
>
> In my app/mysite/settings/ *init*.py
>
> from .base import *try:
> from .local import *
> live = Falseexcept:
> live = Trueif live:
> from .production import *
>
> and in my base.py
>
> import os
> BASE_DIR = os.path.dirname(os.path.dirname(os.path.dirname(__file__)))
> STATIC_URL = '/static/'
> MEDIA_URL = '/media/'
> MEDIA_ROOT = os.path.join(BASE_DIR, 'static', 'media')
> STATIC_ROOT = os.path.join(BASE_DIR, 'static', 'static_root')
> STATICFILES_DIRS = (
> os.path.join(BASE_DIR, 'static', 'static_dirs'),)
> TEMPLATE_DIRS = (
> os.path.join(BASE_DIR, 'templates'),)
>
>
> and in my production.py, I annotated as below.
>
> # Static asset configuration# import os# BASE_DIR = 
> os.path.dirname(os.path.abspath(__file__))# STATIC_ROOT = 'staticfiles'# 
> STATIC_URL = '/static/'# STATICFILES_DIRS = (# os.path.join(BASE_DIR, 
> 'static'),# )
>
> Finally, I ran server and I got still broken image shown on my page. When
> I look the image carefully through "google inspect element",I can still see
> the probably right path as below.
>
> 
>
> But when I see my /static/media/products/images/ folder, there were images
> created on development statge only, not the images I just created on
> production site. (aws.png)
>
> As still beginner for django development, It is a tough to find answer
> even after few hour's googling.
>
> Thanks always.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/2f1eb33e-c1c0-417f-8665-b8f239540f4d%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/2f1eb33e-c1c0-417f-8665-b8f239540f4d%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2B8okoLAeWvJKPDYAGcLR7XYOMDT1CohqcZWEsek3PtbpZdzXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

broken image on my django production site. Why is it?

[rdyact]

<https://lh5.googleusercontent.com/-FFtVl5q2M_s/VFTzY-YR7iI/Gyw/5ITM6qKL25Y/s1600/medialinkerror.png>
I just product my site using Heroku and I got a odd problem with my media 
images broken. Here is my site structure on Heroku.

 -- app
-- manage.py
-- mysite
   -- settings
 -- __init__.py
 -- base.py
 -- production.py
-- static
   -- media
  -- product
-- images
  -- 
   -- static_dirs
   -- static_root


In my app/mysite/settings/ *init*.py

from .base import *try:
from .local import *
live = Falseexcept:
live = Trueif live:
from .production import *

and in my base.py

import os
BASE_DIR = os.path.dirname(os.path.dirname(os.path.dirname(__file__)))
STATIC_URL = '/static/'
MEDIA_URL = '/media/'
MEDIA_ROOT = os.path.join(BASE_DIR, 'static', 'media')
STATIC_ROOT = os.path.join(BASE_DIR, 'static', 'static_root')
STATICFILES_DIRS = (
os.path.join(BASE_DIR, 'static', 'static_dirs'),)
TEMPLATE_DIRS = (
os.path.join(BASE_DIR, 'templates'),)


and in my production.py, I annotated as below.

# Static asset configuration# import os# BASE_DIR = 
os.path.dirname(os.path.abspath(__file__))# STATIC_ROOT = 'staticfiles'# 
STATIC_URL = '/static/'# STATICFILES_DIRS = (# os.path.join(BASE_DIR, 
'static'),# )

Finally, I ran server and I got still broken image shown on my page. When I 
look the image carefully through "google inspect element",I can still see 
the probably right path as below.



But when I see my /static/media/products/images/ folder, there were images 
created on development statge only, not the images I just created on 
production site. (aws.png)

As still beginner for django development, It is a tough to find answer even 
after few hour's googling.

Thanks always.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2f1eb33e-c1c0-417f-8665-b8f239540f4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: readonly unittests for production site

[Thomas Guettler]

Benjamin Reitzammer wrote:
> Hi Thomas,
> how did you make sure, that the tests are read-only? Did you apply any
> special measures/tricks (like using a special DJANGO_SETTINGS_MODULE,
> that has read-ony access to the database), or are your tests read-only
> by convention and you trust the developer that he/she does the
> RightThing?

Hi,

yes, I trust me and my co workers.

But I have a "allways rollback" decorator, too. But unittest writers
need to use it explicitly. It is not applied automatically.

But you are right. Maybe the unittest should redefine methods
which modify the DB, that an exception gets raised.

And there are some other features: Call all views, except views
which have the attribute 'no_readoly_test' with a pseudo GET request.

I run this script nightly and after updates.

  Thomas


-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

-- 
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.

Re: readonly unittests for production site

[Benjamin Reitzammer]

Hi Thomas,
how did you make sure, that the tests are read-only? Did you apply any
special measures/tricks (like using a special DJANGO_SETTINGS_MODULE,
that has read-ony access to the database), or are your tests read-only
by convention and you trust the developer that he/she does the
RightThing?

Cheers

Benjamin



On Thu, Apr 15, 2010 at 10:10, Thomas Guettler  wrote:
> Hi,
>
> I use django since several months and wrote a lot of
> readonly unittests that I run on live systems.
>
> I think Django has only a infrastructure for test
> which use a temporary database.
>
> I am happy with my solution, but it would be nice
> to have the "infrastructure" in django itself.
>
>  - A page to list and start the unittests from a webpage
>   (Start one, start all of an application, ...)
>
>  - Start the unittest from the shell:
>   list all unittests, start one, start all of an application.
>
> Anyone else interested?
>
>  Thomas
>
> --
> Thomas Guettler, http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
>
> --
> 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.
>
>

-- 
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.

readonly unittests for production site

[Thomas Guettler]

Hi,

I use django since several months and wrote a lot of
readonly unittests that I run on live systems.

I think Django has only a infrastructure for test
which use a temporary database.

I am happy with my solution, but it would be nice
to have the "infrastructure" in django itself.

 - A page to list and start the unittests from a webpage
   (Start one, start all of an application, ...)

 - Start the unittest from the shell:
   list all unittests, start one, start all of an application.

Anyone else interested?

 Thomas

-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

-- 
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.

Production site.

[Massimiliano Bertinetti]

Hi all,

I finally put my first, little django site in production. This was my
first work in django after several php site (cake, zend, joomla, magento
and so on...).

I take a VPS Hosting with Ubuntu 9.10 64 bit - the same linux distro I
use for work and try to put in production the site with apache -
mod_python. For the db (since I host a cms with flatpage for the moment)
I use sqlite3.

The problem was that when I put the project onto the server my config
for serving media, admin_media and tiny_mce initially don't function,
until I create in settings.py a couple of constant with absolute path.

Now all work, but I want to learn how to use continuos integration and
having different machine to host my DBs (MySQL or PostgresSQL),
Mercurial repositories and CI server and staging and production site in
a consistent way, when my work grow.so, what can I post to you for
let me know what was eventually wrong with my configuration?

Thanks in advance!

Max-B 

-- 
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.

Re: best practices for a production site

[D. Hayes]

Be sure and check out SVNMerge: http://www.orcaware.com/svn/wiki/Svnmerge.py

It's a little Python script that helps ease the pain of merging. It's
superfantastic. ( =

On Jan 20, 7:59 pm, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> On 20-Jan-08, at 2:06 PM, Andrew wrote:
>
> > This also may be a good time to consider a distributed version control
> > system (Like bazaar or mercurial)... we're just about to finish
> > porting to bazaar after running up to several situations just like
> > yours.
>
> > One benefit of DVCS is that branching is easier than SVN...making
> > feature-level branches easier to intergrate into your workflow.
>
> yes - I had my first experience of branching under svn and it was  
> harrowing - some files just refused to get transferred to the branch
>
> --
>
> regards
> kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/web/
> Foss Conference for the common man:http://registration.fossconf.in/web/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: best practices for a production site

[Kenneth Gonsalves]

On 20-Jan-08, at 2:06 PM, Andrew wrote:

> This also may be a good time to consider a distributed version control
> system (Like bazaar or mercurial)... we're just about to finish
> porting to bazaar after running up to several situations just like
> yours.
>
> One benefit of DVCS is that branching is easier than SVN...making
> feature-level branches easier to intergrate into your workflow.

yes - I had my first experience of branching under svn and it was  
harrowing - some files just refused to get transferred to the branch

-- 

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Foss Conference for the common man: http://registration.fossconf.in/web/



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

Re: best practices for a production site

[Tim Chase]

> This also may be a good time to consider a distributed version control
> system (Like bazaar or mercurial)... we're just about to finish
> porting to bazaar after running up to several situations just like
> yours.

I second this suggestion.  Mercurial is currently at the top of
my pick-list for its speed and mental model.  I like Bazaar for
its mental model and it's focus on correctness, but it's still a
bit slow for my old home machine (once they resolve this, I
suspect I'll shift to Bazaar).  Some folks swear by Git, but I
don't fully grasp the mental model to make the best use of it,
and it's a bit of a second-class citizen on Win32.  For yet
others, it's Darcs but I don't know much about it.

Mercurial and Bazaar also have the added benefit of being written
in Python like Django so if I had to hack a VCS or use its
libraries from within Django, it would be a bit easier.

> One benefit of DVCS is that branching is easier than SVN...making
> feature-level branches easier to intergrate into your workflow.

Bah...branching in SVN is easy...it's the repeatedly merging
those branches back together that becomes a pain :)  (At least
until they add merge-tracking features which are the horizon, but
not yet released).

-tim






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

Re: best practices for a production site

[Andrew]

This also may be a good time to consider a distributed version control
system (Like bazaar or mercurial)... we're just about to finish
porting to bazaar after running up to several situations just like
yours.

One benefit of DVCS is that branching is easier than SVN...making
feature-level branches easier to intergrate into your workflow.

Good luck!

On Jan 17, 11:55 pm, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> hi,
>
> I have a site in production and being developed at the same time - a
> common django usecase I am sure. This is the first time I am
> developing a site with a team comprised of several remote
> contributors also. My previous teams were all in the same lab.
> Currently everyone with commit rights commits code to the repository.
> I test it out on the setup on my local box, and if satisfactory do an
> svn up on the server and restart apache. The problem is that there
> are two types of changes in code - one is new features and the other
> is minor changes. With the current setup, minor changes have to wait
> until the new features are tested out. So even a spelling mistake has
> to wait until whatever is already committed is tested and accepted.
> At the same time, the new features do not really justify setting up
> separate branches. So what would be the best way out of this?
> --
>
> regards
> kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/web/
> Foss Conference for the common man:http://registration.fossconf.in/web/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: best practices for a production site

[Ned Batchelder]

Updating to just a particular revision may work, but it is very easy for 
the trunk to get into a state where it would be hard to pick out just 
the fixes by updating specific files to specific revisions.  This is 
labor intensive and confusing, and therefore error prone.

Other people in this thread have suggested branches for the fixes, 
rather than branches for the features, and I agree with them. It works 
very well to use branches this way, since the minority of trunk checkins 
will have to be merged onto the fixes branch, most of your development 
is simple a checkin-to-the-trunk model.  Only when you have a fix that 
needs to leapfrog ahead of the feature work do you need to merge anything.

--Ned.
http://nedbatchelder.com

Kenneth Gonsalves wrote:
> On 18-Jan-08, at 9:54 PM, William Siegrist wrote:
>
>   
>> If the spelling changes are in 1 file, and the new feature is in  
>> another file, can't you "svn update" just the spelling change file  
>> and not the new feature file? And if they are in the same file, I  
>> think the --revision option to svn update might also help.
>> 
>
> I am an idiot - why didnt I think of that?
>
>   


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

Re: best practices for a production site

[Kenneth Gonsalves]

On 18-Jan-08, at 9:54 PM, William Siegrist wrote:

> If the spelling changes are in 1 file, and the new feature is in  
> another file, can't you "svn update" just the spelling change file  
> and not the new feature file? And if they are in the same file, I  
> think the --revision option to svn update might also help.

I am an idiot - why didnt I think of that?

-- 

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Foss Conference for the common man: http://registration.fossconf.in/web/



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

Re: best practices for a production site

[Rajesh Dhawan]

Hi Kenneth,

> I have a site in production and being developed at the same time - a
> common django usecase I am sure. This is the first time I am
> developing a site with a team comprised of several remote
> contributors also. My previous teams were all in the same lab.
> Currently everyone with commit rights commits code to the repository.
> I test it out on the setup on my local box, and if satisfactory do an
> svn up on the server and restart apache. The problem is that there
> are two types of changes in code - one is new features and the other
> is minor changes. With the current setup, minor changes have to wait
> until the new features are tested out. So even a spelling mistake has
> to wait until whatever is already committed is tested and accepted.
> At the same time, the new features do not really justify setting up
> separate branches. So what would be the best way out of this?
> --

Branching and merging will actually make your life easy. This is a
standard usecase for it.

Just for example:

/trunk -> Keep the latest/bleeding-edge/unstable development code here

/branches/production -> Keep your current production code here (your
production server would be upgraded by "svn up" from this branch)

/versions/v-2008-Jan-15
/versions/v-2007-Dec-09
-> Keep a snapshot of each production release here with a dated
version number

Encourage your development team to make small frequent commits of
related code rather than one big commit with all kinds of mixed fixes
and features (all of this trunk, of course.)

When you need to deploy a set of minor fixes to production, keep
merging such fixes into /branches/production. Be sure to test /
branches/production any time you merge in fixes or features into it.
And any time /branches/production gets svn updated to your production
server, snapshot it to /versions/v--mmm-dd for historical records
(or if you need to revert back to an older production release for any
reason.)

If you have serious features/refactoring work going on, it's extremely
useful to do all of that in dedicated branches (think newforms-admin,
queryset-refactor, ...) and merge them to trunk later.

Good luck!

-Rajesh D

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

Re: best practices for a production site

[William Siegrist]

If the spelling changes are in 1 file, and the new feature is in  
another file, can't you "svn update" just the spelling change file and  
not the new feature file? And if they are in the same file, I think  
the --revision option to svn update might also help.


-Bill


On Jan 17, 2008, at 11:55 PM, Kenneth Gonsalves wrote:



hi,

I have a site in production and being developed at the same time - a
common django usecase I am sure. This is the first time I am
developing a site with a team comprised of several remote
contributors also. My previous teams were all in the same lab.
Currently everyone with commit rights commits code to the repository.
I test it out on the setup on my local box, and if satisfactory do an
svn up on the server and restart apache. The problem is that there
are two types of changes in code - one is new features and the other
is minor changes. With the current setup, minor changes have to wait
until the new features are tested out. So even a spelling mistake has
to wait until whatever is already committed is tested and accepted.
At the same time, the new features do not really justify setting up
separate branches. So what would be the best way out of this?
--

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Foss Conference for the common man: http://registration.fossconf.in/web/



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google  
Groups "Django users" group.

To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---












smime.p7s
Description: S/MIME cryptographic signature

Re: best practices for a production site

[Marcin Mierzejewski]

Hi Kenneth,

I have very similar situation in my projects (some our projects, we
develop 4 version in the same time - client specific versions).
We do it in this way (we are using SVN):
/trunk/ <- latest version
/branches/product-1.0
/branches/product-1.1
/branches/product-1.2
/tags/product-1.0.0
/tags/product-1.0.1
/tags/product-1.0.2

New feature development is in /trunk/ and maintenance (bugfixing for
old version) are made directly on branches (1.0, 1.1).
And if we have a bug in version 1.0, when we checkout source code from
brunch /branches/product-1.0 and after fix, we build version 1.0.3
(tag + installation package for client).
After bug fixing, we merge this bugfix to trunk.

Regards,
Marcin

--
http://www.zenzire.com





On Jan 18, 8:55 am, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> hi,
>
> I have a site in production and being developed at the same time - a
> common django usecase I am sure. This is the first time I am
> developing a site with a team comprised of several remote
> contributors also. My previous teams were all in the same lab.
> Currently everyone with commit rights commits code to the repository.
> I test it out on the setup on my local box, and if satisfactory do an
> svn up on the server and restart apache. The problem is that there
> are two types of changes in code - one is new features and the other
> is minor changes. With the current setup, minor changes have to wait
> until the new features are tested out. So even a spelling mistake has
> to wait until whatever is already committed is tested and accepted.
> At the same time, the new features do not really justify setting up
> separate branches. So what would be the best way out of this?
> --
>
> regards
> kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/web/
> Foss Conference for the common man:http://registration.fossconf.in/web/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

best practices for a production site

[Kenneth Gonsalves]

hi,

I have a site in production and being developed at the same time - a  
common django usecase I am sure. This is the first time I am  
developing a site with a team comprised of several remote  
contributors also. My previous teams were all in the same lab.  
Currently everyone with commit rights commits code to the repository.  
I test it out on the setup on my local box, and if satisfactory do an  
svn up on the server and restart apache. The problem is that there  
are two types of changes in code - one is new features and the other  
is minor changes. With the current setup, minor changes have to wait  
until the new features are tested out. So even a spelling mistake has  
to wait until whatever is already committed is tested and accepted.  
At the same time, the new features do not really justify setting up  
separate branches. So what would be the best way out of this?
-- 

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Foss Conference for the common man: http://registration.fossconf.in/web/



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

Re: Debugging production site.

[Merric Mercer]

Just what I was looking for - many thanks

MerMer

Matt McClanahan wrote:
> On Aug 13, 2:11 pm, Merric Mercer <[EMAIL PROTECTED]> wrote:
>
>   
>> Is there anyway to trap the debug information - so it is logged - but
>> not visible to users?
>> 
>
> A good starting point is to use the ADMINS setting, which will give
> you a way to receive error reports via e-mail when debugging is off:
>
> http://www.djangoproject.com/documentation/settings/#admins
>
> Matt
>
>
> >
>
>   


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

Re: Debugging production site.

[Deryck Hodge]

On 8/13/07, TheMaTrIx <[EMAIL PROTECTED]> wrote:
>
> Any idea why ADMINS would fail to send out the debug or 404 PNF mails
> while your apps are sending email perfectly with the settings you put
> in your settings.py for SMTP auth?

Did you set your SERVER_EMAIL setting in addition to the EMAIL_HOST,
etc. settings?  If so, I'd open the Python interpreter and try to run
django.core.mail.mail_admins manually to see what errors.  If not
obviously errors, start looking through server logs.

Cheers,
deryck

-- 
Deryck Hodge
Lead Developer, Product Development
Washington Post.Newsweek Interactive

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

Re: Debugging production site.

[Matt McClanahan]

On Aug 13, 2:11 pm, Merric Mercer <[EMAIL PROTECTED]> wrote:

> Is there anyway to trap the debug information - so it is logged - but
> not visible to users?

A good starting point is to use the ADMINS setting, which will give
you a way to receive error reports via e-mail when debugging is off:

http://www.djangoproject.com/documentation/settings/#admins

Matt


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

Debugging production site.

[Merric Mercer]

I'm very occasionally getting errors reported to me on our production 
site by our members.   However,  we cannot replicate the problem ourself 
and because debugging is turned off the members are not giving me any 
real clues.

Is there anyway to trap the debug information - so it is logged - but 
not visible to users?

Many thanks

MerMer

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

Re: Error In the production site

[James Bennett]

On 5/4/07, Grupo Django <[EMAIL PROTECTED]> wrote:
> Hello, I get very often an error from modpython, and I have no idea
> about what I should check, does anybody know it?

You're seeing this particular traceback because an internal error
occurred and you don't have a template for displaying the "internal
server error" message -- when DEBUG is True, Django does this on the
fly for you to display the traceback, but when DEBUG is False you must
create a template named '500.html' to display on an internal error
(called '500.html', because 500 is the HTTP status code for an
internal server error). If you look at the traceback you'll see a line
which says "You need to create a 500.html template", and the final
line is telling you Django could not find that template.

As for the error which started the whole sequence of events, if you've
configured the ADMINS setting and the settings for Django to send
email, then Django will email a traceback of the original error (the
one which happened before the non-existent '500.html' got in the way)
to everyone listed in ADMINS.

-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

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

Production site management

[chasfs]

I'm looking for some scripts to help manage  Django based
applications on a production site.  Stuff like:
-backing up and restoring the DB, code, media, html, etc.
-promoting a test site to production
-demoting a production site to the previous version

Any recommendations?

Thanks!
-chasfs
http://zdecisions.com


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

Best way to run dev and production site concurrently on same server? (take 2)

[argus]

Found this thread on the same topic
http://groups.google.com/group/django-users/browse_frm/thread/7a2d69fa8748ba68
..but it got closed.

I want to do the same things as the OP in that thread:
> I've recently completed a first milestone of a project and want to
> publish it.  I've got two URLs: www.mydomain.com and dev.mydomain.com.
> I'm not too concerned if dev is public, I just don't want to break the
> production website while I'm developing.
>
> What's the best way to handle this?

The difference between what I'm trying to do and the OP in that thread
is (apparently) that I've got different databases for each subdomain.
The problem I'm having is that the www domain is using the settings for
the test domain, and ends up pulling from its database.  At this point,
I can't tell if I'm having an apache config problem, a mod_python
directive problem, or a django problem.

The relevant portions of my two vhost definitions:


  ServerName test.mysite.com
  
### setup django stuff
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
SetHandler python-program
PythonHandler django.core.handlers.modpython
PythonAutoReload On
PythonDebug On
PythonPath "['/home/django-code/test.mysite.com/'] + sys.path"
PythonInterpreter mysite-test
  



  ServerName mysite.com
  ServerAlias www.mysite.com
  
### setup django stuff
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
SetHandler python-program
PythonHandler django.core.handlers.modpython
PythonDebug Off
PythonPath "['/home/django-code/www.mysite.com/'] + sys.path"
PythonInterpreter mysite-www
  


www settings file: /home/django-code/www.mysite.com/mysite/settings.py
test settings file:
/home/django-code/test.mysite.com/mysite/settings.py
PYTHONPATH doesn't contain any references to either (only base Python
components & locations)

I've double-checked each settings.py file and verified that the DB info
is in fact different, so it's nothing that obvious (at least to me).  I
suspect that my issue isn't Django related at all, but I couldn't be
sure.  I didn't *think* that the sites angle (as covered in the
original thread) was relevant to my situation, since I've got
completely separate databases for each.  Any pointers?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Best way to run dev and production site concurrently on same server?

[Ian Holsman]

oh.. you might also want to have a different pythoninterpreter
add the following to your virtual hosts.
PythonInterpreter xxx_prod
and
PythonInterpreter xxx_dev

On 19/05/2006, at 8:20 AM, Rob Hudson wrote:

>
> I've recently completed a first milestone of a project and want to
> publish it.  I've got two URLs: www.mydomain.com and dev.mydomain.com.
> I'm not too concerned if dev is public, I just don't want to break the
> production website while I'm developing.
>
> What's the best way to handle this?
>
> Currently I only have the dev website -- the current production  
> website
> is static HTML.
>
> I was thinking the dev site could have it's own path separate from the
> production website.  The dev website is checked out from subversion as
> the trunk and the production is checked out from tags.
>
> Based on my virtual hosts, can I have the production site list:
> SetEnv DJANGO_SETTINGS_MODULE website.settings
> and the dev site list:
> SetEnv DJANGO_SETTINGS_MODULE website_dev.settings
> and everything work?
>
> Is there something more I need to consider?  Is anyone else doing
> something similar?
>
> Thanks,
> Rob
>
>
> >

X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.54.68.11 with SMTP id q11mr156202wra;
Sat, 20 May 2006 15:50:18 -0700 (PDT)
Return-Path: <[EMAIL PROTECTED]>
Received: from circe.holsman.net (218-214-209-234.people.net.au 
[218.214.209.234])
by mx.googlegroups.com with ESMTP id v23si497102cwb.2006.05.20.15.50.16;
Sat, 20 May 2006 15:50:18 -0700 (PDT)
Received-SPF: neutral (googlegroups.com: 218.214.209.234 is neither permitted 
nor denied by domain of [EMAIL PROTECTED])
Received: from [127.0.0.1] (localhost [127.0.0.1])
by circe.holsman.net (Postfix) with ESMTP id C20B01C5D8C
for <django-users@googlegroups.com>; Sun, 21 May 2006 08:50:04 +1000 
(EST)
Mime-Version: 1.0
Content-Type: text/plain
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
From: Ian Holsman <[EMAIL PROTECTED]>
Subject: Re: Best way to run dev and production site concurrently on same 
server?
Date: Sun, 21 May 2006 08:50:03 +1000
To: django-users@googlegroups.com
X-Mailer: Apple Mail (2.750)

oh.. you might also want to have a different pythoninterpreter
add the following to your virtual hosts.
PythonInterpreter xxx_prod
and
PythonInterpreter xxx_dev

On 19/05/2006, at 8:20 AM, Rob Hudson wrote:

>
> I've recently completed a first milestone of a project and want to
> publish it.  I've got two URLs: www.mydomain.com and dev.mydomain.com.
> I'm not too concerned if dev is public, I just don't want to break the
> production website while I'm developing.
>
> What's the best way to handle this?
>
> Currently I only have the dev website -- the current production  
> website
> is static HTML.
>
> I was thinking the dev site could have it's own path separate from the
> production website.  The dev website is checked out from subversion as
> the trunk and the production is checked out from tags.
>
> Based on my virtual hosts, can I have the production site list:
> SetEnv DJANGO_SETTINGS_MODULE website.settings
> and the dev site list:
> SetEnv DJANGO_SETTINGS_MODULE website_dev.settings
> and everything work?
>
> Is there something more I need to consider?  Is anyone else doing
> something similar?
>
> Thanks,
> Rob
>
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Best way to run dev and production site concurrently on same server?

[Ian Holsman]

to use the Sites you may find the following useful.

class SiteLimitManager(models.Manager):
 def get_query_set(self):
 return super(SiteLimitManager, self).get_query_set().filter 
(site=settings.SITE_ID)

and in your model add:
 site = models.ForeignKey(Site, default=settings.SITE_ID,  
blank=True)
 objects = SiteLimitManager()

 def save(self):
 self.site = settings.SITE_ID
 self.site_id = settings.SITE_ID
 super(XXXMODELNAMEXXX, self).save()


this should make the production/dev thing pretty transparent to the  
rest of your application, and allow you to share common things like  
user-id's across both.

regards
Ian

On 21/05/2006, at 2:30 AM, Luke Plant wrote:

>
> On Thursday 18 May 2006 23:20, Rob Hudson wrote:
>
>> Based on my virtual hosts, can I have the production site list:
>> SetEnv DJANGO_SETTINGS_MODULE website.settings
>> and the dev site list:
>> SetEnv DJANGO_SETTINGS_MODULE website_dev.settings
>> and everything work?
>>
>> Is there something more I need to consider?  Is anyone else doing
>> something similar?
>
> You may have to consider the 'Sites' objects.  So far, I have only  
> come
> across these are used internally only for creating URLs in the RSS/ 
> Atom
> framework.  I think this can be taken care of by creating the  
> necessary
> Site objects and setting the SITE_ID option correctly in your settings
> files.  Other than that I can't see any problems.
>
> Luke
>
> -- 
> Parenthetical remarks (however relevant) are unnecessary
>
> Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
> X-Google-Language: ENGLISH,UTF8
> Received: by 10.54.68.15 with SMTP id q15mr149925wra;
> Sat, 20 May 2006 09:31:04 -0700 (PDT)
> Return-Path: <[EMAIL PROTECTED]>
> Received: from out3.smtp.messagingengine.com  
> (out3.smtp.messagingengine.com [66.111.4.27])
> by mx.googlegroups.com with ESMTP id v11si417440cwb. 
> 2006.05.20.09.31.02;
> Sat, 20 May 2006 09:31:04 -0700 (PDT)
> Received-SPF: neutral (googlegroups.com: 66.111.4.27 is neither  
> permitted nor denied by best guess record for domain of L.Plant. 
> [EMAIL PROTECTED])
> Received: from frontend3.internal (frontend3.internal [10.202.2.152])
>   by frontend1.messagingengine.com (Postfix) with ESMTP id 589FDD62E61
>   for <django-users@googlegroups.com>; Sat, 20 May 2006 12:31:01  
> -0400 (EDT)
> Received: from heartbeat1.messagingengine.com ([10.202.2.160])
>   by frontend3.internal (MEProxy); Sat, 20 May 2006 12:31:02 -0400
> X-Sasl-enc: TOvXyHl5eKU8anYn8+yXqXov7e647JzvglcJ1SItoDTP 1148142661
> Received: from calvin  
> (host86-141-27-140.range86-141.btcentralplus.com [86.141.27.140])
>   by mail.messagingengine.com (Postfix) with ESMTP id B0B15132E
>   for <django-users@googlegroups.com>; Sat, 20 May 2006 12:31:01  
> -0400 (EDT)
> From: Luke Plant <[EMAIL PROTECTED]>
> To: django-users@googlegroups.com
> Subject: Re: Best way to run dev and production site concurrently  
> on same server?
> Date: Sat, 20 May 2006 17:30:30 +0100
> User-Agent: KMail/1.8.3
> References: <[EMAIL PROTECTED]>
> In-Reply-To: <[EMAIL PROTECTED]>
> X-Face: "N27'AmvBWpdTowy8j|{(HM:g:In+;[nNrbEv6"_B>#oJW=()=?utf-8?q? 
> g=2EtC=3BI9=7CDrpPnB=3Ff=242=5B9V=0A=09?="eYjDWVW 
> [PFOJj5zbG1mZm>y3P^"$Fl)(=?utf-8?q?=3Fx=5E4/ 
> rPd4SMJX=7C53PpvkyMk=5F=5CmSl=24oK=25nZf3D=0A=09d=7EK+c?=
>  =?utf-8?q?f=60wDl!q=27P4JNu=5FI=25V0!l=3D1D?="]WrI4~ZZK!-|5T% Mime-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Message-Id: <[EMAIL PROTECTED]>
>
> On Thursday 18 May 2006 23:20, Rob Hudson wrote:
>
>> Based on my virtual hosts, can I have the production site list:
>> SetEnv DJANGO_SETTINGS_MODULE website.settings
>> and the dev site list:
>> SetEnv DJANGO_SETTINGS_MODULE website_dev.settings
>> and everything work?
>>
>> Is there something more I need to consider?  Is anyone else doing
>> something similar?
>
> You may have to consider the 'Sites' objects.  So far, I have only  
> come
> across these are used internally only for creating URLs in the RSS/ 
> Atom
> framework.  I think this can be taken care of by creating the  
> necessary
> Site objects and setting the SITE_ID option correctly in your settings
> files.  Other than that I can't see any problems.
>
> Luke
>
> -- 
> Parenthetical remarks (however relevant) are unnecessary
>
> Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Best way to run dev and production site concurrently on same server?

[Luke Plant]

On Thursday 18 May 2006 23:20, Rob Hudson wrote:

> Based on my virtual hosts, can I have the production site list:
> SetEnv DJANGO_SETTINGS_MODULE website.settings
> and the dev site list:
> SetEnv DJANGO_SETTINGS_MODULE website_dev.settings
> and everything work?
>
> Is there something more I need to consider?  Is anyone else doing
> something similar?

You may have to consider the 'Sites' objects.  So far, I have only come 
across these are used internally only for creating URLs in the RSS/Atom 
framework.  I think this can be taken care of by creating the necessary 
Site objects and setting the SITE_ID option correctly in your settings 
files.  Other than that I can't see any problems.

Luke

-- 
Parenthetical remarks (however relevant) are unnecessary

Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
X-Google-Language: ENGLISH,UTF8
Received: by 10.54.68.15 with SMTP id q15mr149925wra;
Sat, 20 May 2006 09:31:04 -0700 (PDT)
Return-Path: <[EMAIL PROTECTED]>
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com 
[66.111.4.27])
by mx.googlegroups.com with ESMTP id v11si417440cwb.2006.05.20.09.31.02;
Sat, 20 May 2006 09:31:04 -0700 (PDT)
Received-SPF: neutral (googlegroups.com: 66.111.4.27 is neither permitted nor 
denied by best guess record for domain of [EMAIL PROTECTED])
Received: from frontend3.internal (frontend3.internal [10.202.2.152])
by frontend1.messagingengine.com (Postfix) with ESMTP id 589FDD62E61
for <django-users@googlegroups.com>; Sat, 20 May 2006 12:31:01 -0400 
(EDT)
Received: from heartbeat1.messagingengine.com ([10.202.2.160])
  by frontend3.internal (MEProxy); Sat, 20 May 2006 12:31:02 -0400
X-Sasl-enc: TOvXyHl5eKU8anYn8+yXqXov7e647JzvglcJ1SItoDTP 1148142661
Received: from calvin (host86-141-27-140.range86-141.btcentralplus.com 
[86.141.27.140])
by mail.messagingengine.com (Postfix) with ESMTP id B0B15132E
for <django-users@googlegroups.com>; Sat, 20 May 2006 12:31:01 -0400 
(EDT)
From: Luke Plant <[EMAIL PROTECTED]>
To: django-users@googlegroups.com
Subject: Re: Best way to run dev and production site concurrently on same 
server?
Date: Sat, 20 May 2006 17:30:30 +0100
User-Agent: KMail/1.8.3
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
X-Face: 
"N27'AmvBWpdTowy8j|{(HM:g:In+;[nNrbEv6"_B>#oJW=()=?utf-8?q?g=2EtC=3BI9=7CDrpPnB=3Ff=242=5B9V=0A=09?="eYjDWVW[PFOJj5zbG1mZm>y3P^"$Fl)(=?utf-8?q?=3Fx=5E4/rPd4SMJX=7C53PpvkyMk=5F=5CmSl=24oK=25nZf3D=0A=09d=7EK+c?=
 =?utf-8?q?f=60wDl!q=27P4JNu=5FI=25V0!l=3D1D?="]WrI4~ZZK!-|5T%

On Thursday 18 May 2006 23:20, Rob Hudson wrote:

> Based on my virtual hosts, can I have the production site list:
> SetEnv DJANGO_SETTINGS_MODULE website.settings
> and the dev site list:
> SetEnv DJANGO_SETTINGS_MODULE website_dev.settings
> and everything work?
>
> Is there something more I need to consider?  Is anyone else doing
> something similar?

You may have to consider the 'Sites' objects.  So far, I have only come 
across these are used internally only for creating URLs in the RSS/Atom 
framework.  I think this can be taken care of by creating the necessary 
Site objects and setting the SITE_ID option correctly in your settings 
files.  Other than that I can't see any problems.

Luke

-- 
Parenthetical remarks (however relevant) are unnecessary

Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---