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 <[email protected]>: > 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]. > 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 [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.
