Re: broken image on my django production site. Why is it?
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?
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 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&utm_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?
<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
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
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
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.
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
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
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
> 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
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
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
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
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
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
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
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.
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.
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.
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? On Aug 14, 12:03 am, Matt McClanahan <[EMAIL PROTECTED]> 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.
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.
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
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 -~--~~~~--~~--~--~---
Re: Error In the production site
I think it is because there is an error in the view, it happens suddenly. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Error In the production site
Hello, I get very often an error from modpython, and I have no idea about what I should check, does anybody know it? Here is the output: Mod_python error: "PythonHandler django.core.handlers.modpython" Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/usr/lib/python2.4/site-packages/django/core/handlers/ modpython.py", line 177, in handler return ModPythonHandler()(req) File "/usr/lib/python2.4/site-packages/django/core/handlers/ modpython.py", line 150, in __call__ response = self.get_response(request) File "/usr/lib/python2.4/site-packages/django/core/handlers/ base.py", line 126, in get_response return callback(request, **param_dict) File "/usr/lib/python2.4/site-packages/django/views/defaults.py", line 88, in server_error t = loader.get_template(template_name) # You need to create a 500.html template. File "/usr/lib/python2.4/site-packages/django/template/loader.py", line 79, in get_template source, origin = find_template_source(template_name) File "/usr/lib/python2.4/site-packages/django/template/loader.py", line 72, in find_template_source raise TemplateDoesNotExist, name TemplateDoesNotExist: 500.html --~--~-~--~~~---~--~~ 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
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)
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?
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 ; 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?
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 ; 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 ; 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&a7~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?
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 ; 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 ; 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&a7~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
-~--~~~~--~~--~--~---
Best way to run dev and production site concurrently on same server?
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 -~--~~~~--~~--~--~---
