Re: [mezzanine-users] Re: The Readme on Github - I would like to give it a revamp
Hello, I believe most people who read the readme on github have already seen the website. So they would like to know technical stuff and how to get started and do basic and essential things. Perhaps a link to Dgango's guide and then instructions on how to get started and instructions on how to deploy. thanks, Brandon Keith Biggs http://www.brandonkeithbiggs.com/ On 5/24/2015 11:20 AM, Graham wrote: Hello all... I am also interested in the 'who' and the 'why' and this may help us decide what should go in the README... *Who* are we designing the README for? *Why* would the reader of the README choose to become involved, what would 'hook them in'? *Why* choose Mezzanine over any other 'similar' project? *Who* would we like to attract to the project / to use Mezzanine? Is there a minimum skill level that we want to mention? Clearly I have my own responses to these questions, but interested to hear others points of view before I unduly influence anyone! Cheers g On 24/05/15 05:40, Stephen McDonald wrote: On Fri, May 22, 2015 at 11:14 PM, Mathias Ettinger mathias.ettin...@gmail.com mailto: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
Re: [mezzanine-users] Price Rounding Off Issues
The staged server have the locale correctly set ( see at end of my message the settings). Steps on my Staged server - Amazon Ec2 - Ubuntu 14 - stopped supervisor and nginx on my staged machine - switched my staged machine to run using - python manage runserver 0.0.0.0:8000 - put printf value statement in the currency filter under shop_tags.py now when i browse (using windows machine) the site running on ec2 machine I have NO issues with the Product prices, Cart total etc..Both the Browser and the printf values match However, when I switch the machine to nginx and start browsing from windows machine, i start getting the incorrect prices (alternate between correct and wrong) when - I press the different products or go back and forth from cart to product pages - Switching between incorrect price and correct prices happens everytime when I goto my payment processor and click the back button again to website (neglecting browser warnings that page has expired). BUT this doesn't happens when site running from python manage runserver ex: Rs.249 is displayed as Rs.250 and Rs.349 as Rs.350. clicking the same link toggles between those 2 values Help is greatly appreciated as i am near completion and can't figure this ambiguous behavior. My development is on Local Machine a Ubuntu 12.01LTS and I was testing using python manage runserver on 127.0.0.0:8000... This is working as expected locale command on ubuntu-14 amazon-ec2 LANG=en_IN LANGUAGE=en_IN:en LC_CTYPE=en_IN LC_NUMERIC=en_IN LC_TIME=en_IN LC_COLLATE=en_IN LC_MONETARY=en_IN LC_MESSAGES=en_IN LC_PAPER=en_IN LC_NAME=en_IN LC_ADDRESS=en_IN LC_TELEPHONE=en_IN LC_MEASUREMENT=en_IN LC_IDENTIFICATION=en_IN LC_ALL= The currencies symbol is correctly shown on the browser. However, i the prices change sometimes alternately and sometimes randomly. Correct price is 249. it switches between 249 and 250 when i click the same page or cart button. the cart total is updated On Saturday, May 23, 2015 at 10:59:37 PM UTC+5:30, Stephen McDonald wrote: 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 javascript: 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-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.
Re: [mezzanine-users] Re: The Readme on Github - I would like to give it a revamp
Thanks Brandon I will get going with the feedback I have. Stephen, could you please give me the instructions on how to install the 'project site' on my local development machine. I can do the git clone but I am a bit hazy after that. Thanks g On 24/05/15 21:41, Brandon Keith Biggs wrote: Hello, I believe most people who read the readme on github have already seen the website. So they would like to know technical stuff and how to get started and do basic and essential things. Perhaps a link to Dgango's guide and then instructions on how to get started and instructions on how to deploy. thanks, Brandon Keith Biggs http://www.brandonkeithbiggs.com/ On 5/24/2015 11:20 AM, Graham wrote: Hello all... I am also interested in the 'who' and the 'why' and this may help us decide what should go in the README... *Who* are we designing the README for? *Why* would the reader of the README choose to become involved, what would 'hook them in'? *Why* choose Mezzanine over any other 'similar' project? *Who* would we like to attract to the project / to use Mezzanine? Is there a minimum skill level that we want to mention? Clearly I have my own responses to these questions, but interested to hear others points of view before I unduly influence anyone! Cheers g On 24/05/15 05:40, Stephen McDonald wrote: On Fri, May 22, 2015 at 11:14 PM, Mathias Ettinger mathias.ettin...@gmail.com mailto: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,
Re: [mezzanine-users] a page summary with a link to the whole page
Thanks for your reply. I want to know if I can create a custom page rather
than use the blog app. I mean doing like the following :
class ACustomPage(Page, RichText):
content = models.TextField()
pubDate = models.DateField()
Then register the page and use it as I asked?
On Saturday, 23 May 2015 01:11:07 UTC, Danny S wrote:
On 23/05/2015 9:12 AM, Jean de la Croix Ki wrote:
Hi group;
I want to know how is it possible to create page and just put it
summary and a link to it on my home page. How to achieve this ?
My home page shows some of the summaries of the blog posts on the front
page - you could probably do this in your template
for other pages as well. The key thing, I think, is the
'truncatewords_html' filter that Django provides, it allows you show a
short snippet from another page/other content.
In my index.html template:
{% block main %}
{% blog_recent_posts 3 as recent_posts %}
{% if recent_posts %}
div class=panel
h2a href=/blogLatest News/a/h2
{% for blog_post in recent_posts %}
h3
a href={{ blog_post.get_absolute_url }}{{ blog_post.title }}/a
/h3
h6 class=post-meta
{% trans Posted by %}: {% with blog_post.user as author %} a
href={% url blog_post_list_author author %}{{
author.get_full_name|default:author.username }}/a {% endwith %}
{% blocktrans with sometime=blog_post.publish_date|timesince %}{{
sometime }} ago{% endblocktrans %}
/h6
div class=recent-summary
{{ blog_post.content|safe|truncatewords_html:100 }}
p class=blog-list-detail
a href={{ blog_post.get_absolute_url }}{% trans read more
%}/a
/p
/div
{% endfor %}
pa href=/blogiRead more news/i/a/p
/div
{% endif %}
{% endblock %}
Hope this helps!
Seeya. Danny.
--
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] Support for multiple currencies?
I haven't played with this kind of things, but I made the SHOP_CURRENCY_LOCALE setting translatable with that in mind. You could try to setup a translation field on the unit_price and sale_price fields of the Priced model. Not sure of how it will be handled out of the box: ProductAdmin inherits from Displayable which is translation-ready. But the variation saving logic is very specific and might not behave very well. Anyway, if you get something working with products, all you have to do is set a price for each language and, in your settings page, set the correct locale to get the currency for each language. Any feedback on how you setup translation fields and results observed will be appreciated. Le samedi 23 mai 2015 19:31:11 UTC+2, Stephen McDonald a écrit : There may be a solution here using the new modeltranslation integration. Anyone have any insight there? (Particularly Mathias Ettinger!) On Thu, May 21, 2015 at 11:24 AM, longne...@gmail.com javascript: wrote: Dear all, In cartridge, how can I set prices for different currencies? E.g. I have a product that has a price in CHF, EUR and USD. Users should be able to switch between them, independent of the currently selected language. Is this possible? Thanks, Claude -- 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.
Re: [mezzanine-users] Price Rounding Off Issues
Is it possible that you are running with different versions of python between the runserver and nginx/gunicorn versions of your website? I've noticed before in other work that e.g. Python 2.7 has slightly different precision on floats than Python 2.6... But yeah, weird problem. On 25/05/2015 3:45 AM, vikraw wrote: The staged server have the locale correctly set ( see at end of my message the settings). Steps on my Staged server - Amazon Ec2 - Ubuntu 14 - stopped supervisor and nginx on my staged machine - switched my staged machine to run using - python manage runserver 0.0.0.0:8000 - put printf value statement in the currency filter under shop_tags.py now when i browse (using windows machine) the site running on ec2 machine I have NO issues with the Product prices, Cart total etc..Both the Browser and the printf values match However, when I switch the machine to nginx and start browsing from windows machine, i start getting the incorrect prices (alternate between correct and wrong) when - I press the different products or go back and forth from cart to product pages - Switching between incorrect price and correct prices happens everytime when I goto my payment processor and click the back button again to website (neglecting browser warnings that page has expired). BUT this doesn't happens when site running from python manage runserver ex: Rs.249 is displayed as Rs.250 and Rs.349 as Rs.350. clicking the same link toggles between those 2 values Help is greatly appreciated as i am near completion and can't figure this ambiguous behavior. My development is on Local Machine a Ubuntu 12.01LTS and I was testing using python manage runserver on 127.0.0.0:8000... This is working as expected locale command on ubuntu-14 amazon-ec2 LANG=en_IN LANGUAGE=en_IN:en LC_CTYPE=en_IN LC_NUMERIC=en_IN LC_TIME=en_IN LC_COLLATE=en_IN LC_MONETARY=en_IN LC_MESSAGES=en_IN LC_PAPER=en_IN LC_NAME=en_IN LC_ADDRESS=en_IN LC_TELEPHONE=en_IN LC_MEASUREMENT=en_IN LC_IDENTIFICATION=en_IN LC_ALL= The currencies symbol is correctly shown on the browser. However, i the prices change sometimes alternately and sometimes randomly. Correct price is 249. it switches between 249 and 250 when i click the same page or cart button. the cart total is updated On Saturday, May 23, 2015 at 10:59:37 PM UTC+5:30, Stephen McDonald wrote: 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 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 javascript: 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-use...@googlegroups.com javascript:.
[mezzanine-users] What would be the best way to accept arbitrary values for product variations?
I want the admin user to be able to add arbitrary 'height' and 'width' values to product variations (the products are artworks with originals and prints as variations). Currently, users can add specific 'height' and 'width' values as options in the 'create new variations' fieldset. This would be fine if the set of values were limited (e.g. to 'small', 'medium', 'large') but because the values are arbitrary, adding a new product option for each new 'height' or 'width' value is unwieldy. Instead, it would make more sense if these values were added after creating the variation (i.e. in the same way that the 'number in stock' and 'unit price' are set). I've looked through shop.models.py and shop.admin.py but can't see where or how it might be possible to add extra fields to the variations other than the standard approach of using product options, which is not really suitable if I want to allow arbitrary values instead of a set of checkboxes. Does anyone have any suggestions for how I might best approach this? -- 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] a page summary with a link to the whole page
Hi Jean. Yes, you can retrieve content from your custom pages too. I see two possibilities: - If your desired page structure allows it, you can create the pages from which you want to pull the content as children of the page that will show the snippets. This way the child pages are accessible in the parent page as page.children, and you can use the truncatewords filter or the description field as others have explained. - For a more flexible solution, you can create a template tag that loads your custom pages into the context (something modeled after Mezzanine's own blog tags). Again, you're then able to display the content as you like. As a side note, I don't know if the example model you provided in your previous reply is what you're actually using, but it's worth saying that anything that inherits from Page or Displayable already has a publish_date field, and anything that inherits from RichText already has a content field; so declaring those is not necessary. -- 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.
