Re: [mezzanine-users] Re: Page menu - Cartridge product categories as root pages ?
Sure, but what if a product belongs to multiple categories?
On Sat, May 23, 2015 at 12:21 PM, Mathias Ettinger
mathias.ettin...@gmail.com wrote:
I meant a shop_menu tag, the page_menu already exists.
Le samedi 23 mai 2015 21:20:35 UTC+2, Mathias Ettinger a écrit :
What about implementing a page_menu tag in
cartridge.shop.templatetags.shop_tags? And changing the shop/product.html
template to use
{% block breadcrumb_menu %}{% shop_menu pages/menu/breadcrumb.html %}{%
endblock %}
Is it worth taking some time to provide it in cartridge?
Le samedi 23 mai 2015 18:57:35 UTC+2, Stephen McDonald a écrit :
BTW you should be able to implement your own breadcrumb logic by
overriding {% block breadcrumb_menu %} in your product.html template - at
that point you have your product variable, and access to its
category/categories.
That wouldn't be a one size fits all solution, but will absolutely
work for your own project.
On Sat, May 23, 2015 at 8:15 AM, Mathias Ettinger mathias@gmail.com
wrote:
So, as I understand, you’re talking about:
https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/templates/shop/product.html#L45-L48
https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fstephenmcd%2Fcartridge%2Fblob%2Fmaster%2Fcartridge%2Fshop%2Ftemplates%2Fshop%2Fproduct.html%23L45-L48sa=Dsntz=1usg=AFQjCNGaRwDqDpf3rqW61_9I-dIh7EfvpA
not displaying Shop Category Subcategory Product.title but only Shop
Product.title
The block uses the page_menu template tag. But also uses the
PageMiddleware mechanisms because the page_menu function uses the page
object populated in the context by the PageMiddleware:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/templatetags/pages_tags.py#L57-L64
PageMiddleware rely on the PageManager to query the pages in the
hierarchy of the page we are curently on:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/middleware.py#L76-L80
You can see in PageMiddleware that the hierarchy is queryed by
searching for pages with their slug being a subset of the slug we are
currently on:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/managers.py#L68-L69
And here is the problem you are facing. Since the url of your product
is SHOP_SLUG/product/PRODUCT_SLUG, only SHOP_SLUG is being matched as a
valid page, hence the short breadcrumb.
I haven't thought of a way to solve it efficiently, but suggestions are
welcome.
Le samedi 23 mai 2015 11:51:42 UTC+2, David Unric a écrit :
Yes, you've nailed it. Thanks for rephrasing the question.
It seems Product model derives only from Displayable, unlike Category
which derives from Page, so it won't be handled with PageMiddleware.
I'd guess for Product it would be prefixed directly by its app_label.
After inserting tracing output in mentioned pages_tags.py,
shop_product view receives in context both Shop and Category instances,
but
the former is used.
On Saturday, May 23, 2015 at 3:53:13 AM UTC+2, Chris Trengove wrote:
As I understand it, this happens in PageMiddleware
(pages/middleware.py) which is responsible for coming up with a page to
add to the template context. This happens as well for non-page views,
like
blog pages and shop products, in which case the page that gets added to
the context is the root blog or shop page.
For shop products, I think a useful feature would be to have the
context page be the category with the deepest (most specific) path. So
if
a product was in Shop Mens Wear Shirts and Shop Mens Wear (as a
featured product), then when viewing the product, the page set in the
context would be Shirts, so that the breadcrumbs then showed Shop
Mens
Wear Shirts and not (as happens at present) Shop.
So, the question is how best to achieve this, presumably by modifying
PageMiddleware in some way.
On Friday, May 22, 2015 at 11:11:51 PM UTC+10, David Unric wrote:
Hello,
how can I configure/tweak Mezzanine *cartridge.shop.models.Product*
won't be prefixes with *Shop* in menus and breadcrumbs ?
For example I've created product category Pages named Cars and
Acessories and each product belongs only to one of them.
Both categories are rendered as root in page_menu
pages/menus/tree.html (bellow Shop), links in category view (including
nested ones) correspond to current category in a categories tree. So
far
so good.
However when navigate to a specific product, instead of real parent
categories path, page_menu places product directly as a descendant of
*Shop*, which is not correct.
It seems the logic is in Mezzanine's pages_tags.py in
pages/templatetags, but having a harder time to completely understand
it,
incl. where *menu_pages* in context comes from etc.
I do not know if I'am on the right track and would welcome if
anybody can give me an advice how Cartridge products to be linked as
descendants of their primary category instead of a generic Shop ?
Thanks.
--
Re: [mezzanine-users] Re: Page menu - Cartridge product categories as root pages ?
My favourite function! :-)
On Sat, May 23, 2015 at 1:33 PM, Mathias Ettinger
mathias.ettin...@gmail.com wrote:
Mmmh… random.choice ? It's a function that is so underrated.
Anyway, I understand your statement as to why we might not be able to
implement a one size fits most approach.
Le samedi 23 mai 2015 21:33:26 UTC+2, Stephen McDonald a écrit :
Sure, but what if a product belongs to multiple categories?
On Sat, May 23, 2015 at 12:21 PM, Mathias Ettinger mathias@gmail.com
wrote:
I meant a shop_menu tag, the page_menu already exists.
Le samedi 23 mai 2015 21:20:35 UTC+2, Mathias Ettinger a écrit :
What about implementing a page_menu tag in
cartridge.shop.templatetags.shop_tags? And changing the shop/product.html
template to use
{% block breadcrumb_menu %}{% shop_menu pages/menu/breadcrumb.html
%}{% endblock %}
Is it worth taking some time to provide it in cartridge?
Le samedi 23 mai 2015 18:57:35 UTC+2, Stephen McDonald a écrit :
BTW you should be able to implement your own breadcrumb logic by
overriding {% block breadcrumb_menu %} in your product.html template -
at
that point you have your product variable, and access to its
category/categories.
That wouldn't be a one size fits all solution, but will absolutely
work for your own project.
On Sat, May 23, 2015 at 8:15 AM, Mathias Ettinger
mathias@gmail.com wrote:
So, as I understand, you’re talking about:
https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/templates/shop/product.html#L45-L48
https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fstephenmcd%2Fcartridge%2Fblob%2Fmaster%2Fcartridge%2Fshop%2Ftemplates%2Fshop%2Fproduct.html%23L45-L48sa=Dsntz=1usg=AFQjCNGaRwDqDpf3rqW61_9I-dIh7EfvpA
not displaying Shop Category Subcategory Product.title but only
Shop
Product.title
The block uses the page_menu template tag. But also uses the
PageMiddleware mechanisms because the page_menu function uses the page
object populated in the context by the PageMiddleware:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/templatetags/pages_tags.py#L57-L64
PageMiddleware rely on the PageManager to query the pages in the
hierarchy of the page we are curently on:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/middleware.py#L76-L80
You can see in PageMiddleware that the hierarchy is queryed by
searching for pages with their slug being a subset of the slug we are
currently on:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/managers.py#L68-L69
And here is the problem you are facing. Since the url of your product
is SHOP_SLUG/product/PRODUCT_SLUG, only SHOP_SLUG is being matched as a
valid page, hence the short breadcrumb.
I haven't thought of a way to solve it efficiently, but suggestions
are welcome.
Le samedi 23 mai 2015 11:51:42 UTC+2, David Unric a écrit :
Yes, you've nailed it. Thanks for rephrasing the question.
It seems Product model derives only from Displayable, unlike
Category which derives from Page, so it won't be handled with
PageMiddleware.
I'd guess for Product it would be prefixed directly by its app_label.
After inserting tracing output in mentioned pages_tags.py,
shop_product view receives in context both Shop and Category instances,
but
the former is used.
On Saturday, May 23, 2015 at 3:53:13 AM UTC+2, Chris Trengove wrote:
As I understand it, this happens in PageMiddleware
(pages/middleware.py) which is responsible for coming up with a page
to
add to the template context. This happens as well for non-page views,
like
blog pages and shop products, in which case the page that gets added
to
the context is the root blog or shop page.
For shop products, I think a useful feature would be to have the
context page be the category with the deepest (most specific) path.
So if
a product was in Shop Mens Wear Shirts and Shop Mens Wear
(as a
featured product), then when viewing the product, the page set in the
context would be Shirts, so that the breadcrumbs then showed Shop
Mens
Wear Shirts and not (as happens at present) Shop.
So, the question is how best to achieve this, presumably by
modifying PageMiddleware in some way.
On Friday, May 22, 2015 at 11:11:51 PM UTC+10, David Unric wrote:
Hello,
how can I configure/tweak Mezzanine
*cartridge.shop.models.Product* won't be prefixes with *Shop* in
menus and breadcrumbs ?
For example I've created product category Pages named Cars and
Acessories and each product belongs only to one of them.
Both categories are rendered as root in page_menu
pages/menus/tree.html (bellow Shop), links in category view
(including
nested ones) correspond to current category in a categories tree. So
far
so good.
However when navigate to a specific product, instead of real
parent categories path, page_menu places product directly as a
descendant
of *Shop*, which is not correct.
It seems the logic is in
Re: [mezzanine-users] Re: Page menu - Cartridge product categories as root pages ?
Mmmh… random.choice ? It's a function that is so underrated.
Anyway, I understand your statement as to why we might not be able to
implement a one size fits most approach.
Le samedi 23 mai 2015 21:33:26 UTC+2, Stephen McDonald a écrit :
Sure, but what if a product belongs to multiple categories?
On Sat, May 23, 2015 at 12:21 PM, Mathias Ettinger mathias@gmail.com
javascript: wrote:
I meant a shop_menu tag, the page_menu already exists.
Le samedi 23 mai 2015 21:20:35 UTC+2, Mathias Ettinger a écrit :
What about implementing a page_menu tag in
cartridge.shop.templatetags.shop_tags? And changing the shop/product.html
template to use
{% block breadcrumb_menu %}{% shop_menu pages/menu/breadcrumb.html
%}{% endblock %}
Is it worth taking some time to provide it in cartridge?
Le samedi 23 mai 2015 18:57:35 UTC+2, Stephen McDonald a écrit :
BTW you should be able to implement your own breadcrumb logic by
overriding {% block breadcrumb_menu %} in your product.html template -
at
that point you have your product variable, and access to its
category/categories.
That wouldn't be a one size fits all solution, but will absolutely
work for your own project.
On Sat, May 23, 2015 at 8:15 AM, Mathias Ettinger
mathias@gmail.com wrote:
So, as I understand, you’re talking about:
https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/templates/shop/product.html#L45-L48
https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fstephenmcd%2Fcartridge%2Fblob%2Fmaster%2Fcartridge%2Fshop%2Ftemplates%2Fshop%2Fproduct.html%23L45-L48sa=Dsntz=1usg=AFQjCNGaRwDqDpf3rqW61_9I-dIh7EfvpA
not displaying Shop Category Subcategory Product.title but only
Shop
Product.title
The block uses the page_menu template tag. But also uses the
PageMiddleware mechanisms because the page_menu function uses the page
object populated in the context by the PageMiddleware:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/templatetags/pages_tags.py#L57-L64
PageMiddleware rely on the PageManager to query the pages in the
hierarchy of the page we are curently on:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/middleware.py#L76-L80
You can see in PageMiddleware that the hierarchy is queryed by
searching for pages with their slug being a subset of the slug we are
currently on:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/managers.py#L68-L69
And here is the problem you are facing. Since the url of your product
is SHOP_SLUG/product/PRODUCT_SLUG, only SHOP_SLUG is being matched as a
valid page, hence the short breadcrumb.
I haven't thought of a way to solve it efficiently, but suggestions
are welcome.
Le samedi 23 mai 2015 11:51:42 UTC+2, David Unric a écrit :
Yes, you've nailed it. Thanks for rephrasing the question.
It seems Product model derives only from Displayable, unlike Category
which derives from Page, so it won't be handled with PageMiddleware.
I'd guess for Product it would be prefixed directly by its app_label.
After inserting tracing output in mentioned pages_tags.py,
shop_product view receives in context both Shop and Category instances,
but
the former is used.
On Saturday, May 23, 2015 at 3:53:13 AM UTC+2, Chris Trengove wrote:
As I understand it, this happens in PageMiddleware
(pages/middleware.py) which is responsible for coming up with a page
to
add to the template context. This happens as well for non-page views,
like
blog pages and shop products, in which case the page that gets added
to
the context is the root blog or shop page.
For shop products, I think a useful feature would be to have the
context page be the category with the deepest (most specific) path.
So if
a product was in Shop Mens Wear Shirts and Shop Mens Wear (as
a
featured product), then when viewing the product, the page set in the
context would be Shirts, so that the breadcrumbs then showed Shop
Mens
Wear Shirts and not (as happens at present) Shop.
So, the question is how best to achieve this, presumably by
modifying PageMiddleware in some way.
On Friday, May 22, 2015 at 11:11:51 PM UTC+10, David Unric wrote:
Hello,
how can I configure/tweak Mezzanine *cartridge.shop.models.Product*
won't be prefixes with *Shop* in menus and breadcrumbs ?
For example I've created product category Pages named Cars and
Acessories and each product belongs only to one of them.
Both categories are rendered as root in page_menu
pages/menus/tree.html (bellow Shop), links in category view
(including
nested ones) correspond to current category in a categories tree. So
far
so good.
However when navigate to a specific product, instead of real parent
categories path, page_menu places product directly as a descendant of
*Shop*, which is not correct.
It seems the logic is in Mezzanine's pages_tags.py in
pages/templatetags, but having a
[mezzanine-users] Re: Page menu - Cartridge product categories as root pages ?
I think if a product is in multiple categories then the owning page/category should be the deepest (most specific) category. If there are multiple such categories then just choose any. This way you could even have products appearing in the root shop category, but when they are clicked on, the breadcrumbs would show their full category and sub-category context. So the task then becomes one of querying for all categories which contain the product, and then choosing the one with the most antecedents. I've no idea whether this can be done efficiently or not. -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[mezzanine-users] Re: Page menu - Cartridge product categories as root pages ?
Yes, you've nailed it. Thanks for rephrasing the question. It seems Product model derives only from Displayable, unlike Category which derives from Page, so it won't be handled with PageMiddleware. I'd guess for Product it would be prefixed directly by its app_label. After inserting tracing output in mentioned pages_tags.py, shop_product view receives in context both Shop and Category instances, but the former is used. On Saturday, May 23, 2015 at 3:53:13 AM UTC+2, Chris Trengove wrote: As I understand it, this happens in PageMiddleware (pages/middleware.py) which is responsible for coming up with a page to add to the template context. This happens as well for non-page views, like blog pages and shop products, in which case the page that gets added to the context is the root blog or shop page. For shop products, I think a useful feature would be to have the context page be the category with the deepest (most specific) path. So if a product was in Shop Mens Wear Shirts and Shop Mens Wear (as a featured product), then when viewing the product, the page set in the context would be Shirts, so that the breadcrumbs then showed Shop Mens Wear Shirts and not (as happens at present) Shop. So, the question is how best to achieve this, presumably by modifying PageMiddleware in some way. On Friday, May 22, 2015 at 11:11:51 PM UTC+10, David Unric wrote: Hello, how can I configure/tweak Mezzanine *cartridge.shop.models.Product* won't be prefixes with *Shop* in menus and breadcrumbs ? For example I've created product category Pages named Cars and Acessories and each product belongs only to one of them. Both categories are rendered as root in page_menu pages/menus/tree.html (bellow Shop), links in category view (including nested ones) correspond to current category in a categories tree. So far so good. However when navigate to a specific product, instead of real parent categories path, page_menu places product directly as a descendant of *Shop*, which is not correct. It seems the logic is in Mezzanine's pages_tags.py in pages/templatetags, but having a harder time to completely understand it, incl. where *menu_pages* in context comes from etc. I do not know if I'am on the right track and would welcome if anybody can give me an advice how Cartridge products to be linked as descendants of their primary category instead of a generic Shop ? Thanks. -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[mezzanine-users] Price Rounding Off Issues
Hi Almost near launching a site. But running into Price rounding issues today when I fab deployed to AWS ec2 instance. Never had those issues before on ec2. My Development environment is working great with no issues. However on deployed machine -Prices are getting rounded off in various places ex: 249 was rounded off to 250 in cart.html, as well as HTML invoice, PDF invoice. Unit Price was displaying correctly as 249 But Total Price was showing 250 Also, facing rounding off issues in PDF invoice and View Invoice in browser. The amounts are accurate in email invoice though. Even the amounts sent to payment gateway are correct. When the account user goes to history of orders, the amounts are correctly displayed in the columns. Only issues are cart, html invoice, pdf templates. I have a tax_handler where i calculate tax as follows - TAX_RATE = 0.05 tax_total = Decimal(amount_to_tax) * Decimal(str(settings.TAX_RATE)) See attached files - 366.45 is the correct amount being shown in Order-History page, but invoice is generated or 370. -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] In-line editing issue with Mezzanine FileField
Don't think this has ever been supported.
Not sure what would be involved, but the best approach might end up just
using a regular file upload field that saves to the media library, without
trying to suck in admin pages into inline editing.
Are you interested in working on it?
On Sat, May 23, 2015 at 2:20 AM, Philip Southwell p...@zoothink.com wrote:
Hi there, I'm having trouble editing FileFields inline. When I attempt it
I'm getting the FileField on the popup, with the normal symbol linking to
the Media Manager, but when I click the image I'm not being taken to the
media manager to select a new image. Nor when I click the clear link is
the image being cleared. I'm being allowed to edit the other fields in the
same popup so I know the mechanism's all working fine.
Here's my code:
{% editable homepage.banner_image homepage.main_title homepage
.main_subtitle %}
img src={{ MEDIA_URL }}{% thumbnail homepage.banner_image
479 126 %}
h1{{ homepage.main_title }}/h1
h4{{ homepage.main_subtitle }}/h4
{% endeditable %}
The problem occurs in both Chrome and Firefox for me. I'm working in
Python 3.4 on the development branch.
--
You received this message because you are subscribed to the Google Groups
Mezzanine Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Stephen McDonald
http://jupo.org
--
You received this message because you are subscribed to the Google Groups
Mezzanine Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] Price Rounding Off Issues
It looks like you're calculating the correct value being stored in the DB, and only getting the error on output. Each currency value gets passed through the currency template tag, which is where the problem likely is. It also deals with machine specific locale settings, which will vary per machine - also making it a likely candidate for the error. Here's the source for it - https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/templatetags/shop_tags.py#L17-L41 Have you consistently defined (and installed) the correct locale? (defined with the SHOP_CURRENCY_LOCALE setting). Can you debug what happens in the currency template tag on your deployed machine? That might entail adding some logging to it, making a copy of it in your own project, printing out values while manually running it in a terminal, whatever works for you. On Sat, May 23, 2015 at 3:26 AM, vikraw vik...@gmail.com wrote: Hi Almost near launching a site. But running into Price rounding issues today when I fab deployed to AWS ec2 instance. Never had those issues before on ec2. My Development environment is working great with no issues. However on deployed machine -Prices are getting rounded off in various places ex: 249 was rounded off to 250 in cart.html, as well as HTML invoice, PDF invoice. Unit Price was displaying correctly as 249 But Total Price was showing 250 Also, facing rounding off issues in PDF invoice and View Invoice in browser. The amounts are accurate in email invoice though. Even the amounts sent to payment gateway are correct. When the account user goes to history of orders, the amounts are correctly displayed in the columns. Only issues are cart, html invoice, pdf templates. I have a tax_handler where i calculate tax as follows - TAX_RATE = 0.05 tax_total = Decimal(amount_to_tax) * Decimal(str(settings.TAX_RATE)) See attached files - 366.45 is the correct amount being shown in Order-History page, but invoice is generated or 370. -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] Re: The Readme on Github - I would like to give it a revamp
On Fri, May 22, 2015 at 11:14 PM, Mathias Ettinger mathias.ettin...@gmail.com wrote: Why not swap it entirely with doc/overview.rst? I think this will be the general approach - move stuff out of the README, and directly into the docs, and adding links in the README back to the docs for these moved pieces. Here's my initial thoughts on each section, feedback welcome. Overview - leave as is Features - leave as is Dependencies - move to end of installation section Installation - move to overview in docs, and link from README Themes - move to overview in docs, no link needed from README Browser support - move to overview in docs, no link needed from README Contributing - leave as is Multi-lingual sites - already has a docs section, merge into that or remove Third party plugins - move to overview in docs, and link from README Donating - leave as is Support - leave as is, but move up to a more prominent spot (the number of invalid issues opened when posting to the mailing list would suffice is overwhelming) Sites using Mezzanine - move to overview in docs, and link from README (refactoring demo site required) Quotes - leave as is This way, what relies on README.rst today can rely on overview.rst tomorow without breaking anything. Or is the point to shorten both? Le vendredi 22 mai 2015 22:32:01 UTC+2, Stephen McDonald a écrit : It's a good idea. Please keep in mind there's some functionality of the project site dependent on the format of the readme, particularly those lists we'll probably remove: https://github.com/stephenmcd/mezzanine.jupo.org/blob/master/demo/__init__.py On Fri, May 22, 2015 at 1:26 PM, Geo djge...@gmail.com wrote: +1 Mezzanine's Readme is, at the time of writing, 795 lines long - pretty much an essay! The GH Readme for Django itself is short and sweet at just 44 lines. That's a massive 94% reduction in lines. If you are looking for a python CMS to use, you want to read about 3 key features of Mezzanine that make it stand out from all the others, that's all. Then one could link to the Mezzanine website and documentation website for further details and even for installation steps etc. Just my thoughts. Interesting to hear what the core devs think... On Friday, 22 May 2015 10:43:37 UTC+1, Graham Oliver wrote: Hi all I would like to have a go at revamping the readme on GitHub https://github.com/stephenmcd/mezzanine/blob/master/README.rst Initial thoughts - Make it way shorter - Put the 'third party plugins' and 'sites using Mezzanine' lists in separate documents - Add details of 'Core Development Team' Possibly also something for people (relatively) new to the Open Source thing. All feedback appreciated... This one I quite like (apart from the crypto stuff) http://svn.apache.org/repos/asf/httpd/httpd/trunk/README Take Care g -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-use...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] Re: Page menu - Cartridge product categories as root pages ?
I meant a shop_menu tag, the page_menu already exists.
Le samedi 23 mai 2015 21:20:35 UTC+2, Mathias Ettinger a écrit :
What about implementing a page_menu tag in
cartridge.shop.templatetags.shop_tags? And changing the shop/product.html
template to use
{% block breadcrumb_menu %}{% shop_menu pages/menu/breadcrumb.html %}{%
endblock %}
Is it worth taking some time to provide it in cartridge?
Le samedi 23 mai 2015 18:57:35 UTC+2, Stephen McDonald a écrit :
BTW you should be able to implement your own breadcrumb logic by
overriding {% block breadcrumb_menu %} in your product.html template - at
that point you have your product variable, and access to its
category/categories.
That wouldn't be a one size fits all solution, but will absolutely work
for your own project.
On Sat, May 23, 2015 at 8:15 AM, Mathias Ettinger mathias@gmail.com
wrote:
So, as I understand, you’re talking about:
https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/templates/shop/product.html#L45-L48
https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fstephenmcd%2Fcartridge%2Fblob%2Fmaster%2Fcartridge%2Fshop%2Ftemplates%2Fshop%2Fproduct.html%23L45-L48sa=Dsntz=1usg=AFQjCNGaRwDqDpf3rqW61_9I-dIh7EfvpA
not displaying Shop Category Subcategory Product.title but only Shop
Product.title
The block uses the page_menu template tag. But also uses the
PageMiddleware mechanisms because the page_menu function uses the page
object populated in the context by the PageMiddleware:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/templatetags/pages_tags.py#L57-L64
PageMiddleware rely on the PageManager to query the pages in the
hierarchy of the page we are curently on:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/middleware.py#L76-L80
You can see in PageMiddleware that the hierarchy is queryed by searching
for pages with their slug being a subset of the slug we are currently on:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/managers.py#L68-L69
And here is the problem you are facing. Since the url of your product is
SHOP_SLUG/product/PRODUCT_SLUG, only SHOP_SLUG is being matched as a valid
page, hence the short breadcrumb.
I haven't thought of a way to solve it efficiently, but suggestions are
welcome.
Le samedi 23 mai 2015 11:51:42 UTC+2, David Unric a écrit :
Yes, you've nailed it. Thanks for rephrasing the question.
It seems Product model derives only from Displayable, unlike Category
which derives from Page, so it won't be handled with PageMiddleware.
I'd guess for Product it would be prefixed directly by its app_label.
After inserting tracing output in mentioned pages_tags.py,
shop_product view receives in context both Shop and Category instances,
but
the former is used.
On Saturday, May 23, 2015 at 3:53:13 AM UTC+2, Chris Trengove wrote:
As I understand it, this happens in PageMiddleware
(pages/middleware.py) which is responsible for coming up with a page to
add to the template context. This happens as well for non-page views,
like
blog pages and shop products, in which case the page that gets added to
the context is the root blog or shop page.
For shop products, I think a useful feature would be to have the
context page be the category with the deepest (most specific) path. So
if
a product was in Shop Mens Wear Shirts and Shop Mens Wear (as a
featured product), then when viewing the product, the page set in the
context would be Shirts, so that the breadcrumbs then showed Shop
Mens
Wear Shirts and not (as happens at present) Shop.
So, the question is how best to achieve this, presumably by modifying
PageMiddleware in some way.
On Friday, May 22, 2015 at 11:11:51 PM UTC+10, David Unric wrote:
Hello,
how can I configure/tweak Mezzanine *cartridge.shop.models.Product*
won't be prefixes with *Shop* in menus and breadcrumbs ?
For example I've created product category Pages named Cars and
Acessories and each product belongs only to one of them.
Both categories are rendered as root in page_menu
pages/menus/tree.html (bellow Shop), links in category view (including
nested ones) correspond to current category in a categories tree. So
far
so good.
However when navigate to a specific product, instead of real parent
categories path, page_menu places product directly as a descendant of
*Shop*, which is not correct.
It seems the logic is in Mezzanine's pages_tags.py in
pages/templatetags, but having a harder time to completely understand
it,
incl. where *menu_pages* in context comes from etc.
I do not know if I'am on the right track and would welcome if anybody
can give me an advice how Cartridge products to be linked as descendants
of
their primary category instead of a generic Shop ?
Thanks.
--
You received this message because you are subscribed to the Google
Groups Mezzanine Users group.
Re: [mezzanine-users] In-line editing issue with Mezzanine FileField
Sure. Not sure when I'll get it done but I'll give it a shot.
On Sunday, May 24, 2015 at 2:31:53 AM UTC+9:30, Stephen McDonald wrote:
Don't think this has ever been supported.
Not sure what would be involved, but the best approach might end up just
using a regular file upload field that saves to the media library, without
trying to suck in admin pages into inline editing.
Are you interested in working on it?
On Sat, May 23, 2015 at 2:20 AM, Philip Southwell ph...@zoothink.com
javascript: wrote:
Hi there, I'm having trouble editing FileFields inline. When I attempt it
I'm getting the FileField on the popup, with the normal symbol linking to
the Media Manager, but when I click the image I'm not being taken to the
media manager to select a new image. Nor when I click the clear link is
the image being cleared. I'm being allowed to edit the other fields in the
same popup so I know the mechanism's all working fine.
Here's my code:
{% editable homepage.banner_image homepage.main_title
homepage.main_subtitle %}
img src={{ MEDIA_URL }}{% thumbnail homepage.banner_image
479 126 %}
h1{{ homepage.main_title }}/h1
h4{{ homepage.main_subtitle }}/h4
{% endeditable %}
The problem occurs in both Chrome and Firefox for me. I'm working in
Python 3.4 on the development branch.
--
You received this message because you are subscribed to the Google Groups
Mezzanine Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to mezzanine-use...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/d/optout.
--
Stephen McDonald
http://jupo.org
--
You received this message because you are subscribed to the Google Groups
Mezzanine Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
