TemplateSyntaxError

[Matt]

Hi there,

I've installed Satchmo (trunk) today following the instructions given
on the site.

But I've run into a small issue which I was hoping you might be able
to help me with.

Whenever I try and run either my own project or one of the default
included projects (simple, etc).

I get the following error(s):

TemplateSyntaxError at /store/

Caught an exception while rendering: need more than 1 value to unpack

In template /Library/Python/2.5/site-packages/Satchmo-0.9_pre-
py2.5.egg/satchmo_store/shop/templates/base.html, error at line 48

Which turns out to be

47 <h3>{% trans "Quick Links" %}</h3>
48 {% url satchmo_product_recently_added as recenturl %}
49 {% if recenturl %}<a href="{{ recenturl }}">{% trans "Recently
Added" %}</a>{% endif %}
50 {% url satchmo_product_best_selling as popularurl %}

Any ideas why this might be happening? Is this potentially a bug?

NB: Is also happened with the {% satchmo_search_form %} and {%
category_tree %} I temporarily commented them out but that just kept
moving the problem elsewhere.

Thanks in advance,
Matt

[davis]

I just updated satchmo trunk on my dev site and developed the same
problem. I haven't been able to figure out what the problem is so far.
My Django/Satchmo versions are:

Using Django version 1.1 beta 1 SVN-11265
Using Satchmo version 0.9-pre hg-unknown

And the traceback I got is here: http://dpaste.org/BEPc/

I'll let you know if I get anywhere with it.

[Chris Moffitt]

Looks like something broke it in Django trunk.

I am getting the same error with Django SVN-11268 but was not getting it with SVN-10865

I'm not sure what backwards incompatible changes might have happened or other change that's causing the issue.

I'm not sure I'll be able to check it out right now but hopefully it's not too difficult to figure out what changed and might be causing the issue.

Thanks for posting the bug report. Hopefully it's not too difficult to id and fix.

-Chris

[Chris Moffitt]

In the interest of keeping folks up to speed, this error is most likely do to the recent inclusion of support for namespaces in urls.

You can see the changeset here -
http://code.djangoproject.com/changeset/11250

I'm not 100% sure what I need to do to fix it yet but I'm pretty sure this is the issue.

-Chris

[Matt]

Ok. Thanks for the update.

Cheers,
Matt

On Jul 19, 8:04 am, Chris Moffitt <ch...@moffitts.net> wrote:
> In the interest of keeping folks up to speed, this error is most likely do
> to the recent inclusion of support for namespaces in urls.
>

> You can see the changeset here -http://code.djangoproject.com/changeset/11250

[Chris Moffitt]

The issue seems to be with the way we're handling the payment urls. I've made some progress on the issue but having resolved one issue another has reared it's ugly head.

If you're just trying to get things running, you can comment out the line:
urlpatterns += make_urlpatterns()

in the file satchmo/apps/payment/urls.py

Obviously you're payment modules won't work, but the rest of the site should work.

I'll keep the group informed as we work on it. Oh yeah, I'm open to help too ;)

Thanks,

-Chris

[Bruce Kroeze]

I've been thinking about this.

The fact is, we probably should *not* be automatically trying to determine the URLs.

It would be nearly trivial to have people add it to their base URLs, and then we get:

1) Faster startup

2) More compatibility with "the way things are done" in standard Django apps.

3) More clarity

4) (most importantly to me) No possibility of people accidentally enabling test mode in live stores.

In a live store, this stuff should be set in stone, we don't get a lot by auto-determining the URLs.  Thoughts?

--
Bruce Kroeze
http://solidsitesolutions.com
Dynamic Designs, Optimized

[Chris Moffitt]

Bruce,

I tend to agree with you. All of your bullet points make sense. As long as we have a clearly documented approach of how to configure the payment modules, I think that explicit is better than implicit.

-Chris

[Bob Waycott]

I, too, have definitely thought of trying to disable some of the automatic stuff & having more explicit url patterns defined for payment modules in our live store. I think it's the sensible approach.

[C]

It would appear that url(regex, view, ...)
now expects that view is either a string, created by include(), or a 3
item list or tuple.

Changing [urlmodule] to include(urlmodule) in
payment/urls.py's make_urlpatterns() appears to resolve the issue.

Now I have this itching urge to see what happens if I do something
idiotic like
patterns.append(url(<regex>, include([urlmodule]))

[googletorp]

Using include is not a good option as it seems to be cached. I tried
that myself a few days ago, but found that on my dev server I needed
to restart before seeing newly enabled payment methods. I looked at
setting up a signal to clear cache when payment methods are altered
but that didn't seem possible.

~Jakob

[Bob Waycott]

Can't one pass in a view by way of a lambda?

[lifewithryan]

Does anyone know the status of this issue? Has it been closed?
(Granted I need to update to the Mercurial version since I'm currently
using the latest svn repo).

On Jul 24, 7:44 am, Bob Waycott <bobwayc...@gmail.com> wrote:
> Can't one pass in a view by way of a lambda?
>

[Chris Moffitt]

Upgrade the the mercurial version. It should be working fine there.

-Chris