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

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: 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
>
> 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 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
>
> > > >     > 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].
For more options, visit this group at 
http://groups.google.com/group/satchmo-users?hl=en.


Reply via email to