just to add my own experience. i was SettingNotSet CATEGORY_SLUG error, so I
tried to use the import product.config fix and get the following error. Now
I get the following.
[Fri Dec 11 15:24:13 2009] [error] [client XXX] mod_wsgi (pid=25171): Target
WSGI script '/home/XXX/XXX/buildout/bin/django.wsgi' cannot be loaded as
Python module.
[Fri Dec 11 15:24:13 2009] [error] [client 68.29.157.49] mod_wsgi
(pid=25171): SystemExit exception raised by WSGI script
'/home/XXX/XXX/buildout/bin/django.wsgi' ignored.
[Fri Dec 11 15:24:13 2009] [error] [client XXX] Traceback (most recent call
last):
[Fri Dec 11 15:24:13 2009] [error] [client XXX] File
"/home/XXX/XXX/buildout/bin/django.wsgi", line 42, in <module>
[Fri Dec 11 15:24:13 2009] [error] [client XXX] application =
djangorecipe.wsgi.main('bkco.settings', logfile='')
[Fri Dec 11 15:24:13 2009] [error] [client XXX] File
"/home/XXX/XXX/buildout/eggs/djangorecipe-0.20-py2.5.egg/djangorecipe/wsgi.py",
line 15, in main
[Fri Dec 11 15:24:13 2009] [error] [client XXX] sys.exit(1)
[Fri Dec 11 15:24:13 2009] [error] [client XXX] SystemExit: 1
On Sun, Dec 6, 2009 at 5:06 PM, ruckc <[email protected]> wrote:
> So this is a temporary solution... because i can't use manage.py if
> import product.config is in settings.py.
>
> Anyone found a longer term hack for a location to put import
> product.config at?
>
> On Nov 22, 7:16 pm, "Eric R. Palakovich Carr" <[email protected]>
> wrote:
> > I've been having the same problem and I've found a one-line hack that
> > doesn't touch the Satchmo source code. From what I can see, the
> > product.config module isn't being loaded in the same order as when you
> > run the development server. In fact, it isn't being loaded at all
> > before the exception is thrown and that is where the product settings
> > are loaded.
> >
> > So add this to your settings.py
> >
> > # HACK: FixesSettingNotSetCATEOGORY.SLUG exception that occurs on
> > production
> >
> > import product.config
> >
> > This resolves the issue, but it doesn't solve the root of the bug.
> > I'm new to deploying software using wsgi on Apache, what would be the
> > difference in loading modules between django's development server and
> > mod_wsgi?
> >
> > - Eric Palakovich Carr
> >
> > On Nov 19, 12:22 pm, davis <[email protected]> wrote:
> >
> > > If Gloria's fix solves it, then there must be something broken about
> > > the livesettings configuration module, because 'category' and
> > > 'product' are the default settings in product/config.py, and they
> > > should be returned if those two slugs aren't set in the livesettings
> > > table.
> >
> > > On Nov 3, 11:52 pm, Gloria W <[email protected]> wrote:
> >
> > > > My apprentice is playing with this, and he tried this solution, which
> > > > worked. His fix:
> >
> > > > "What I ended up doing was manually adding in the slug values (in the
> > > > form of an extra parameter that specified a default) that should
> > > > havebeen retrieved by the config_value call that was throwing the
> error.
> > > > Here are the changes I made to Satchmo's products/urls/__init__.py:
> >
> > > > # catbase = r'^' + config_value('PRODUCT','CATEGORY_SLUG') + '/'
> > > > catbase = r'^' + config_value('PRODUCT','CATEGORY_SLUG', 'category')
> + '/'
> > > > # prodbase = r'^' + config_value('PRODUCT','PRODUCT_SLUG') + '/'
> > > > prodbase = r'^' + config_value('PRODUCT','PRODUCT_SLUG', 'product') +
> '/'
> >
> > > > After those changes, test2.xxxxxxxxxx.com started working again"
> >
> > > > I am wondering why the slug values weren't there in the first place,
> but
> > > > I haven't had time to look at it just yet.
> >
> > > > Gloria
> >
> > > > > Interestingly enough, I just ran into a somewhat similar error as
> > > > > described in this thread -
> > > > >
> http://groups.google.com/group/satchmo-users/browse_thread/thread/989...
> >
> > > > > If I try the fix that Brian Tol proposes, I think it resolves my
> > > > > issue. It might fix yours. If it does, it would be interesting to
> see
> > > > > if that's the issue. Please let us know.
> >
> > > > > -Chris
> >
> > > > > On Tue, Nov 3, 2009 at 3:32 PM, Gloria W <[email protected]
> > > > > <mailto:[email protected]>> wrote:
> >
> > > > > Did you try running a standalone instance and hitting it
> directly:
> >
> > > > > python manage.py runserver 0.0.0.0:port_number
> >
> > > > > so you're eliminating memcache, apache, etc, and you can see if
> > > > > what you
> > > > > suspect, the cache, is the true problem?
> >
> > > > > Gloria
> > > > > > Anything solutions on this? Has anyone had definitive or even
> > > > > marginal
> > > > > > success eliminating the issue? So far, I've followed all
> suggestions
> > > > > > here (short of moving to another webserver -- gotta stick
> with
> > > > > Apache/
> > > > > > WSGI).
> >
> > > > > > I've been banging my head against the wall for almost a whole
> > > > > day, but
> > > > > > I can't get thatSettingNotSetException to budge.
> >
> > > > > > Tried multiple different caching setups. Also verified that
> > > > > everything
> > > > > > works running under shell and development server. I haven't a
> clue
> > > > > > what to change in my apache/wsgi configuration. ANY help
> would be
> > > > > > appreciated.
> >
> > > > > > Thanks,
> > > > > > Walter
> >
> > > > > > On Sep 16, 10:09 am, ruidc<[email protected]
> > > > > <mailto:[email protected]>> wrote:
> >
> > > > > >> We're using Apache 2.2.13 prefork MPM with mod_wsgi 3.0RC4
> in
> > > > > daemon
> > > > > >> mode.
> >
> > > > > >> We thought file cache was the issue as well, so switched to
> > > > > memcached
> > > > > >> via python-memcached with default settings, however this did
> not
> > > > > >> resolve the issue.
> >
> > > > > >> It's coming up on startup or on navigating to admin.
> >
> > > > > >> Are there any other suggestions?
> >
> > > > > >> I'd hate to move the server over to using Lighttpd or Nginx
> only to
> > > > > >> face the same problem there, but if that's the only
> suggestion,
> > > > > then i
> > > > > >> guess i'll investigate as this problem is a showstopper.
> >
> > > > > >> or is there a plan to make this section of the code more
> > > > > resilient to
> > > > > >> cache problems?
> >
> > > > > >> Regards,
> > > > > >> Rui
> >
> > > > > >> On Sep 16, 5:43 pm, Bruce Kroeze<[email protected]
> > > > > <mailto:[email protected]>> wrote:
> >
> > > > > >>> On Wed, Sep 16, 2009 at 6:50 AM, ruidc<
> [email protected]
> > > > > <mailto:[email protected]>> wrote:
> >
> > > > > >>>> We're also getting this same problem intermittently, with
> both
> > > > > >>>> filecache and memcache. We're using postgres as the
> database.
> >
> > > > > >>>> Corey, did you ever get to the bottom of this?
> > > > > >>>> Chris, can you offer any other suggestions?
> >
> > > > > >>> For some reason, when "things are messed up" in your store,
> > > > > the first
> > > > > >>> symptom seems to be the dreaded "SettingNotSet" disorder.
> >
> > > > > >>> In my experience with production sites, the answer is most
> > > > > likely one of these:
> > > > > >>> - You are using mod_python. Stop. Stop now. mod_python
> > > > > stinks. Use
> > > > > >>> mod_wsgi with Apache or preferably move to using Lighttpd
> or
> > > > > Nginx. I
> > > > > >>> have personally *never* seen a solid, stable, mod_python
> > > > > production
> > > > > >>> instance in the last two years.
> >
> > > > > >>> - Your cache is flaky. If you are using filecache, there
> could be
> > > > > >>> permissions issues.
> >
> > > > > >>> --
> > > > > >>> Bruce Kroezehttp://www.ecomsmith.com<
> http://www.ecomsmith.com>
> > > > > >>> It's time to hammer your site into shape.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Satchmo users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<satchmo-users%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/satchmo-users?hl=en.
>
>
>
--
Aleksandr Vladimirskiy
--
You received this message because you are subscribed to the Google Groups
"Satchmo users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/satchmo-users?hl=en.
