Re: [mezzanine-users] Mezzanine 4.0 with Cartridge
That’s exactly it. It was kind of obvious for me when I created translatable settings that this one should be translatable too. But it was less and less as time passed. But we never really discussed about it. Given how this field and modeltranslation are working, I don't think anything will break by letting this setting translatable. However, I don't find it useful anymore to keep it that way. It can only make sense if staff users are able to provide different prices for different languages. So that each language has its own price, own formating, and own currency symbol. We should either implement the latter or remove the former to avoid confusions. Le lundi 13 juillet 2015 08:19:11 UTC+2, Stephen McDonald a écrit : Loosely in my head it shouldn't be, since it's something that needs to be coordinated with system administration tasks (installing locale on the server etc). I'm guessing Mathias made it editable in order to make it translatable, which in theory would allow for multiple currencies - I vaguely recall a conversation around this as well but I don't think we explored it too much. Thinking more about it, it probably won't work - the MoneyField (which all monetary values in the DB use) uses the locale to determine the precision of its underlying DecimalField - I'm pretty sure that setup would break in conjunction with modeltranslation. On Mon, Jul 13, 2015 at 3:11 PM, Danny mol...@gmail.com javascript: wrote: Thanks Stephen. Wasn't the SHOP_CURRENCY_LOCALE made editable for a reason? Personally I don't mind either way, but in the 0.9.5. tag it's not editable, but on master it was, so I'm assuming that was changed for a reason. Maybe see https://github.com/stephenmcd/cartridge/commit/79c611bd318ec095073c3b9a729b2bfa7fb4405b#diff-d3220a9516c6f9328cd3c424de02a7ef for the change? Mathias, you made this change, want to comment? Seeya. Danny. On 13 July 2015 at 15:35, Stephen McDonald st...@jupo.org javascript: wrote: Fixed here: https://github.com/stephenmcd/cartridge/commit/c6aa87003d41ee203f5070f6601c81b844047e94 On Mon, Jul 13, 2015 at 2:56 PM, Stephen McDonald st...@jupo.org javascript: wrote: I can confirm this bug - the demo site doesn't hit it as it defines the SHOP_CURRENCY_LOCALE setting in its settings module. On Sat, Jul 11, 2015 at 11:49 AM, Danny mol...@gmail.com javascript: wrote: Hi all, I was wondering if anyone could help me! I've tried the new Mezzanine 4.0 release with cartridge master (which Stephen said should work) and am getting AppRegistryNotReady exception from shop.models.Priced(): BACKTRACE: /home/danny/.virtualenvs/mez4/local/lib/python2.7/site-packages/mezzanine/utils/conf.py:51: UserWarning: You haven't defined the ALLOWED_HOSTS settings, which Django requires. Will fall back to the domains configured as sites. warn(You haven't defined the ALLOWED_HOSTS settings, which /home/danny/.virtualenvs/mez4/local/lib/python2.7/site-packages/mezzanine/generic/fields.py:6: RemovedInDjango19Warning: django.contrib.contenttypes.generic is deprecated and will be removed in Django 1.9. Its contents have been moved to the fields, forms, and admin submodules of django.contrib.contenttypes. from django.contrib.contenttypes.generic import GenericRelation Traceback (most recent call last): File manage.py, line 14, in module execute_from_command_line(sys.argv) File /home/danny/.virtualenvs/mez4/local/lib/python2.7/site-packages/django/core/management/__init__.py, line 338, in execute_from_command_line utility.execute() File /home/danny/.virtualenvs/mez4/local/lib/python2.7/site-packages/django/core/management/__init__.py, line 312, in execute django.setup() File /home/danny/.virtualenvs/mez4/local/lib/python2.7/site-packages/django/__init__.py, line 18, in setup apps.populate(settings.INSTALLED_APPS) File /home/danny/.virtualenvs/mez4/local/lib/python2.7/site-packages/django/apps/registry.py, line 108, in populate app_config.import_models(all_models) File /home/danny/.virtualenvs/mez4/local/lib/python2.7/site-packages/django/apps/config.py, line 198, in import_models self.models_module = import_module(models_module_name) File /usr/lib/python2.7/importlib/__init__.py, line 37, in import_module __import__(name) File /home/danny/.virtualenvs/mez4/src/cartridge/cartridge/shop/models.py, line 35, in module class Priced(models.Model): File /home/danny/.virtualenvs/mez4/src/cartridge/cartridge/shop/models.py, line 41, in Priced unit_price = fields.MoneyField(_(Unit price)) File /home/danny/.virtualenvs/mez4/src/cartridge/cartridge/shop/fields.py, line 46, in __init__ set_locale() File /home/danny/.virtualenvs/mez4/src/cartridge/cartridge/shop/utils.py, line 103, in set_locale currency_locale =
[mezzanine-users] Re: Trouble with django version
To complete my previous answer you can specify the commit you wish to use to pip instead of HEAD/master Cartridge was still compatible with mezzanine before the merge of PR #1265 and will be as soon as we report the changes back to it. Just use a commit number that is before this merge (for instance the one I gave you previously) and you will have compatibility: pip install -e git+ https://github.com/stephenmcd/mezzanine.git@the_commit_you_d_like_to_get#egg=Mezzanine https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fstephenmcd%2Fmezzanine.git%23egg%3DMezzanine-mastersa=Dsntz=1usg=AFQjCNHCsSEd9DN-Hl0kGx_jPQbE_KD2Eg pip install -e git+https://github.com/stephenmcd/cartridge.git#egg=Cartridge https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fstephenmcd%2Fmezzanine.git%23egg%3DMezzanine-mastersa=Dsntz=1usg=AFQjCNHCsSEd9DN-Hl0kGx_jPQbE_KD2Eg Le samedi 20 juin 2015 08:42:27 UTC+2, Aman Garg a écrit : As I mentioned earlier, the problem is that when using the development version, I am unable to install cartridge for that version. It seems cartridge is only compatible presently with the release version. On Saturday, 20 June 2015 02:38:43 UTC+5:30, Mathias Ettinger wrote: By the time cartridge gets updated as well, you could try using a compatible version of mezzanine. Like https://github.com/stephenmcd/mezzanine/tree/a0df8300ed943fdae89b6f517f8ad54986ac9afd -- 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: Left-hand tree is not showing up in latest branch
Mezzanine is shipped with its own bootstrap theme and it is intended behaviour that some elements move around or disapear on smaller screens. If it doesn't suit your needs, you can use standard Django's template overriding to create your own html/css. And for your second question… I don't quite understand it. But you might be able to modify the behaviour by overriding the include/page_menu.html or include/page_tree.html templates. Le samedi 20 juin 2015 13:20:04 UTC+2, Brandon Keith Biggs a écrit : Hello, Messing around some more, I found that only when the page was not fullscreen did the left-hand tree not show up. There are a lot of things that don't work with the screen not maximized. For example, the + above the pages does not work. Also, when I have bottom-level pages checked to show in the left-hand tree, but not the top, they don't show when I click on the top level page. For example: about/ (not checked) teem (checked) history (checked) blog/ (not checked) Gallery (checked) ... My first thought, and what I would like to happen, is when I click on about for the two items under blog to show up. About doesn't show, but teem and history show. You get that left hand tree when you are in history, teem and about. But when you click on blog, you only get Gallery in the left tree. Is there a reason for the functionality not working this way? On most websites it is pretty normal for something like this to happen. Thanks, Brandon Keith Biggs http://www.brandonkeithbiggs.com/ On 6/20/2015 12:24 PM, Brandon Keith Biggs wrote: Hello, I just installed mezzanine yesterday and I am not seeing the Left-hand tree. The list of links under the h2/h2 The code looks to be there in base.html, but nothing is showing up. In the default pages there is: about/ blog history... On both blog and history the show in Left-hand tree box is checked, but on the about page there is nothing under the breadcrumbs. Thanks, -- Brandon Keith Biggs http://www.brandonkeithbiggs.com/ -- 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] Trouble with django version
By the time cartridge gets updated as well, you could try using a compatible version of mezzanine. Like https://github.com/stephenmcd/mezzanine/tree/a0df8300ed943fdae89b6f517f8ad54986ac9afd -- 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: how change first page content ??
Have a look at the urls.py file at the root of your project to get started on the several types of index pages. Basicaly, there is a line to uncomment in this urls.py and then you will have to create a regular page in your admin with the following slug: / Le dimanche 14 juin 2015 18:09:11 UTC+2, سید محمد رضا طباطبائی a écrit : i want change home page content in admin page how can i do it??? -- 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: error on create mezzanine Multi-Lingual Sites?
Be warned that the version of Mezzanine available through PyPi is not compatible with Django 1.7 and 1.8, nor does it have support for django-modeltranslation (at least as is). If you want to use Mezzanine with either django-modeltranslation or Django 1.8, you’ll have to use Mezzanine 4.0 which is pretty close to be released. You can have early access to it with: pip install -e git+ https://github.com/stephenmcd/mezzanine.git@master#egg=Mezzanine Same goes for catridge: pip install -e git+ https://github.com/stephenmcd/cartridge.git@master#egg=Cartridge https://github.com/stephenmcd/mezzanine.git@master#egg=Mezzanine Le samedi 13 juin 2015 15:14:10 UTC+2, سید محمد رضا طباطبائی a écrit : i update pip, mezzanin and django-modeltranslation worked correctly but when update cartridge and tested show this message -- 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: EXTRA_MODEL_FIELDS and django 1.8 migration
Hi Sergey, Since you’re using the development version of mezzanine, you'd better of reading the development version of the documentation. Have a look at the “Field Injection Caveats” section of https://github.com/stephenmcd/mezzanine/blob/master/docs/model-customization.rst Any feedback will be appreciated, especially if it doesn't seems to work as expected. Mathias Le vendredi 12 juin 2015 18:03:57 UTC+2, Sergey Maranchuk a écrit : In django 1.8 migration i can't set app_label in migration file and looks like not possible create migration in app A for app B. Any ideas? -- 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: error on create mezzanine Multi-Lingual Sites?
Hi, Can you confirm that you’re using the development version of Mezzanine and not the version available through pip. Also what is your version of Django and django-modeltranslation? Even though it might not be related, you mentionned adding languages to settings.LANGUAGES; but do you have a settings.LANGUAGE_CODE defined? Le vendredi 12 juin 2015 10:48:53 UTC+2, سید محمد رضا طباطبائی a écrit : i do this work to make multi lingual Sites whit mezzanine 1- $ mezzanine-project test cd test 2- edit setting.py USE_MODELTRANSLATION = False to USE_MODELTRANSLATION = True 3- add another languge to LANGUAGES in setting.py 4- run $python3 manage.py createdb but show this message $ python3 manage.py createdb /usr/local/lib/python3.3/dist-packages/Mezzanine-3.1.10-py3.3.egg/ mezzanine/utils/conf.py:51: UserWarning: You haven't defined the ALLOWED_HOSTS settings, which Django requires. Will fall back to the domains configured as sites. warn(You haven't defined the ALLOWED_HOSTS settings, which /usr/local/lib/python3.3/dist-packages/Mezzanine-3.1.10-py3.3.egg/mezzanine/utils/conf.py:59: UserWarning: TIME_ZONE setting is not set, using closest match: Asia/Tehran warn(TIME_ZONE setting is not set, using closest match: %s % tz) /usr/lib/python3.3/importlib/_bootstrap.py:313: RemovedInDjango19Warning: django.contrib.contenttypes.generic is deprecated and will be removed in Django 1.9. Its contents have been moved to the fields, forms, and admin submodules of django.contrib.contenttypes. return f(*args, **kwds) /usr/lib/python3.3/importlib/_bootstrap.py:313: RemovedInDjango19Warning: django.utils.importlib will be removed in Django 1.9. return f(*args, **kwds) Traceback (most recent call last): File manage.py, line 34, in module execute_from_command_line(sys.argv) File /usr/local/lib/python3.3/dist-packages/django/core/management/ __init__.py, line 338, in execute_from_command_line utility.execute() File /usr/local/lib/python3.3/dist-packages/django/core/management/ __init__.py, line 312, in execute django.setup() File /usr/local/lib/python3.3/dist-packages/django/__init__.py, line 18, in setup apps.populate(settings.INSTALLED_APPS) File /usr/local/lib/python3.3/dist-packages/django/apps/registry.py, line 115, in populate app_config.ready() File /usr/local/lib/python3.3/dist-packages/modeltranslation/apps.py, line 11, in ready handle_translation_registrations() File /usr/local/lib/python3.3/dist-packages/modeltranslation/models.py, line 80, in handle_translation_registrations autodiscover() File /usr/local/lib/python3.3/dist-packages/modeltranslation/models.py, line 17, in autodiscover from modeltranslation.translator import translator File /usr/local/lib/python3.3/dist-packages/modeltranslation/translator .py, line 12, in module from modeltranslation.manager import (MultilingualManager, MultilingualQuerysetManager, File /usr/local/lib/python3.3/dist-packages/modeltranslation/manager.py, line 12, in module from django.db.models.fields.related import RelatedField, RelatedObject ImportError: cannot import name RelatedObject how solve this problem??? -- 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] Enable Mezzanine multilingual site support
Hi Lee, To possibilities to fix your problem. Either you manually added modeltranslation to INSTALLED_APPS in a place that is too deep in the loading chain, in this case, just remove it. Turning on USE_MODELTRANSLATION will automatically add it to the list. Or you used the ordering of INSTALLED_APPS provided for Mezzanine 3.1 which is not suitable for modeltranslation. Make sure mezzanine.pages is before every app that subclass the Page model (gallery, form, shop). Or use the list from the development project_template : https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/project_template/project_name/settings.py#L206-L226 Le vendredi 12 juin 2015 07:45:23 UTC+2, Lee H. a écrit : Thanks for the reply Eduardo I upgraded to the master branch, pip install git+ https://github.com/stephenmcd/mezzanine.git, (which also upgraded django to 1.8), and I now get the error: Traceback (most recent call last): File manage.py, line 29, in module execute_from_command_line(sys.argv) File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/django/core/management/__init__.py, line 385, in execute_from_command_line utility.execute() File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/django/core/management/__init__.py, line 354, in execute django.setup() File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/django/__init__.py, line 21, in setup apps.populate(settings.INSTALLED_APPS) File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/django/apps/registry.py, line 85, in populate app_config = AppConfig.create(entry) File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/django/apps/config.py, line 87, in create module = import_module(entry) File /usr/lib/python2.7/importlib/__init__.py, line 37, in import_module __import__(name) File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/mezzanine/conf/__init__.py, line 209, in module import_module(%s.defaults % app) File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/django/utils/importlib.py, line 46, in import_module __import__(name) File /home/lee/Desktop/pyco/compmezz/theme/defaults.py, line 73, in module label=_(Name), File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/django/utils/translation/__init__.py, line 75, in gettext return _trans.gettext(message) File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py, line 319, in gettext return do_translate(message, 'gettext') File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py, line 306, in do_translate _default = translation(settings.LANGUAGE_CODE) File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py, line 209, in translation default_translation = _fetch(settings.LANGUAGE_CODE) File /home/lee/Desktop/pyco/compmezz/compenv/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py, line 189, in _fetch The translation infrastructure cannot be initialized before the django.core.exceptions.AppRegistryNotReady: The translation infrastructure cannot be initialized before the apps registry is ready. Check that you don't make non-lazy g$ttext calls at import time. Upon running the shell or runserver. My attempts at googling suggested the wsgi.py was at fault, but it looks correct: http://paste.ubuntu.com/11700416/ -- 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: Custom page with uploading form
Hi Quentin,
The @processor_for decorator is totally suited to manage form validation,
have a look at mezzanine.forms.page_processors for a working example.
Some advices on your code, though:
- I don't think that “if request.method == (post or POST)” really does
what you think it does. You’d better use “if request.method == post or
request.method ==POST“ or better “if request.method == POST“ or even
better, get rid of this if and create the form as “form =
DocForm(request.POST or None, request.FILES or None)”
- Your model has a ForeignKey for an UploadPage model and you’re creating
it with “uploadpage = page.id”. It would be wiser to use the page instance
instead of its id.
- Upon successful validation, you redirect the visitor to “request.path +
'?submitted=true'” which is basically the same view but you never handle
this GET parameter in your page processor. Is it by design?
(also, why don't you use quotation marks or diacritics in your docstrings?)
Cheers,
Le mercredi 3 juin 2015 18:07:25 UTC+2, Quentin M a écrit :
[Update] I just found the page_processor so I will test if it is the
solution, but not sure if the page_processor will make it with the
ForeignKey attribute...
[Edit] I tested with the page processor but it don't works ... can
page_processor validate a form ?
page_processors.py :
from django import forms
from django.http import HttpResponseRedirect
from mezzanine.pages.page_processors import processor_for
from .models import Document, UploadPage
from django.db import models
class DocForm(forms.Form):
docfile = models.FileField(upload_to=mezzSettings.PDT_VERSION,
help_text=Ajouter un document en annexe.)
@processor_for(UploadPage)
def uploadpage_form(request, page):
form = DocForm()
if request.method == (post or POST):
form = DocForm(request.POST, request.FILES)
if form.is_valid():
Document(docfile = request.FILES['docfile'], uploadpage =
page.id).save()
redirect = request.path + ?submitted=true
return HttpResponseRedirect(redirect)
return {form:form}
Le mercredi 3 juin 2015 11:13:56 UTC+2, Quentin M a écrit :
Firstly Hello ! I am Mezzanine newbie and I would like to have some help.
I know there are many similar questions but no one answers my question.
I have a model called Document assiociated to a custom page
UploadPage :
models.py :
# -*- coding: utf-8 -*-
from django.db import models
from django.utils.translation import ugettext_lazy as _
from mezzanine.conf import settings as mezzSettings
from mezzanine.pages.models import Page, RichText
class UploadPage(Page, RichText):
Page pour l upload des annexes
class Meta:
verbose_name = _(Upload page)
verbose_name_plural = _(Upload pages)
class Document(models.Model):
Modele representatif d un document annexe
docfile = models.FileField(upload_to=mezzSettings.PDT_VERSION)
uploadpage = models.ForeignKey(UploadPage, related_name=files)
admin.py :
# -*- coding: utf-8 -*-
from django.contrib import admin
from mezzanine.core.admin import TabularDynamicInlineAdmin
from mezzanine.pages.admin import PageAdmin
from quentinApp.models import UploadPage, Document
class DocumentInline(TabularDynamicInlineAdmin):
model = Document
class UploadPageAdmin(PageAdmin):
inlines = (DocumentInline,)
admin.site.register(UploadPage, UploadPageAdmin)
This code works but I would like to add a form field in this page
(displayed in the site) that allow an user to upload a file (no worries
about the security it's an intranet site).
I have already tested with a form page with field form but I don't like
the way it stores the documents (create an unique jksdfdfjkhomp key
folder for the document).
Should I add a Custom form field wich upload a file and create the page
related object Document... In the documentation I found the fields_for
function so the custom form must be the key, but I have no ideas how to
make it.
Ps: I have some difficulties in expressing myself in English, do not
hesitate to ask me if I was not clear.
Cordially,
Quentin
--
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] Which documentation is correct
Hi, The first link points to the documentation of the master branche which is not released yet. The second one points tout the official documentation for mezzanine 3.1.10. -- 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: How to make some user fields on registration form optional
woops, sorry. I’m not entirely used to the mobile interface of google groups and I missed your post with the code. That’s what I had in mind. And to answer Omid, just put the code in a file in one of your app. Let's call it forms.py for consistency, you’ll just have to add ACCOUNTS_PROFILE_FORM_CLASS = 'your_app.forms.ProfileForm' to your settings.py in order to use it. Le mardi 2 juin 2015 17:24:33 UTC+2, River Satya a écrit : Differently to how I showed in my example? On 2 June 2015 at 21:58, Mathias Ettinger mathias@gmail.com javascript: wrote: Instead of duplicating the __init__, you can just override the __init__, call super() and then set self.fields['first_name'].required = False -- You received this message because you are subscribed to a topic in the Google Groups Mezzanine Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/A6dDQLqePAg/unsubscribe . To unsubscribe from this group and all its topics, send an email to mezzanine-use...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- 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] [Django] ERROR: Invalid HTTP_HOST header: 'domain.com'.You may need to add u'domain.com'
I'm using HTTPS and SNI for virtualhosts. I'm getting these messages when clients that doesn't support SNI tries to connect. I happily ignore them. Mat be your issue is related. -- 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: Design to extend cartridge with global location selection
Hi, I’d rather not use a variation option to store the location: - it can be costly to retrieve every one of them when filtering products for a given category; - it will display on the product page and can be redundant if you have a dropdown elsewhere. Instead, I’d rather use EXTRA_MODEL_FIELDS to inject a CharField (or better, a ForeignKey or a ManyToMany, depending on your needs, to a custom model storing locations and may be other metadata) into cartridge.shop.models.Product You can then write a custom @processor_for(Category) to filter the products according to your needs. Check out https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/page_processors.py for an example of how to achieve that. Le jeudi 28 mai 2015 10:55:55 UTC+2, Wesley a écrit : Hi guys, This is not an problem but just here to consult with you guys. When coding these days, I happen to think about that how to add a functionality that dynamic display products by user's location selection. That is, on my homepage, there is one location select, e.g. New York, Boston .etc When users select New York, all product list related shows only products that are availabe for New York. So, if I code, I will: 1. Add one product option to Product, maybe named as location, and values are those city names, e.g. New York, Boston .etc 2. Add the selected location variable to request.session 3. Within those product list templates or view functions returning queryset to product list pages, filter products Is above idea correct? or do you guys has some better suggestions? Wesley -- 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: Design to extend cartridge with global location selection
Indeed, Category can be the (already existing and SQL cheaper version of the) ManyToMany field I was referring to. You can use the PAGE_MENU_TEMPLATES checkboxes to make sure they don't appear in the menu if you don't want them to. Le samedi 30 mai 2015 08:17:57 UTC+2, Stephen McDonald a écrit : Might even be able to do something simple using locations as categories. On Fri, May 29, 2015 at 11:12 PM, Mathias Ettinger mathias@gmail.com javascript: wrote: Hi, I’d rather not use a variation option to store the location: - it can be costly to retrieve every one of them when filtering products for a given category; - it will display on the product page and can be redundant if you have a dropdown elsewhere. Instead, I’d rather use EXTRA_MODEL_FIELDS to inject a CharField (or better, a ForeignKey or a ManyToMany, depending on your needs, to a custom model storing locations and may be other metadata) into cartridge.shop.models.Product You can then write a custom @processor_for(Category) to filter the products according to your needs. Check out https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/page_processors.py for an example of how to achieve that. Le jeudi 28 mai 2015 10:55:55 UTC+2, Wesley a écrit : Hi guys, This is not an problem but just here to consult with you guys. When coding these days, I happen to think about that how to add a functionality that dynamic display products by user's location selection. That is, on my homepage, there is one location select, e.g. New York, Boston .etc When users select New York, all product list related shows only products that are availabe for New York. So, if I code, I will: 1. Add one product option to Product, maybe named as location, and values are those city names, e.g. New York, Boston .etc 2. Add the selected location variable to request.session 3. Within those product list templates or view functions returning queryset to product list pages, filter products Is above idea correct? or do you guys has some better suggestions? Wesley -- 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.
[mezzanine-users] Re: admin.StackedInline not working in mezzanine
Hello,
To integrate your models gracefully into mezzanine, your may want to have
them extend mezzanine.pages.models.Page and extend the
mezzanine.pages.admin.PageAdmin as their modeladmin.
For your specific question about inlines, try
mezzanine.core.admin.TabularDynamicInlineAdmin or
mezzanine.core.admin.StackedDynamicInlineAdmin.
Le vendredi 29 mai 2015 09:54:28 UTC+2, Ernesto Palafox a écrit :
Hi to all!
I am working on a slider, i try it in django 1.7 and it works, but when i
install it to mezzanine(Mezzanine 3.1.10) the StackedInline doesnt work.
It doesnt show any information about my Slide model, does nothing when i
click on it. (Image)
here is my admin.py:
# -*- encoding: utf-8 -*-
from slideshow.models import Slide, Slideshow
from django.contrib import admin
class SlideInline(admin.StackedInline):
model = Slide
class SlideshowAdmin(admin.ModelAdmin):
fieldsets = [
(None, {'fields': ['name']}),
('Opciones', {'fields': [('slide_duration',
'player_orientation'),
]}),
('Tamaño', {'fields': [('slideheight', 'slidewidth')]}),
('Extras', {'fields': [('autoplay', 'autoplay_interval',)]}),
('Fondo', {'fields': [('transition', )]}),
('Texto', {'fields': [('caption_transition', )]}),
]
inlines = [SlideInline]
list_filter = ['pub_date']
search_fields = ['name']
admin.site.register(Slideshow, SlideshowAdmin)
If debug true i got this error message:
Exception Value:
strftime() argument 1 must be string or read-only buffer, not tuple
Error during template rendering
In template
/usr/local/lib/python2.7/dist-packages/grappelli_safe/templates/admin/includes/fieldset_inline.html,
error at line *15*
strftime() argument 1 must be string or read-only buffer, not tuple
Can anybody help me?
Thank you!
--
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: new release? - Possible Mezzanine Bug in relation to mezzanine.jupo.org install
What happens if you swap django.contrib.auth and django.contrib.admin in your INSTALLED_APPS? Does it solves it without the extra step? -- 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: How to get order final total price in views function?
Hi,
Where are you trying to get this value? Is it a step handler like
SHOP_HANDLER_PAYMENT or SHOP_HANDLER_ORDER? Or a regular view?
If you have an order object then it should be available in order.total,
given that you are “far enought” in the checkout process so it has been
computed. If you just have a request, try request.session[shipping_total]
combined with request.cart.total_price().
Le mercredi 27 mai 2015 13:49:51 UTC+2, Wesley a écrit :
Sorry missing one that:
I am trying to get the price from checkout confirmation page, I mean, when
click Next on the page.
Hi guys,
In one of my views function, I wanna get final total price of the
order.
I tried to get from request.session['order']['total'] or
request.session['cart']['something'] but all failed.
I print order and cart getting this sample:
order is:
{'card_name': u'', u'delivery_type': u'', 'remember': True, 'pay_type':
u'\u5fae\u4fe1\u652f\u4ed8', 'billing_detail_street': u'\u6d4b\u8bd5',
'shipping_detail_first_name': u'\u502a\u6770', 'shipping_detail_street':
u'\u6d4b\u8bd5', u'additional_instructions': u'', 'card_type': u'', 'step':
2, 'same_billing_shipping': True, u'prefer_time':
u'\u7acb\u5373\u9001\u9910', 'shipping_detail_phone': u'11211',
'billing_detail_email': u'whatever here', 'billing_detail_phone': u'11211',
'billing_detail_first_name': u'\u502a\u6770'}
cart is:544
So, no something like 'total' in order object, and cart is id.
Maybe I can get price to query database according to the cart's id, but
is there any easy way to get the total price?
Thanks.
Wesley
--
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] Theming best practice: Bootstrap or bare-bones?
Just to echo Stephen's words, I built a site removing almost everything theming related. Keeping almost only the magnify-popup javascript. And it works pretty well. Le mercredi 27 mai 2015 19:38:21 UTC+2, Gerald Hien a écrit : If things don't work as in bootstrap docs, overwrite bootstrap css and js in your projects static folder with current versions, since the ones included in mezzanine are somewhat outdated (3.0.3 fro D Am Mittwoch, 27. Mai 2015 19:06:49 UTC+2 schrieb Simon Griffee: Thanks, Stephen — understood. Once I have something to show I'll post a link here. Design: www.hypertexthero.com Photography: www.simongriffee.com Email: si...@hypertexthero.com Phone: +1 (347) 498-5369 On Wed, May 27, 2015 at 12:55 PM, Stephen McDonald st...@jupo.org wrote: Agree with Tom, use bootstrap if it helps you. I just wanted to point out though that nothing in Mezzanine really depends on bootstrap - if you wanted to start from scratch, using an alternative framework or none at all, you certainly can. On Wed, May 27, 2015 at 9:46 AM, Simon Griffee si...@hypertexthero.com wrote: Thanks, Tom. It does help, and I think you're right! I'll get to work now. Design: www.hypertexthero.com Photography: www.simongriffee.com Email: si...@hypertexthero.com Phone: +1 (347) 498-5369 On Wed, May 27, 2015 at 12:39 PM, Tom Lockhart tlockh...@gmail.com wrote: On May 27, 2015, at 9:16 AM, Simon Griffee simong...@gmail.com wrote: I'm beginning work on a Mezzanine theme focussed on blog writing and reading that I want to publish on PyPi. Mezzanine's templates are currently heavily Bootstrap-dependent and I'm wondering if I should embrace the framework in my theme. I am leaning toward starting from scratch with simple, minimal HTML and CSS and little-to-no JavaScript, but thought I’d ask here whether this is a fool's errand as I do want to maintain compatibility with future versions of Mezzanine. You can choose to leave out references to bootstrap in your templates, which will give you “minimal html and css”. But you’ll end up using bootstrap since it is awesome. Build on top of a body of work rather than try to replicate the thousands of hours of work embodied in bootstrap. hth - Tom -- You received this message because you are subscribed to a topic in the Google Groups Mezzanine Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/bdqjepkhtzc/unsubscribe . To unsubscribe from this group and all its topics, send an email to mezzanine-use...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 a topic in the Google Groups Mezzanine Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/bdqjepkhtzc/unsubscribe . To unsubscribe from this group and all its topics, send an email to mezzanine-use...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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] What would be the best way to accept arbitrary values for product variations?
You can use the default variation handling to achieve that. It might not be ideal because it will add a lot of checkboxes but it will do the job. Just add width and height (or juste size if you prefer) to the SHOP_OPTION_TYPE_CHOICES setting and create as much product options as needed for your produits using numerical values. You will then be able to use the chexboxes to get the desired size for your variations. -- 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] What would be the best way to accept arbitrary values for product variations?
There is also the begining of a discussion on dynamic variation fields here: https://github.com/stephenmcd/cartridge/issues/232 -- 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: What would be the best way to accept arbitrary values for product variations?
If you used EXTRA_MODEL_FIELDS to inject fields into ProductVariation, then ProductVariation.option_fields won't consider them for the “identity check” unless they are of type cartridge.shop.fields.OptionField (which I doubt, I would bet on regular IntegerField). So it might not be a problem for you. Le lundi 25 mai 2015 10:56:06 UTC+2, Tomlin a écrit : Good thing you pointed that out. I just read this - You'll also see in ProductVariation.option_fields its used as an identity check. Seems I still need every variation to have a unique set of options. Doh! On Monday, May 25, 2015 at 6:35:37 PM UTC+10, Mathias Ettinger wrote: There is also the begining of a discussion on dynamic variation fields here: https://github.com/stephenmcd/cartridge/issues/232 -- 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: What would be the best way to accept arbitrary values for product variations?
You best bet might be to ping @*sjkingo https://github.com/sjkingo* on the github issue to see if he can share what he already started. That might even (re)start the discussion on how to best integrate it into cartridge. Le lundi 25 mai 2015 12:20:59 UTC+2, Tomlin a écrit : Unfortunately, it is a problem. I can't rely on a unique combination of options (in some cases it will only be the dimensions that differ). The ProductVariation manager does have a check that ensures option sets must be unique in order to save the variation (the try/except): def create_from_options(self, options): Create all unique variations from the selected options. if options: options = SortedDict(options) # Build all combinations of options. variations = [[]] for values_list in list(options.values()): variations = [x + [y] for x in variations for y in values_list] for variation in variations: # Lookup unspecified options as null to ensure a # unique filter. variation = dict(list(zip(list(options.keys()), variation))) lookup = dict(variation) lookup.update(self._empty_options_lookup(exclude=variation)) try: self.get(**lookup) except self.model.DoesNotExist: self.create(**variation) It's s tempting to hack away at some of these files but I'll persevere and find a way of doing it while leaving the cartridge files intact :) On Monday, May 25, 2015 at 7:32:45 PM UTC+10, Mathias Ettinger wrote: If you used EXTRA_MODEL_FIELDS to inject fields into ProductVariation, then ProductVariation.option_fields won't consider them for the “identity check” unless they are of type cartridge.shop.fields.OptionField (which I doubt, I would bet on regular IntegerField). So it might not be a problem for you. Le lundi 25 mai 2015 10:56:06 UTC+2, Tomlin a écrit : Good thing you pointed that out. I just read this - You'll also see in ProductVariation.option_fields its used as an identity check. Seems I still need every variation to have a unique set of options. Doh! On Monday, May 25, 2015 at 6:35:37 PM UTC+10, Mathias Ettinger wrote: There is also the begining of a discussion on dynamic variation fields here: https://github.com/stephenmcd/cartridge/issues/232 -- 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] 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
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] How to create RichText migration
You could either subclass RichText or (better, as suggested by Ken) Page and have your custom model either as MyModel(Page, CustomRichText) or MyModel(CustomPage, RichText) Le mardi 19 mai 2015 22:57:01 UTC+2, Maksym Mospanenko a écrit : I want page type with ImageField and ForeignKey to other type and others RichText pages (default). I don't want add extra fields to whole pages on the site - I only want one my content type. And I don't understand how it tied with migrations. My model doesn't have default values as fields from RichTextPage class. Ok, it works with class MyModel(Page, RichText) and with default value in migration file. But it didn't work as MyModel(RichTextPage)... %) Thank you вівторок, 19 травня 2015 р. 23:37:49 UTC+3 користувач Kenneth Bolton написав: https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/models.py#L37-L38 You can create a custom copy of RichTextPage by copying the code. Ask yourself this question, though: Do I want multiple types of RichTextPage-alike pages for my content editors to learn and understand, or do I want a single RichTextPage type? If the answer to the second part of the question is yes, you are talking about field injection, which is far less labor intensive and definitely the Mezzanine approach. hth. -ken On Tue, May 19, 2015 at 4:28 PM, Maksym Mospanenko mmosp...@gmail.com wrote: I read docs but maybe didn't understand enough. Abstract class RichTextPage is Page and RichText mixin. I thought that I can use it as base for my model (only rich page and some fields). Why I have to use injection if I write my app with own models? вівторок, 19 травня 2015 р. 23:16:26 UTC+3 користувач Kenneth Bolton написав: Hi Maksym, Can I ask you to read about Mezzanine's content architecture http://mezzanine.jupo.org/docs/content-architecture.html#content-architecture? RichTextPage does not support subclassing. You are likely looking for model customization http://mezzanine.jupo.org/docs/model-customization.html#model-customization and field injection http://mezzanine.jupo.org/docs/model-customization.html#field-injection . Hope that helps. -ken On Tue, May 19, 2015 at 4:10 PM, Maksym Mospanenko mmosp...@gmail.com wrote: I have a model that extends RichTextPage. How can I set default value for this field? You are trying to add a non-nullable field 'richtextpage_ptr' to product without a default; we can't do that (the database needs something to populate existing rows). Which is the right solution? -- 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. -- 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. -- 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: Blog post images with captions?
I would have used either RICHTEXT_FILTER or RICHTEXT_FILTERS to achieve the same result. But I think it ils ultimately a matter of taste. -- 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: Blog post images with captions?
I’m not sure of a way to add captions through the builtin widgets of tinyMCE but you can edit the HTML directly whenever you want. Just click the HTML button to open the editor and add your caption tag directly in there. This editor will allow you to add nearly all the tags you can't (or don't know how to) access from the widgets. Have a look at the RICHTEXT_ALLOWED_TAGS setting (http://mezzanine.jupo.org/docs/configuration.html#richtext-allowed-tags) to know which one are available with no particular configuration tweak. The RICHTEXT_FILTER_LEVEL and the RICHTEXT_FILTER(S) settings can also help improve your control over the rendering of whatever you put into your tinyMCE editor. Le vendredi 8 mai 2015 02:46:30 UTC+2, Lee H. a écrit : Hi, As far as a I can see, the tinyMCE default editor does not provide a way to add captions to images embedded in a blog post? (the description/title are there, but not a caption field). Are captions really missing or am I being blind? Seems pretty basic functionality... If they are missing, can someone recommend an alternative rich text editor or another custom way of implementing captions? Cheers -- 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: Which version of mezzanine should I use?
You can install the master branch which is on its way to be released in a near future. It supports both django 1:7 and 1:8 Check out the issue tracker on github for the release blocker tag to see what could impact your project. And report back there if you discover some others. Le jeudi 7 mai 2015 13:00:54 UTC+2, Sreedhar Bukya a écrit : Hi , I am currently upgrading my project from django 1.6.1 to django 1.7 and mezzanine both. My current project uses get_profile methods. pip install mezzanine is installing by default 1.6.11 but I am looking for django 1.7. I know they are some compatibility issues in packages. I know installing packages from github repository directly. Please let me know which (tag/branch/commit ) should I have to get from mezzanine git repo to make everything working. Regards, Sreedhar -- 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: new release?
Do you have migration defined in your soulapp2 application? If not, it is standard Django behaviour. The doc says: Be aware, however, that unmigrated apps cannot depend on migrated apps, by the very nature of not having migrations. This means that it is not generally possible to have an unmigrated app have a ForeignKey or ManyToManyField to a migrated app; some cases may work, but it will eventually fail. Le 08/04/2015 03:43, Graham Oliver a écrit : Django 1.8 - Python 3.4.3 Took the advice of the console 'You have unapplied migrations; your app may not work properly until they are applied. Run 'python manage.py migrate' to apply them.' and ran python manage.py migrate stack trace Running migrations: Rendering model states...Traceback (most recent call last): File manage.py, line 28, in module execute_from_command_line(sys.argv) File /home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/core/management/__init__.py, line 338, in execute_from_command_line utility.execute() File /home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/core/management/__init__.py, line 330, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File /home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/core/management/base.py, line 390, in run_from_argv self.execute(*args, **cmd_options) File /home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/core/management/base.py, line 441, in execute output = self.handle(*args, **options) File /home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/core/management/commands/migrate.py, line 221, in handle executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial) File /home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/db/migrations/executor.py, line 100, in migrate state.apps # Render all real_apps -- performance critical File /home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/utils/functional.py, line 60, in __get__ res = instance.__dict__[self.name] = self.func(instance) File /home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/db/migrations/state.py, line 154, in apps return StateApps(self.real_apps, self.models) File /home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/db/migrations/state.py, line 220, in __init__ self.render_multiple(list(models.values()) + self.real_models) File /home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/db/migrations/state.py, line 258, in render_multiple for more % (new_unrendered_models, get_docs_version()) django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [ModelState: 'soulapp2.SoulPractitioner', ModelState: 'soulapp2.SoulClassInformation', ModelState: 'soulapp2.Happening'] This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth) in an app with no migrations; see https://docs.djangoproject.com/en/1.8/topics/migrations/#dependencies for more *Note* The 3 models mentioned are the only ones in the project that inherit from 'Page' and 'RichText' -- You received this message because you are subscribed to a topic in the Google Groups Mezzanine Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/_QWfFVB3RVc/unsubscribe. To unsubscribe from this group and all its topics, send an email to mezzanine-users+unsubscr...@googlegroups.com mailto:mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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] File Uploader Not Visible (403 Forbidden)
Can you confirm that your server can serve the output of:
url =
'//...static-domain.../djstatic/static/grappelli/tinymce/jscripts/tiny_mce/plugins/searchreplace/searchreplace.htm
'
host = '//..domain..'
static_url = mezzanine.conf.settings.STATIC_URL
static_url = '//' + static_url.split('://') if '://' in static_url else
static_url
for prefix in (host, static_url, '/'):
if url.startswith(prefix):
url = url.replace(prefix, '', 1)
path = django.contrib.staticfiles.finders.find(url)
print(path[0])
If not, but the correct location is somewhere in path, you might want to
consider changing the ordering of your settings.STATICFILES_FINDERS.
Le jeudi 2 avril 2015 12:45:10 UTC+2, Pushkar Paranjpe a écrit :
Hi Mathias,
I am accessing these URLs as an authenticated user. I have tried with
admin superuser and two other users with a Staff status. All give same 403
error.
Pushkar
On Thursday, 2 April 2015 15:43:54 UTC+5:30, Mathias Ettinger wrote:
The mezzanine.core.views.static_proxy function (which is called by the
/asset_proxy/ url) is decorated by @staff_member_required.
Are you, by any chance, trying to open these urls as a non authenticated
user ?
Le jeudi 2 avril 2015 11:04:36 UTC+2, Pushkar Paranjpe a écrit :
Same error when trying to open the TinyMCE Find/Replace dialog box.
- The URL
http://...domain.../asset_proxy/?u=http://...static-domain.../djstatic/static/grappelli/tinymce/jscripts/tiny_mce/plugins/searchreplace/searchreplace.htm
gives 403 error
- The URL
http://...static-domain.../djstatic/static/grappelli/tinymce/jscripts/tiny_mce/plugins/searchreplace/searchreplace.htm
opens without 403 error
Any clues ?
Pushkar
On Thursday, 2 April 2015 12:57:35 UTC+5:30, Pushkar Paranjpe wrote:
Hi Danny,
Yes. As I mentioned, uploadify is visible in the browser when I access
it in my development server and works as expected in the browser.
Cheers!
Pushkar
On Thursday, 2 April 2015 12:41:46 UTC+5:30, Danny S wrote:
Hi Pushkar,
Do you have the Flash plugin installed for your browser?
https://get.adobe.com/flashplayer/
Seeya. Danny.
On 2/04/2015 5:19 PM, Pushkar Paranjpe wrote:
Production Environment: Hostgator, Shared
Trying to add a Featured Image to a Blog post. The SWF uploader UI
element itself is not visible.
Getting the following error in the browser console:
http://...domain.../asset_proxy/?u=http://
...domain.../static/filebrowser/uploadify/uploadify.swf
- Was working fine on the development server.
- I have ran collectstatic and confirmed that the uploadify.swf
file exists at an accessible path on the server.
- Accessing
http://...domain.../static/filebrowser/uploadify/uploadify.swf
itself directly loads the uploader UI fine without any 403 error.
- Accessing http://...domain.../asset_proxy/ alone does not give
a 403 either
- Other static assets like PNG images, CSS and JS are being
accessed without any issues
Screenshot :
https://lh3.googleusercontent.com/-p1r-QsppUn4/VRzl_6QnitI/CEU/VfEfIh_T158/s1600/Missing%2Buplloadify.swf_403_error.png
Please suggest a fix.
Cheers!
Pushkar
--
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.
--
Email: mol...@gmail.com
--
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] File Uploader Not Visible (403 Forbidden)
You are right for the [-1] part. But it’s very odd. If path is really None,
then going to
http://...domain.../asset_proxy/?u=http://...static-domain.../djstatic/static/grappelli/tinymce/jscripts/tiny_mce/plugins/searchreplace/searchreplace.htm
shoiuld give you the same output as going to
http://...domain.../asset_proxy/
I never experienced this before so I can only try to guess what the problem
is. And I’m lacking ideas.
It seems however, that your domain and static domain are different. Maybe
that mezzanine.core.views.static_proxy is trying to get searchreplace.htm
and uploadify.swf from the ...domain... server where it doesn't exist/is
unreachable, hence the 403…
Le jeudi 2 avril 2015 16:21:25 UTC+2, Pushkar Paranjpe a écrit :
Hi Mathias,
I re-ordered the only two active entries in the FINDERS list :
STATICFILES_FINDERS = (
django.contrib.staticfiles.finders.FileSystemFinder,
django.contrib.staticfiles.finders.AppDirectoriesFinder,
#'django.contrib.staticfiles.finders.DefaultStorageFinder',
)
403 errors persist.
Pushkar
On Thursday, 2 April 2015 19:37:54 UTC+5:30, Pushkar Paranjpe wrote:
Hi Mathias,
Thanks for your reply.
I assumed you meant :
url =
'//...static-domain.../djstatic/static/grappelli/tinymce/jscripts/tiny_mce/plugins/searchreplace/searchreplace.htm
'
host = '//..domain..'
static_url = mezzanine.conf.settings.STATIC_URL
static_url = '//' + static_url.split('://')*[-1]* if '://' in static_url
else static_url
for prefix in (host, static_url, '/'):
if url.startswith(prefix):
url = url.replace(prefix, '', 1)
path = django.contrib.staticfiles.finders.find(url)
print(path[0])
After running the above, path evaluates to None
Will try to shuffle the ordering of settings.STATICFILES_FINDERS now.
Pushkar
On Thursday, 2 April 2015 18:31:59 UTC+5:30, Mathias Ettinger wrote:
Can you confirm that your server can serve the output of:
url =
'//...static-domain.../djstatic/static/grappelli/tinymce/jscripts/tiny_mce/plugins/searchreplace/searchreplace.htm
'
host = '//..domain..'
static_url = mezzanine.conf.settings.STATIC_URL
static_url = '//' + static_url.split('://') if '://' in static_url else
static_url
for prefix in (host, static_url, '/'):
if url.startswith(prefix):
url = url.replace(prefix, '', 1)
path = django.contrib.staticfiles.finders.find(url)
print(path[0])
If not, but the correct location is somewhere in path, you might want to
consider changing the ordering of your settings.STATICFILES_FINDERS.
Le jeudi 2 avril 2015 12:45:10 UTC+2, Pushkar Paranjpe a écrit :
Hi Mathias,
I am accessing these URLs as an authenticated user. I have tried with
admin superuser and two other users with a Staff status. All give same 403
error.
Pushkar
On Thursday, 2 April 2015 15:43:54 UTC+5:30, Mathias Ettinger wrote:
The mezzanine.core.views.static_proxy function (which is called by the
/asset_proxy/ url) is decorated by @staff_member_required.
Are you, by any chance, trying to open these urls as a non
authenticated user ?
Le jeudi 2 avril 2015 11:04:36 UTC+2, Pushkar Paranjpe a écrit :
Same error when trying to open the TinyMCE Find/Replace dialog box.
- The URL
http://...domain.../asset_proxy/?u=http://...static-domain.../djstatic/static/grappelli/tinymce/jscripts/tiny_mce/plugins/searchreplace/searchreplace.htm
gives 403 error
- The URL
http://...static-domain.../djstatic/static/grappelli/tinymce/jscripts/tiny_mce/plugins/searchreplace/searchreplace.htm
opens without 403 error
Any clues ?
Pushkar
On Thursday, 2 April 2015 12:57:35 UTC+5:30, Pushkar Paranjpe wrote:
Hi Danny,
Yes. As I mentioned, uploadify is visible in the browser when I
access it in my development server and works as expected in the browser.
Cheers!
Pushkar
On Thursday, 2 April 2015 12:41:46 UTC+5:30, Danny S wrote:
Hi Pushkar,
Do you have the Flash plugin installed for your browser?
https://get.adobe.com/flashplayer/
Seeya. Danny.
On 2/04/2015 5:19 PM, Pushkar Paranjpe wrote:
Production Environment: Hostgator, Shared
Trying to add a Featured Image to a Blog post. The SWF uploader UI
element itself is not visible.
Getting the following error in the browser console:
http://...domain.../asset_proxy/?u=http://
...domain.../static/filebrowser/uploadify/uploadify.swf
- Was working fine on the development server.
- I have ran collectstatic and confirmed that the uploadify.swf
file exists at an accessible path on the server.
- Accessing
http://...domain.../static/filebrowser/uploadify/uploadify.swf
itself directly loads the uploader UI fine without any 403 error.
- Accessing http://...domain.../asset_proxy/ alone does not
give a 403 either
- Other static assets like PNG images, CSS and JS are being
accessed without any issues
Screenshot :
https://lh3.googleusercontent.com/-p1r-QsppUn4
[mezzanine-users] Re: Just upgraded to 3.1.10
Is there an error message after you run python manage.py runserver ? Do you go to localhost or localhost:8000 ? You might have to run migrations in order to get mezzanine to run fine, but since you’re not even getting a django error, it is not yet related to the mezzanine configuration. Le samedi 7 mars 2015 08:58:54 UTC+1, automo...@gmail.com a écrit : It seems that it no longer recognized my app. Ran the command pip install -U mezzanine and that ran fine. After that, when I run the command python manage.py runserver and go to localhost, Chrome says This webpage is not available. Same for the admin. Do I have to re-initialize my app after I upgrade Mezzanine or ... not sure what to do. I have Django 1.6.10 installed -- 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: modeltranslations - round 2
Just corrected a few things for the front-end language selector and pushed
an updated version of cartridge as well.
I tried the TabbedExternalJqueryTranslationAdmin class instead of
TranslationAdmin and couldn’t get the meta tag area to show. Does it happen
for you too? Or is there something else to do in order to get it working?
If it is not possible to show extra area like this that are hidden by
default, we definitely need to write our own custom class on top of
TranslationAdmin (meaning: core.BaseTranslationModelAdmin). I’m also unsure
if Translation{Tabular,Stacked}Inline also need to integrates some
tabbing-awareness code (wether it is a global switch or a per field one).
But I modified a little bit their admin classes to help integrate it if
needed.
Le samedi 7 juin 2014 02:26:50 UTC+2, Eduardo Rivas a écrit :
Hey everybody. I've been trying out Mathias master branch and everything
is working smoothly. As I said, I'm also exploring ways to enable toggling
translation fields in the Admin. Turns out Model Translation (MT) provides
two admin classes (docs
https://django-modeltranslation.readthedocs.org/en/latest/admin.html#tabbed-translation-fields-admin-classes)
to include the required static resources for this purpose:
TabbedTranslationAdmin
and TabbedExternalJqueryTranslationAdmin. The first one seems to fail as
it uses Django's jQuery, but the second one works as expected (though it
looks kinda ugly in Grappelli) by using external jQuery resources.
I have a couple of questions at this point:
1. Should we use these classes or create our own (considering
Mezzanine already includes jQuery and jQuery UI)?
2. Should we create a toggle for each field (as MT does), or just a
global toggle to hide/show all fields of a specified language? I favor
the second option, as giving each field it's own toggle seems overly messy
and confusing for the end user.
Hope to hear from you soon. BTW, if you want to try out MT's default
implementation, simply replace all occurrences of TranslationAdmin with
TabbedExternalJqueryTranslationAdmin
in mezzanine.core.admin.
--
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: modeltranslations - round 2
Ok, changes are done. I tried something for inlines admin classes (mezzanine.core.admin), but I’m not sure wether it sounds right or not, let me know. Le lundi 9 juin 2014 02:37:44 UTC+2, Stephen McDonald a écrit : On Sun, Jun 8, 2014 at 6:15 PM, Mathias Ettinger mathias@gmail.com javascript: wrote: You’re pretty right, some design choices sound really bad when put like this. I’ll move the admin classes, the code_list and the frontend language selector somewhere else. Not bad per se, it's common for these things to involve some iterations :-) As for the TRANSLATED setting, I don’t recall exactly why I tied it with USE_I18N. If I’m correct, it is because django-modeltranslation deactivates itself when USE_I18N is False. So we can’t relly solely on USE_MODELTRANSLATION to know when translations are activated. I’ll check that by tomorow and let you know. But if it is the case, what is your suggested approach ? Force the USE_I18N to True if USE_MODELTRANSLATION is True ? Tighten TRANSLATED into settings instead of a global var ? So if modeltranslations needs USE_I18N then that's fine - let's just comment that in the code where we deal with it. I guess what I was getting at was that we should try and have this configurable via a single point, namely USE_MODELTRANSLATION - we can handle all the rest in set_dynamic_settings. There we can check if USE_MODELTRANSLATION is True and if so, also check that we can import modeltranslations, and then with that in place we can do the rest - set USE_I18N to True, and add modeltranslations to INSTALLED_APPS if missing. After that we can reliably use mezzanine.conf.settings.USE_MODELTRANSLATION *everywhere* to control integration (such as which admin class to use, what appears on the front-end, etc). Le samedi 7 juin 2014 12:09:02 UTC+2, Stephen McDonald a écrit : Ok I spent a bit of time going over the pull request and testing it, it's really good. I think we can tighten things up a little, for example we have `class SomeAdmin(TRANSLATED and TranslationAdmin or admin.ModelAdmin)` all through each of the admin modules. I think we could have a single BaseAdmin class with this logic that everything subclasses, rather than having conditions all throughout the code base. With that in place I figure it'd be pretty easy for us to modify that base class to include a snippet of jQuery with a single toggle (eg per screen, not per field, as Ed suggested) that shows/hides all the language fields. Also confused about the end of mezzanine/conf/__init__: TRANSLATED = settings.USE_MODELTRANSLATION and settings.USE_I18N CODE_LIST = [lang[0] for lang in settings.LANGUAGES] This isn't where settings should simply be dumped. CODE_LIST could possibly be a function in mezzanine.utils.translation. Does Django not have this already? More importantly I don't understand the relationship between USE_MODELTRANSLATION and USE_I18N, and why these get combined into another setting (which isn't consistently used throughout the PR, in same cases this combo of settings get checked separately again). Can't everything just check the USE_MODELTRANSLATION settings? If USE_I18N is needed for this to work, then that's what's set_dynamic_settings is for - fixing up missing things that the developer has intended to have working by providing a single point of configuration that hides away all the various bits that need configuring. In set_dynamic_settings we should simply check for USE_MODELTRANSLATION and if True, add modeltranslation app if missing, and if USE_I18N actually needs to be True for modeltranslation to work, set it to True as well. modeltranslation shouldn't be in INSTALLED_APPS by default either. Lastly we probably don't want the language chooser for the front-end site in the top nav, there's really no room there. Perhaps it could sit on the right-hand panel at the top somewhere along with the login bits, conditionally, if USE_MODELTRANSLATION is True. All of this stuff should be turned off by default which means USE_MODELTRANSLATION defaults to False and *everything* else stems from that. If I've stupidly overlooked anything please let me know. This looks real promising and I'm hoping this along with django-rest-framework integration will make a compelling offering for the next major release 3.2. I'm going to push 3.1.5 shortly with some bug fixes, and hopefully that'll be the last 3.1.x release. Thanks Mathias and Ed for working this all out, it looks really really good. On Sat, Jun 7, 2014 at 2:31 PM, Stephen McDonald st...@jupo.org wrote: Real odd, works fine for me now and no matter what I try I can't reproduce the error I had. On Sat, Jun 7, 2014 at 2:09 PM, Eduardo Rivas jeriva...@gmail.com wrote: Odd, I just created a project without issue. This is my venv: Django==1.6.5 Mezzanine==3.1.3 #From Mathias' branch Pillow
Re: [mezzanine-users] Re: modeltranslations - round 2
You’re pretty right, some design choices sound really bad when put like this. I’ll move the admin classes, the code_list and the frontend language selector somewhere else. As for the TRANSLATED setting, I don’t recall exactly why I tied it with USE_I18N. If I’m correct, it is because django-modeltranslation deactivates itself when USE_I18N is False. So we can’t relly solely on USE_MODELTRANSLATION to know when translations are activated. I’ll check that by tomorow and let you know. But if it is the case, what is your suggested approach ? Force the USE_I18N to True if USE_MODELTRANSLATION is True ? Tighten TRANSLATED into settings instead of a global var ? Le samedi 7 juin 2014 12:09:02 UTC+2, Stephen McDonald a écrit : Ok I spent a bit of time going over the pull request and testing it, it's really good. I think we can tighten things up a little, for example we have `class SomeAdmin(TRANSLATED and TranslationAdmin or admin.ModelAdmin)` all through each of the admin modules. I think we could have a single BaseAdmin class with this logic that everything subclasses, rather than having conditions all throughout the code base. With that in place I figure it'd be pretty easy for us to modify that base class to include a snippet of jQuery with a single toggle (eg per screen, not per field, as Ed suggested) that shows/hides all the language fields. Also confused about the end of mezzanine/conf/__init__: TRANSLATED = settings.USE_MODELTRANSLATION and settings.USE_I18N CODE_LIST = [lang[0] for lang in settings.LANGUAGES] This isn't where settings should simply be dumped. CODE_LIST could possibly be a function in mezzanine.utils.translation. Does Django not have this already? More importantly I don't understand the relationship between USE_MODELTRANSLATION and USE_I18N, and why these get combined into another setting (which isn't consistently used throughout the PR, in same cases this combo of settings get checked separately again). Can't everything just check the USE_MODELTRANSLATION settings? If USE_I18N is needed for this to work, then that's what's set_dynamic_settings is for - fixing up missing things that the developer has intended to have working by providing a single point of configuration that hides away all the various bits that need configuring. In set_dynamic_settings we should simply check for USE_MODELTRANSLATION and if True, add modeltranslation app if missing, and if USE_I18N actually needs to be True for modeltranslation to work, set it to True as well. modeltranslation shouldn't be in INSTALLED_APPS by default either. Lastly we probably don't want the language chooser for the front-end site in the top nav, there's really no room there. Perhaps it could sit on the right-hand panel at the top somewhere along with the login bits, conditionally, if USE_MODELTRANSLATION is True. All of this stuff should be turned off by default which means USE_MODELTRANSLATION defaults to False and *everything* else stems from that. If I've stupidly overlooked anything please let me know. This looks real promising and I'm hoping this along with django-rest-framework integration will make a compelling offering for the next major release 3.2. I'm going to push 3.1.5 shortly with some bug fixes, and hopefully that'll be the last 3.1.x release. Thanks Mathias and Ed for working this all out, it looks really really good. On Sat, Jun 7, 2014 at 2:31 PM, Stephen McDonald st...@jupo.org javascript: wrote: Real odd, works fine for me now and no matter what I try I can't reproduce the error I had. On Sat, Jun 7, 2014 at 2:09 PM, Eduardo Rivas jeriva...@gmail.com javascript: wrote: Odd, I just created a project without issue. This is my venv: Django==1.6.5 Mezzanine==3.1.3 #From Mathias' branch Pillow==2.4.0 South==0.8.4 argparse==1.2.1 bleach==1.4 django-debug-toolbar==1.2.1 django-modeltranslation==0.7.3 filebrowser-safe==0.3.3 future==0.9.0 grappelli-safe==0.3.10 html5lib==0.999 oauthlib==0.6.1 psycopg2==2.5.3 pytz==2014.4 requests==2.3.0 requests-oauthlib==0.4.0 six==1.6.1 sqlparse==0.1.11 tzlocal==1.0 wsgiref==0.1.2 I ran mezzanine-project and createdb --noinput. Have you done any other changes to settings? -- 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 -- 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: modeltranslations - round 2
I had some thoughts about what tests to add and how to write them. But everything lead to the same question: how is it possible to configure several languages for the tests without hardcoding them into settings.py? -- 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: HomePage with contact form
Isn’t it even simpler to just {% extends page/form.html %} in index.html ?
Le mardi 20 mai 2014 09:24:44 UTC+2, aleksiy a écrit :
Hello!
I created small contact form on Home page by may be wrong, but quite
simple way - without programming at all
1) Create regular mezzanine form in admin with URL contact-form,
2) Open form on site and look for fields names,
3) Hardcode form fields in index.html template using generated fields
names and action=/contact-form/ (and don't forget {% csrf_token %} )
works fine for me!
воскресенье, 18 мая 2014 г., 15:43:34 UTC+3 пользователь bob hosk написал:
I've made a custom HomePage model, so I can edit the home page content
(headers etc)
from the admin easily. I'm trying to add a 'Contact us' form to the
bottom of this page.
In my 'myproject/mytheme' dir I have 'page_processors.py' containing
from django import forms
from django.http import HttpResponseRedirect
from mezzanine.pages.page_processors import processor_for
from .models import HomePage
class ContactForm(forms.Form):
subject = forms.CharField(max_length=100, initial='The subject...',
required=True)
message = forms.CharField(max_length= 5000, widget=forms.Textarea,
initial='Hello, ', required=True)
sender = forms.EmailField(initial='Your e-mail...')
rchoices= (
('WORK','Hire Me'),
('PROB','Site problems'),
('OTH', 'Other'),
)
regarding = ChoiceField(widget=forms.Select(), choices=rchoices,
blank_choice='Regarding?', initial='blank_choice')
@processor_for(HomePage)
def contact_form(request, page):
form = ContactForm()
if request.method == 'POST':
form = ContactForm(request.POST)
if form.is_valid(): # All validation rules pass
subject = form.cleaned_data['subject']
message = form.cleaned_data['message']
sender = form.cleaned_data['sender']
recipients = ['m...@me.com']
print message
if cc_myself:
recipients.append(sender)
from django.core.mail import send_mail
send_mail(subject, message, sender, recipients)
redirect = request.path + ?submitted=true
return HttpResponseRedirect(redirect) # Redirect after POST
return {'form': form}
As for the template for the custom home page, it {% extends
pages/page.html %},
and at the bottom of the block I have
{{ block.super }}
{% if request.GET.sent %}
{% editable page.form.response %}
{{ page.form.response|richtext_filters|safe }}
{% endeditable %}
{% else %}
{% with page.form as page_form %}
{% editable page_form.content %}
{{ page_form.content|richtext_filters|safe }}
{% endeditable %}
{% endwith %}
{% errors_for form %}
form class=mezzanine-form method=post{% if form.is_multipart %}
enctype=multipart/form-data{% endif %}
{% fields_for form %}
div class=form-actions
input class=btn btn-primary btn-lg type=submit value={{
page.form.button_text }}
/div
/form
{% endif %}
which I copied from 'mezzanine/forms/templates/pages/form.html' mostly.
This gives a variable not found error when the homepage is loaded. If
instead I did
{% fields_for page.form %} then I don't get an error but nor do the
fields appear to be rendered.
How do I get this to work?
--
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: modeltranslations - round 2
I’m not sure what you’re implying about toggling the translation fields. If it is about shrinking every translation field into a single one with tabs for each language, go ahead. I know that django-modeltranslation is supposed to allow that but I never had it working. If it is about adding translation fields for conf.Setting that need them (instead of the patchy note that I added lately), I plan to do it this weekend. As regard to the tests, at first I thought that it wasn’t necessary since django-modeltranslation has its own test coverage. But adding a test for each of the 4 items that were corrected plus another one to check if the TRANSLATED flag is correctly set is a good start. Le mardi 20 mai 2014 03:10:07 UTC+2, Eduardo Rivas a écrit : Hey Mathias, a couple of points here. First, do you plan on working on the admin controls for toggling the different translations fields? I'm asking because I'll have some free time in the coming weeks, but I don't want to jump into it if you're planning on doing it yourself. Secondly, I wanted to share with you that recently an effort has started to improve Mezzanine's test coverage. It'd be great if you could write some tests for the features you've contributed; but if you're short on time, just coming up with a list of pending tests for model translation will be of great help. You can share it with me or Steve and they'll be added to the task list. Thanks a lot! 2014-05-19 10:04 GMT-06:00 Mathias Ettinger mathias@gmail.comjavascript: : I read a bit on ugettext and ugettext_lazy and I agree that we should not move everything to plain ugettext. Using ugettext for the default value seems perfectly acceptable though. Since pregenerated content into the database is populated using the default language translation, it is exactly the same behavior. And django-modeltranslation will copy value based on that translation anyway. (./manage.py update_translation_fields) I found the time to make a last change to the settings admin page. It’s far from perfect, I have an idea on how to make it more like pages with every fields exposed but not much time for that. And at least it’s better than nothing. -- You received this message because you are subscribed to a topic in the Google Groups Mezzanine Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/VXVfCU8OFGk/unsubscribe . To unsubscribe from this group and all its topics, send an email to mezzanine-use...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- 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: modeltranslations - round 2
Well, since it is now possible to mark settings for translation I thought it would be a good idea to use it on SHOP_CURRENCY_LOCALE too. Obviously non-editable settings don’t have a ``Setting`` instance and are thus non-translatable. So I made SHOP_CURRENCY_LOCALE editable too. Since ``mezzanine.conf.settings`` manages it I such a way that if the setting is defined in settings.py it is considered non-editable whatever ``register_setting`` says, I guess it does not change anything when upgrading mezzanine/cartridge. If SHOP_CURRENCY_LOCALE was defined in settings.py, it will still keep its value, otherwise it won't have any value and will fallback for the systeme locale for any language. But the latter will enable the translatable admin. But I can be wrong. As for South, the issue is exactly the same than field injection: http://mezzanine.jupo.org/docs/model-customization.html#field-injection-caveats Either you use the same solution, or you use the management commands provided by django-modeltranslation (./manage.py sync-translation-fields and optionnaly ./manage.py update-translation-fields). Le jeudi 15 mai 2014 03:38:03 UTC+2, Eduardo Rivas a écrit : Aaaahh, I get what you mean for #1, and yes, changing the value in non-default languages to something other than the direct translation of Submit fixes it. #2 and #4 look like they've been fixed, thanks a lot. #5 is looking pretty great. However, I don't thinks SHOP_CURRENCY_LOCALE should be translatable, since it is not editable, and non-editable settings don't have DB entries (I think). The other problem I see is that users will have to run python manage.py schemamigration conf --auto every time they add a new language. Also, these migrations seem to be stored in Mezzanine's source so they might be a problem for upgrades and deployment. At least that's what I had to do to get rid of a column does not exist error. Am I missing something? -- 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: modeltranslations - round 2
Before I push a fix for #1 in my master, I have a question. But first, the patch: https://github.com/Kniyl/mezzanine/commit/4fdd125046a402054e6c9e12418f7997df5b146a As you can see, the fix is simply to use ugettext instead of ugettext_lazy for the default value. And (fortunately?) the mezzanine.form.models.Form.button_text field is the only one to define a default value that is a translation string. My question, though, is: “Should we keep this default value?” because, in the end, django-modeltranslation will populate all the fields with the active language translation of that string. It is however possible to keep the default value when mezzanine.conf.TRANSLATED is False. I have an other question about the use of ugettext_lazy in the first place. I’m wondering why it is required and if it wouldn’t be easier to just import ugettext as _ instead of ugettext_lazy. I might confess that I’m not well aware of their differences. Le jeudi 15 mai 2014 10:57:13 UTC+2, Mathias Ettinger a écrit : Well, since it is now possible to mark settings for translation I thought it would be a good idea to use it on SHOP_CURRENCY_LOCALE too. Obviously non-editable settings don’t have a ``Setting`` instance and are thus non-translatable. So I made SHOP_CURRENCY_LOCALE editable too. Since ``mezzanine.conf.settings`` manages it I such a way that if the setting is defined in settings.py it is considered non-editable whatever ``register_setting`` says, I guess it does not change anything when upgrading mezzanine/cartridge. If SHOP_CURRENCY_LOCALE was defined in settings.py, it will still keep its value, otherwise it won't have any value and will fallback for the systeme locale for any language. But the latter will enable the translatable admin. But I can be wrong. As for South, the issue is exactly the same than field injection: http://mezzanine.jupo.org/docs/model-customization.html#field-injection-caveats Either you use the same solution, or you use the management commands provided by django-modeltranslation (./manage.py sync-translation-fields and optionnaly ./manage.py update-translation-fields). Le jeudi 15 mai 2014 03:38:03 UTC+2, Eduardo Rivas a écrit : Aaaahh, I get what you mean for #1, and yes, changing the value in non-default languages to something other than the direct translation of Submit fixes it. #2 and #4 look like they've been fixed, thanks a lot. #5 is looking pretty great. However, I don't thinks SHOP_CURRENCY_LOCALE should be translatable, since it is not editable, and non-editable settings don't have DB entries (I think). The other problem I see is that users will have to run python manage.py schemamigration conf --auto every time they add a new language. Also, these migrations seem to be stored in Mezzanine's source so they might be a problem for upgrades and deployment. At least that's what I had to do to get rid of a column does not exist error. Am I missing something? -- 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: modeltranslations - round 2
I learned something from #5. I’ll try to play with conf.models and see what happens. For #1, I was simply suggesting to change the text of the button. At least for my setup, when the text is “Submit” for the english language or “Wyślij” for polish, it display the french (default) button_text field whatever the active language is. But if I change the text to something else, it gets displayed properly. Le mardi 13 mai 2014 22:49:28 UTC+2, Eduardo Rivas a écrit : Sorry, I didn't understand your explanation on point 1. Could you elaborate a little bit more? The issue I was describing is that the Submit button is not showing the active language text in the form, but rather the default language value. About number 2, I actually had this working a while back using Django's set_languagehttps://docs.djangoproject.com/en/dev/topics/i18n/translation/#set-language-redirect-viewview. I created a gist https://gist.github.com/jerivas/8f9873c36cd8a895cd4a with some code that can go directly into base.html or (even better) in a small template in includes/. Please note that settings.USE_I18N must be included in TEMPLATE_ACCESSIBLE_SETTINGS. Finally, the reason I brought up #5 was because some Settings are indeed model instances stored in the database. See: https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/conf/models.py. However, they are a special case, as we wouldn't want to translate all Settings instances. It would be good to include it in the ToDo just to keep it in mind. -- 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: modeltranslations - round 2
commits for #2 and #4 have been pushed Le mercredi 14 mai 2014 13:28:06 UTC+2, Mathias Ettinger a écrit : I learned something from #5. I’ll try to play with conf.models and see what happens. For #1, I was simply suggesting to change the text of the button. At least for my setup, when the text is “Submit” for the english language or “Wyślij” for polish, it display the french (default) button_text field whatever the active language is. But if I change the text to something else, it gets displayed properly. Le mardi 13 mai 2014 22:49:28 UTC+2, Eduardo Rivas a écrit : Sorry, I didn't understand your explanation on point 1. Could you elaborate a little bit more? The issue I was describing is that the Submit button is not showing the active language text in the form, but rather the default language value. About number 2, I actually had this working a while back using Django's set_languagehttps://docs.djangoproject.com/en/dev/topics/i18n/translation/#set-language-redirect-viewview. I created a gist https://gist.github.com/jerivas/8f9873c36cd8a895cd4a with some code that can go directly into base.html or (even better) in a small template in includes/. Please note that settings.USE_I18N must be included in TEMPLATE_ACCESSIBLE_SETTINGS. Finally, the reason I brought up #5 was because some Settings are indeed model instances stored in the database. See: https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/conf/models.py. However, they are a special case, as we wouldn't want to translate all Settings instances. It would be good to include it in the ToDo just to keep it in mind. -- 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: modeltranslations - round 2
1. Well… In fact they are. But for some reason if the text is the active translation for submit, then the default language field is displayed (i.e: if my default language is french and I have Envoyer [fr]/Submit [en]/Wyślij [pl] then Envoyer will be displayed for each languages. But Submission and W ysłać will be displayed properly for english and polish). Be creative and change this one, it will display well. I haven’t found why it behave this way, though. 2. Good one, I’ll add one in core/templates/base.html 3. I tried but it is more complicated than the others since field name and database column name does not match. I have no idea if it is possible to achieve and I won’t have enought time to try it soon. Maybe something to keep in a ToDoList. 4. Oh! Never ran into this one but you’re completely right. I’ll see what I can do. 5. They are not model fields so django-modeltranslation can’t handle them. Le mardi 13 mai 2014 17:06:43 UTC+2, Eduardo Rivas a écrit : Thanks Mathias, it is working now. I've used the site a little bit more and my first impressions are that translation is working like a charm! I've only found some minor issues/implementation details: 1. Form submit button is not being translated. 2. How do frontend users change the language? Perhaps we need a dropdown similar to the one in the admin for the public site. 3. Are keywords going to be translated? Not sure if this is just a matter of registering the Keywords field for translation. 4. Slugs are generated from the active language, not the default language. This only applies to new items which have their Title set in more than one language. For example, let's say we are logged into the admin in Spanish (default is English), and we have a new Page, and fill the Title with Hello world! (English) and ¡Hola mundo! (Spanish). The Page will get the Slug hola-mundo instead of hello-world. 5. Site tagline and site title; should they be made translatable? -- 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: modeltranslations - round 2
I couldn't reproduce until I installed django-debug-toolbar. I’ll try to dig into it latter but can you confirm that uninstalling (or removing it from the settings) django-debug-toolbar solves the problem ? Le lundi 12 mai 2014 18:54:14 UTC+2, Eduardo Rivas a écrit : Ok, I finally got some time to try this out. I've never used Model Transaltion, so maybe I'm making some noob mistake. This is what I've done: mkvirtualenv modeltranslation git clone https://github.com/Kniyl/mezzanine.git mt-mezzanine cd mt-mezzanine pip install -e . pip install south django-modeltranslation django-debug-toolbar # cd to other folder mezzanine-project mt_test # Edit settings.py. Add USE_I18N = True, USE_L10N = True, add entries to LANGUAGES python manage.py createdb --noinput At this point, createdb fails with the following error: modeltranslation.translator.NotRegistered: The model RichTextPage is not registered for translation. See full tracebackhttp://pastebin.com/qqKEQZw1 . -- 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.
