SettingNotSet at / on server, but works in shell

[Corey Oordt]

Hey everyone,

I'm pulling my hair out at this. I'm getting an error that 'PRODUCT',
'CATEGORY_SLUG' is not set.

Environment:

Request Method: GET
Request URL: https://store.washingtontimes.com/settings/
Django Version: 1.1
Python Version: 2.5.2
Installed Applications:
['django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.admin',
'django.contrib.flatpages',
'django.contrib.humanize',
'django.contrib.redirects',
'django_ext',
'django_memcached',
'pagination',
'south',
'django_extensions',
'accounts',
'satchmo_store.shop',
'registration',
'keyedcache',
'livesettings',
'l10n',
'sorl.thumbnail',
'satchmo_store.contact',
'tax',
'tax.modules.no',
'tax.modules.area',
'tax.modules.percent',
'shipping',
'product',
'payment',
'payment.modules.giftcertificate',
'paypal_payflow_pro',
'satchmo_utils',
'app_plugins',
'satchmo_ext.recentlist',
'celery',
'newsworthy']
Installed Middleware:
('middleware.SecureMiddleware',
'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.http.SetRemoteAddrFromForwardedFor',
'django.middleware.gzip.GZipMiddleware',
'django.middleware.http.ConditionalGetMiddleware',
'django.middleware.doc.XViewMiddleware',
'django.contrib.redirects.middleware.RedirectFallbackMiddleware',
'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware',
'django.middleware.transaction.TransactionMiddleware',
'threaded_multihost.middleware.ThreadLocalMiddleware',
'pagination.middleware.PaginationMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware')


Traceback:
File "/home/webdev/.virtualenvs/twtstore/lib/python2.5/site-packages/
django/core/handlers/base.py" in get_response
83. request.path_info)
File "/home/webdev/.virtualenvs/twtstore/lib/python2.5/site-packages/
django/core/urlresolvers.py" in resolve
216. for pattern in self.url_patterns:
File "/home/webdev/.virtualenvs/twtstore/lib/python2.5/site-packages/
django/core/urlresolvers.py" in _get_url_patterns
245. patterns = getattr(self.urlconf_module, "urlpatterns",
self.urlconf_module)
File "/home/webdev/.virtualenvs/twtstore/lib/python2.5/site-packages/
django/core/urlresolvers.py" in _get_urlconf_module
240. self._urlconf_module = import_module
(self.urlconf_name)
File "/home/webdev/.virtualenvs/twtstore/lib/python2.5/site-packages/
django/utils/importlib.py" in import_module
35. __import__(name)
File "/var/code/twtstore/urls.py" in <module>
7. from satchmo_store.urls import urlpatterns as satchmo_urls
File "/home/webdev/.virtualenvs/twtstore/src/satchmo/satchmo/apps/
satchmo_store/urls/__init__.py" in <module>
28. from base import urlpatterns as basepatterns
File "/home/webdev/.virtualenvs/twtstore/src/satchmo/satchmo/apps/
satchmo_store/urls/base.py" in <module>
8. from product.urls.base import adminpatterns as prodpatterns
File "/home/webdev/.virtualenvs/twtstore/src/satchmo/satchmo/apps/
product/urls/__init__.py" in <module>
8. catbase = r'^' + config_value('PRODUCT','CATEGORY_SLUG') + '/'
File "/home/webdev/.virtualenvs/twtstore/src/satchmo/satchmo/apps/
livesettings/functions.py" in config_value
205. return config_get(group, key).value
File "/home/webdev/.virtualenvs/twtstore/src/satchmo/satchmo/apps/
livesettings/functions.py" in config_get
150. return ConfigurationSettings().get_config(group, key)
File "/home/webdev/.virtualenvs/twtstore/src/satchmo/satchmo/apps/
livesettings/functions.py" in get_config
67. raise SettingNotSet('%s config group does
not exist' % group)

Exception Type: SettingNotSet at /settings/
Exception Value:


However, if I go into the ./manage.py shell and

>>> from livesettings import config_value
>>> config_value('PRODUCT', 'CATEGORY_SLUG')

It returns 'category' just fine. If I import the urls, it returns
without an error.

Why does the shell work but the webserver not?

Thanks a bunch,

Corey Oordt

[Chris Moffitt]

What cache back end are you using? My guess is that the cache isn't working right at that point in the load process.

You could try changing it to file or locmem just to see if it works.

-Chris

[Corey Oordt]

I'm using memcache, but I tried locmem and file and got the same response.

-Corey

[ruidc]

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?

Regards,
Rui

On Aug 25, 3:40 pm, Corey Oordt <coreyoo...@gmail.com> wrote:
> I'm using memcache, but I tried locmem and file and got the same  
> response.
>
> -Corey
>
> On Aug 24, 2009, at 10:54 PM, Chris Moffitt wrote:
>
>
>
> > What cache back end are you using? My guess is that the cache isn't  
> > working right at that point in the load process.
>
> > You could try changing it to file or locmem just to see if it works.
>
> > -Chris
>

> > On Mon, Aug 24, 2009 at 3:31 PM, Corey Oordt <coreyoo...@gmail.com>  

[Bruce Kroeze]

On Wed, Sep 16, 2009 at 6:50 AM, ruidc <ruidc...@gmail.com> 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 Kroeze
http://www.ecomsmith.com
It's time to hammer your site into shape.

[ruidc]

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 <bkro...@gmail.com> wrote:

> On Wed, Sep 16, 2009 at 6:50 AM, ruidc <ruidc.ru...@gmail.com> 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

[Walter]

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 that SettingNotSet Exception 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

[Gloria W]

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

[Chris Moffitt]

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/9897f11d7b1aaba8#

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

[Gloria W]

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

[MetalFilter]

I had this problem. It was resolved by changing the media URL and
media Root to a static-only path.

On Nov 3, 11:52 pm, Gloria W <strang...@comcast.net> 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
>

> >     <mailto:ruidc.ru...@gmail.com>>  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<bkro...@gmail.com

> >     <mailto:bkro...@gmail.com>>  wrote:

>
> >     >>> On Wed, Sep 16, 2009 at 6:50 AM, ruidc<ruidc.ru...@gmail.com

> >     <mailto:ruidc.ru...@gmail.com>>  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>

[MetalFilter]

I had this problem. It was resolved by changing the media URL and
media Root to a static-only path.

On Nov 3, 11:52 pm, Gloria W <strang...@comcast.net> 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
>

> >     <mailto:ruidc.ru...@gmail.com>>  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<bkro...@gmail.com

> >     <mailto:bkro...@gmail.com>>  wrote:

>
> >     >>> On Wed, Sep 16, 2009 at 6:50 AM, ruidc<ruidc.ru...@gmail.com

> >     <mailto:ruidc.ru...@gmail.com>>  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>

[Walter]

Thanks, Chris. I just gave this a try, but it didn't seem to make any
difference.

On Nov 3, 10:37 pm, Chris Moffitt <ch...@moffitts.net> wrote:
> 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...

[Walter]

YES, this did it for me! I can finally see everything in my store.
Front, settings and admin finally accessible and all tests passing.

Beautiful work and kudos to you and your apprentice, Gloria.

MANY thanks,
Walter

On Nov 3, 10:52 pm, Gloria W <strang...@comcast.net> 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
>

> >     <mailto:ruidc.ru...@gmail.com>>  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<bkro...@gmail.com

> >     <mailto:bkro...@gmail.com>>  wrote:

>
> >     >>> On Wed, Sep 16, 2009 at 6:50 AM, ruidc<ruidc.ru...@gmail.com

> >     <mailto:ruidc.ru...@gmail.com>>  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>

[alej0]

Solved for me with this

http://bitbucket.org/chris1610/satchmo/issue/723/product-details-crash-if-django_extrecentlist-not

take a look at the third comment.

Look carefully to your TEMPLATE_CONTEXT_PROCESSORS because
http://www.satchmoproject.com/docs/svn/new_installation.html doesn't
include 'satchmo_ext.recentlist.context_processors.recent_products'

[alej0]

I try with standalone server and it works but still not in production
server which is apache/mod_wsgi/django 1.1.

[davis]

I have the same problem (on Apache/mod_wsgi/django1.1). It works fine
on the test server and via the shell on the production server. I tried
the "apprentice solution" above, but then it just came up with other
SettingNotSet errors.

If the cache were causing the problem, wouldn't clearing it solve it?
I tried that, but it didn't help.

Has anyone found the solution?

On Nov 7, 10:41 am, alej0 <alej0va...@gmail.com> wrote:
> I try with standalone server and it works but still not in production
> server which is apache/mod_wsgi/django 1.1.
>
> On Nov 3, 6:32 pm, Gloria W <strang...@comcast.net> 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.

[Chris Moffitt]

Did you try the solution from this thread?
http://groups.google.com/group/satchmo-users/browse_thread/thread/9897f11d7b1aaba8#

It worked for me in a slightly different situation but I'm curious if that's part of the issue.

Specifically, this point:

On line 47 in satchmo.apps.livesettings.models the cache-miss logic is
calling 'loading.app_cache_ready()' In our case that method is always
returning false. Thus, the database-value is never loaded, and Satchmo
creates a new Setting object in it's place. When this new setting is
saved to the db, it's triggering the IntegrityError.

I dug into the django.db.models.loading module a bit, and it appears
that a module/app someplace else in our codebase isn't loading
properly, and thus app_cache_ready() never finishes correctly. That
explains why we're seeing the problem in development but the tests
pass.

So, I'm assuming this isn't a Satchmo problem directly. However, this
_is_ the only side effect we've seen of whatever underlying problem
we're dealing with. The site works fine-as-is otherwise. I'm going to
keep digging, but I thought I'd document what we've found to-date.

Our temporary fix was to remove the call to 'loading.app_cache_ready
()' for now. Everything is working as expected.

-Chris

--

You received this message because you are subscribed to the Google Groups "Satchmo users" group.
To post to this group, send email to satchm...@googlegroups.com.
To unsubscribe from this group, send email to satchmo-user...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=.

[davis]

I'm not quite sure what that change is supposed to be, but I did try
changing "if loading.app_cache_ready():" to "if True:", and that
didn't work.

On Nov 17, 11:14 pm, Chris Moffitt <ch...@moffitts.net> wrote:
> Did you try the solution from this thread?http://groups.google.com/group/satchmo-users/browse_thread/thread/989...

> > satchmo-user...@googlegroups.com<satchmo-users%2Bunsu...@googlegroups.com>
> > .

[Alessandro Ronchi]

On 18 Nov, 15:26, davis <dv...@yahoo.com> wrote:
> I'm not quite sure what that change is supposed to be, but I did try
> changing "if loading.app_cache_ready():" to "if True:", and that
> didn't work.
>

I have the same problem. Tried to change that line but didn't worked.

[Alessandro Ronchi]

I'm actually using memcached, but other cache doesn't change (and memcached works for other satchmo 0.8 instances in the same machine) 

I've tried also mod_wsgi, but It doesn't change. I get an internal server error and in logs I get the same result.

I  would like to use mod_wsgi, but I can't make it shows the traceback on debug instead standard apache 500 error...

--
Alessandro Ronchi

SOASI
Sviluppo Software e Sistemi Open Source
http://www.soasi.com
http://www.linkedin.com/in/ronchialessandro

[Alessandro Ronchi]

If I put a comment on those lines from settings:

#satchmo_ext.recentlist.context_processors.recent_products
#"satchmo_ext.recentlist.middleware.RecentProductMiddleware",
#'satchmo_ext.recentlist',

or I make the Gloria's change on 

satchmo/apps/product/urls

it works for me.

[rbp]

On Nov 18, 4:19 pm, Alessandro Ronchi <alessandro.ron...@soasi.com>
wrote:

> If I put a comment on those lines from settings:
> #satchmo_ext.recentlist.context_processors.recent_products
> #"satchmo_ext.recentlist.middleware.RecentProductMiddleware",
> #'satchmo_ext.recentlist',
>
> or I make the Gloria's change on
> satchmo/apps/product/urls

FWIW, I didn't have any *recentlist in my settings at all, but
Gloria's fix worked for me (Thanks, Gloria & apprentice!).

[davis]

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 <strang...@comcast.net> 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
>

> >     <mailto:ruidc.ru...@gmail.com>>  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<bkro...@gmail.com

> >     <mailto:bkro...@gmail.com>>  wrote:

>
> >     >>> On Wed, Sep 16, 2009 at 6:50 AM, ruidc<ruidc.ru...@gmail.com

> >     <mailto:ruidc.ru...@gmail.com>>  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>

[Eric R. Palakovich Carr]

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: Fixes SettingNotSet CATEOGORY.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

[Simon Litchfield]

Thanks Eric your fix worked nicely, provided the import came -after-
valid database settings.

Bruce/Chris, looks like something is up with livesettings + modwsgi?
Sorry to be daft if this aint nothin new.

[Chris Moffitt]

There clearly seems to be some oddness going on with livesettings and certain configurations. It's currently being spun off to another project but we'll try to take a look at what's going on.

--

You received this message because you are subscribed to the Google Groups "Satchmo users" group.
To post to this group, send email to satchm...@googlegroups.com.

To unsubscribe from this group, send email to satchmo-user...@googlegroups.com.

[Ryan Headley]

If it matters, I haven't seen this issue under mod_wsgi, django 1.1.1 and the following Satchmo info:

changeset:   1182:5ed0fbc0c660
tag:         tip
user:        Chris Moffitt <ch...@moffitts.net>
date:        Sun Sep 20 10:10:57 2009 -0500
summary:     Fixing some docs and config options for google checkout. Closes #902

I haven't updated our satchmo since before October so perhaps if I did, I'd start seeing this issue...but I don't want to try and update now, just in case :)

--
http://www.sudovi.com/
http://www.twitter.com/lifewithryan
http://www.thecommontongue.com
http://www.lifewithryan.com/

[davis]

This fixed it for me. Thanks very much, Eric.

On Nov 22, 7:16 pm, "Eric R. Palakovich Carr" <carre...@gmail.com>
wrote:

[Chris Moffitt]

Interesting. If you put that product import in the url file does that also work? That might be a better solution for the long term.

-Chris

--

You received this message because you are subscribed to the Google Groups "Satchmo users" group.
To post to this group, send email to satchm...@googlegroups.com.
To unsubscribe from this group, send email to satchmo-user...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.

[davis]

I tried it in my urls.py, and it didn't work. Also, for some reason
this fix makes it necessary to set DJANGO_SETTINGS_MODULE to use the
manage.py shell -- I haven't had the chance to investigate why.

> > satchmo-user...@googlegroups.com<satchmo-users%2Bunsu...@googlegroups.com>
> > .

[ruckc]

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" <carre...@gmail.com>
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

> > > >     > I can't get thatSettingNotSetException to budge.

[Aleksandr Vladimirskiy]

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

--

You received this message because you are subscribed to the Google Groups "Satchmo users" group.
To post to this group, send email to satchm...@googlegroups.com.

To unsubscribe from this group, send email to satchmo-user...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.

--
Aleksandr Vladimirskiy

[franck bret]

hi
i've also met the same problems and spend a lot of hour in trying to
test and understand why there was different behaviour / errors between
local and production test. I've finally putted livesettings params in
my settings file but in this case i was still having error on product
slug even if it was defined et db param set to false. Unable to syncdb
but shell and diffsettings were running fine...
Now i've added "import product.config", i can run the site but got new
errors with shell and diffsettings. So livesettings is really a pain
and from my point of view if we need to automatically set value in a
database django offer loaddata command wich is a standard and just
work fine...
I think we need to make some refactorisation in order to make
livesettings optional and satchmo less depending on that...
Franck

2009/12/7 ruckc <curti...@gmail.com>:

> --
>
> You received this message because you are subscribed to the Google Groups "Satchmo users" group.
> To post to this group, send email to satchm...@googlegroups.com.
> To unsubscribe from this group, send email to satchmo-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.
>
>
>



--

Franck Bret
---------------------
06 03 90 65 98
Fax : 09 59 95 85 96

[Aleksandr Vladimirskiy]

I updated Satchmo to the Sept. 20 th version and that appears to stop SettingsNotSet from happening.

[Hernan]

I'm trying to setup international shipping but i'm getting this error

 UPS Cannot find rate for code: 08 [Worldwide Expedited]

I know the code is right, have anyone setup international shipping with UPS?

Thanks,

Full log.

<?xml version="1.0"?>

<RatingServiceSelectionResponse><Response><TransactionReference><CustomerContext>Rating and Service</CustomerContext><XpciVersion>1.0</XpciVersion></TransactionReference><ResponseStatusCode>1</ResponseStatusCode><ResponseStatusDescription>Success</ResponseStatusDescription></Response><RatedShipment><Service><Code>65</Code></Service><RatedShipmentWarning>Your invoice may vary from the displayed reference rates</RatedShipmentWarning><BillingWeight><UnitOfMeasurement><Code>LBS</Code></UnitOfMeasurement><Weight>8.0</Weight></BillingWeight><TransportationCharges><CurrencyCode>USD</CurrencyCode><MonetaryValue>293.49</MonetaryValue></TransportationCharges><ServiceOptionsCharges><CurrencyCode>USD</CurrencyCode><MonetaryValue>0.00</MonetaryValue></ServiceOptionsCharges><TotalCharges><CurrencyCode>USD</CurrencyCode><MonetaryValue>293.49</MonetaryValue></TotalCharges><GuaranteedDaysToDelivery>1</GuaranteedDaysToDelivery><ScheduledDeliveryTime/><RatedPackage><TransportationCharges><CurrencyCode>USD</CurrencyCode><MonetaryValue>0.00</MonetaryValue></TransportationCharges><ServiceOptionsCharges><CurrencyCode>USD</CurrencyCode><MonetaryValue>0.00</MonetaryValue></ServiceOptionsCharges><TotalCharges><CurrencyCode>USD</CurrencyCode><MonetaryValue>0.00</MonetaryValue></TotalCharges><Weight>6.0</Weight><BillingWeight><UnitOfMeasurement><Code>LBS</Code></UnitOfMeasurement><Weight>0.0</Weight></BillingWeight></RatedPackage></RatedShipment></RatingServiceSelectionResponse>

2009-12-12 05:42:12,455 ups.shipper : DEBUG    UPS Status Code for cart #73 = 1

2009-12-12 05:42:12,455 ups.shipper : DEBUG    UPS Cannot find rate for code: 08 [Worldwide Expedited]

[Hernan]

My bad - the issue was UPS service didn't work at the location I was trying. the cool thing is that just with 3 lines

you can add those extra options for international shipping.

/shiping/modules/ups/config.py

    MultipleStringValue(SHIPPING_GROUP,

        'UPS_SHIPPING_CHOICES',

        description=_("UPS Shipping Choices Available to customers."),

        choices = (

            (('01', 'Next Day Air')),

            (('02', 'Second Day Air')),

            (('03', 'Ground')),

            (('12', '3 Day Select')),

            (('13', 'Next Day Air Saver')),

            (('11', 'Standard')),

            (('07', 'Worldwide Express')),

            (('08', 'Worldwide Expedited')),

            (('54', 'Worldwide Express Plus'))

        ),

[Alex Hayes]

Thanks Gloria and apprentice, this solution worked for me, using
Apache with mod_fcgid, Django latest (as grappelli essentially
requires this) and Satchmo 0.9.

Interestingly I have another store that is not experiencing this issue
running on the same host.

> >     > I can't get that SettingNotSet Exception to budge.

[captainmish]

On Nov 23, 12:16 am, "Eric R. Palakovich Carr" <carre...@gmail.com>
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: Fixes SettingNotSet CATEOGORY.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?
>

I tried this, but now ./manage.py test fails saying settings.py not
found (or import error) - I can import product.config from the
(virtualenv) python shell though! Anyone have any idea what I'm doing
wrong?

[davis]

I found that when using this fix I had to set the
DJANGO_SETTINGS_MODULE environment variable in order to use the
manage.py shell.

[Bob Waycott]

davis,

The typical way of using manage.py shell without setting the environment variable is like this:

python manage.py shell --settings=settings

(if you are in your project dir and your settings.py is in the same dir)

That enables Django to load up all the necessary settings for shell to work.

[franck bret]

well bob, how to use settings is well documented in django
documentation, but the problem is not here, and i could confirm that i
encounter exactly the same strange behaviour even if i'm in django /
satchmo project folder...
All of the post of this thread are related to the fact that
live_settings module is not consistent and for the same reason i say a
few post ago is very hard to debug.
I've also tried to deactivate livesettings and pass in settings.py a
full dictionary with all possible and required livesettings values,
but the problem still remain the same...

2009/12/22 Bob Waycott <bobwa...@gmail.com>:

--

[Bob Waycott]

Perhaps we should see if a concerted effort could be made during next weekend's sprint to get this resolved.

[Bruce Kroeze]

I'm the author of the livesettings module.  What I've seen in the past is that errors from livesettings, the dreaded "SettingNotSet" come up as a symptom of some other configuration issue.  That is, if there are other problems, for some reason, the system first responds by throwing a SettingNotSet error.  The problem, in almost all cases, is not the livesettings module, but the error gets masked by the SettingNotSet error.

I'd love to see that get more transparent, but I really really doubt the OP's problem in livesettings.  In my experience, that has *never* been the case.  It is always a misconfiguration elsewhere.  Any ideas about how to make this more transparent are welcome, and I will be on the Satchmo Sprint.

Bruce Kroeze

[C]

I noticed an odd chicken/egg situation with LiveSettings, but I got
too busy to look further at it.

1) The loading of certain modules are controlled by values in
LiveSettings.
2) Items with value in LiveSettings change depending on which modules
are loaded.
3) For added misery, URLs were (and may still be) one of the things
that depended on LiveSettings.

The side effect is that the settings appear from the command line
(python and everything satchmo are loaded fresh with the new live
settings), but don't appear within a running satchmo unless it's told
to reload everything.

The brute force solution might be to raise a signal when certain live
settings are changed and have the handler reload relevant things. But
it gives me a headache just thinking about it.

Thanks,
Chris Dukes

On Nov 22, 7:16 pm, "Eric R. Palakovich Carr" <carre...@gmail.com>
wrote:

[Bruce Kroeze]

Yes, the single biggest problem with Livesettings is that some settings require a reload or a restart.  I'd love to see that fixed, at least via an admin message after update.

--

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

--
Bruce Kroeze

[Bob Waycott]

Bruce,

I have also seen this be the case that SettingNotSet is thrown during module load when it is something other than livesettings actually causing the problem.

[FranckB]

hello

I've made a bunch of test between local env and dev server (apache,
mod_wsgi, memcached, postgresql) in order to to trace if it was
something in my project that breaks with livesettings.
I've on both machine the same latest version of django + satchmo +
satchmo dependencies.
I've taken the large project example and put in on my dev server, with
small settings adjustement for loading and adding to sys.path our
django module library folder (for manage.py only, wsgi handle sys.path
addition).

After a few errors about memcache setup and a chmod on satchmo.log,
i'm still in front of exactly the same error.
I've created a fresh database + load_l10n + load_store.
I can have diffsettings with no problems. I've also no problems with
exactly the same code on local django server.

I can't see anyway to catch the error and now i really don't know
where i can search cause i'm just with satchmo project, nothing
else...
Hope someone could point me to a new path to explore to make that
stuff juste run on a production server.

nacusr@erp:~$ sudo /etc/init.d/apache2 force-reload
* Reloading web server config
apache2 [ OK ]
nacusr@erp:~$ tail /var/log/apache2/error.log
[Wed Dec 30 19:58:10 2009] [error] [client 192.168.1.2] from
product.urls.base import adminpatterns as prodpatterns
[Wed Dec 30 19:58:10 2009] [error] [client 192.168.1.2] File "/home/
cowri/lib/djangoproject/satchmo/apps/product/urls/__init__.py", line
8, in <module>
[Wed Dec 30 19:58:10 2009] [error] [client 192.168.1.2] catbase =

r'^' + config_value('PRODUCT','CATEGORY_SLUG') + '/'

[Wed Dec 30 19:58:10 2009] [error] [client 192.168.1.2] File "/home/
cowri/lib/djangoproject/satchmo/apps/livesettings/functions.py", line
205, in config_value
[Wed Dec 30 19:58:10 2009] [error] [client 192.168.1.2] return
config_get(group, key).value
[Wed Dec 30 19:58:10 2009] [error] [client 192.168.1.2] File "/home/
cowri/lib/djangoproject/satchmo/apps/livesettings/functions.py", line
150, in config_get
[Wed Dec 30 19:58:10 2009] [error] [client 192.168.1.2] return
ConfigurationSettings().get_config(group, key)
[Wed Dec 30 19:58:10 2009] [error] [client 192.168.1.2] File "/home/
cowri/lib/djangoproject/satchmo/apps/livesettings/functions.py", line
67, in get_config
[Wed Dec 30 19:58:10 2009] [error] [client 192.168.1.2] raise
SettingNotSet('%s config group does not exist' % group)
[Wed Dec 30 19:58:10 2009] [error] [client 192.168.1.2] SettingNotSet

On 22 déc, 19:52, Bob Waycott <bobwayc...@gmail.com> wrote:
> Bruce,
>
> I have also seen this be the case that SettingNotSet is thrown during module
> load when it is something other than livesettings actually causing the
> problem.
>
>
>
> On Tue, Dec 22, 2009 at 1:30 PM, Bruce Kroeze <bkro...@gmail.com> wrote:
> > I'm the author of the livesettings module.  What I've seen in the past is
> > that errors from livesettings, the dreaded "SettingNotSet" come up as a
> > symptom of some other configuration issue.  That is, if there are other
> > problems, for some reason, the system first responds by throwing a
> > SettingNotSet error.  The problem, in almost all cases, is not the
> > livesettings module, but the error gets masked by the SettingNotSet error.
>
> > I'd love to see that get more transparent, but I really really doubt the
> > OP's problem in livesettings.  In my experience, that has *never* been the
> > case.  It is always a misconfiguration elsewhere.  Any ideas about how to
> > make this more transparent are welcome, and I will be on the Satchmo Sprint.
>

> > On Tue, Dec 22, 2009 at 10:24 AM, Bob Waycott <bobwayc...@gmail.com>wrote:
>
> >> Perhaps we should see if a concerted effort could be made during next
> >> weekend's sprint to get this resolved.
>

> >> On Tue, Dec 22, 2009 at 11:56 AM, franck bret <franckb...@gmail.com>wrote:
>
> >>> well bob, how to use settings is well documented in django
> >>> documentation, but the problem is not here, and i could confirm that i
> >>> encounter exactly the same strange behaviour even if i'm in django /
> >>> satchmo project folder...
> >>> All of the post of this thread are related to the fact that
> >>> live_settings module is not consistent and for the same reason i say a
> >>> few post ago is very hard to debug.
> >>> I've also tried to deactivate livesettings and pass in settings.py a
> >>> full dictionary with all possible and required livesettings values,
> >>> but the problem still remain the same...
>

> >>> 2009/12/22 Bob Waycott <bobwayc...@gmail.com>:

> >>> >> satchmo-user...@googlegroups.com<satchmo-users%2Bunsubscribe@goog legroups.com>

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

> >>> > satchmo-user...@googlegroups.com<satchmo-users%2Bunsubscribe@goog legroups.com>

> >>> .
> >>> > For more options, visit this group at
> >>> >http://groups.google.com/group/satchmo-users?hl=en.
>
> >>> --
> >>> Franck Bret
> >>> ---------------------
> >>> 06 03 90 65 98
> >>> Fax : 09 59 95 85 96
>
> >>> --
>
> >>> You received this message because you are subscribed to the Google Groups
> >>> "Satchmo users" group.
> >>> To post to this group, send email to satchm...@googlegroups.com.
> >>> To unsubscribe from this group, send email to

> >>> satchmo-user...@googlegroups.com<satchmo-users%2Bunsubscribe@goog legroups.com>

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

> >> satchmo-user...@googlegroups.com<satchmo-users%2Bunsubscribe@goog legroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/satchmo-users?hl=en.
>
> > --
> > Bruce Kroeze
>
> >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 satchm...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > satchmo-user...@googlegroups.com<satchmo-users%2Bunsubscribe@goog legroups.com>

[Luis Bruno]

What I've logged in to say is that I've been getting this error on and
off for awhile. I added 'product.config' as a Django app, and it
works!

That's because I didn't find the correct place where importing
product.config would solve the SettingNotSet, so I had to improvise.
Thanks for the pointer!

> > satchmo-user...@googlegroups.com<satchmo-users%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/satchmo-users?hl=en.
>
> --

> Bruce Kroezehttp://www.ecomsmith.com