Re: [mezzanine-users] Different Forms for Signup and Profile Update

[christian . kuper1]

That was indeed the way to go, thanks Steve for pointing me into the right 
direction. I discovered that the AccountForm class already has got an 
attribute _signup which does what you suggest. 

I subclassed the AccountForm. If I am not mistaken I had to hide the 
profile form fields during signup (not take them out all together during 
signup) in order to avoid a validation error.

The only small drawback left is that I haven't figured our how to make the 
optional fields "first_name" and "last_name" optional in the AccountForm.

Chris

Am Dienstag, 26. Januar 2016 23:53:18 UTC+1 schrieb Stephen McDonald:
>
> I'd suggest using a custom form class, and checking for a bound user 
> object in its __init__ method, which if present indicates it's the update 
> form, and not signup, and you can then modify the attributes of each field 
> programmatically. This would probably turn out to be less code that 
> defining a form class for each.
>
> On Wed, Jan 27, 2016 at 7:04 AM, 
> > wrote:
>
>> I want to allow new users to register to a mezzanine based site with 
>> minimal information (i.e. email and password) and allow them to update 
>> their profile information once they are registered. Therefore I would like 
>> to display a form with only the two required fields during signup and the 
>> "full" ProfileForm during profile_update. 
>>
>> Looking at the code in mezzanine.accounts I understand that "signup" view 
>> as well as the "profile_update" view use the same form (i.e. 
>> ACCOUNTS_PROFILE_FORM_CLASS). I know I could overcome this by writing my 
>> custom signup view but is there any other way to solve this so I can keep 
>> using the build-in code?
>>
>> If not: Would it make sense to allow the definition of different form 
>> classes for signup and profile_update? Many modern websites try to 
>> encourage registration by asking only for minimal information during 
>> registration but allow users to add addtional profile information later.
>>
>> Regards Chris
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Mezzanine Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to mezzanine-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Stephen McDonald
> http://jupo.org
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Different Forms for Signup and Profile Update

[christian . kuper1]

That was indeed the way to go, thanks Steve for pointing me into the right 
direction. I discovered that the AccountForm class already has got an 
attribute _signup which does what you suggest. 

I subclassed the AccountForm. If I am not mistaken I had to hide the 
profile form fields during signup (not take them out all together during 
signup) in order to avoid a validation error.

The only small drawback left is that I haven't figured our how to make the 
optional fields "first_name" and "last_name" optional in the AccountForm.

Chris

Am Dienstag, 26. Januar 2016 23:53:18 UTC+1 schrieb Stephen McDonald:
>
> I'd suggest using a custom form class, and checking for a bound user 
> object in its __init__ method, which if present indicates it's the update 
> form, and not signup, and you can then modify the attributes of each field 
> programmatically. This would probably turn out to be less code that 
> defining a form class for each.
>
> On Wed, Jan 27, 2016 at 7:04 AM, 
> > wrote:
>
>> I want to allow new users to register to a mezzanine based site with 
>> minimal information (i.e. email and password) and allow them to update 
>> their profile information once they are registered. Therefore I would like 
>> to display a form with only the two required fields during signup and the 
>> "full" ProfileForm during profile_update. 
>>
>> Looking at the code in mezzanine.accounts I understand that "signup" view 
>> as well as the "profile_update" view use the same form (i.e. 
>> ACCOUNTS_PROFILE_FORM_CLASS). I know I could overcome this by writing my 
>> custom signup view but is there any other way to solve this so I can keep 
>> using the build-in code?
>>
>> If not: Would it make sense to allow the definition of different form 
>> classes for signup and profile_update? Many modern websites try to 
>> encourage registration by asking only for minimal information during 
>> registration but allow users to add addtional profile information later.
>>
>> Regards Chris
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Mezzanine Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to mezzanine-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Stephen McDonald
> http://jupo.org
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Different Forms for Signup and Profile Update

[christian . kuper1]

I want to allow new users to register to a mezzanine based site with 
minimal information (i.e. email and password) and allow them to update 
their profile information once they are registered. Therefore I would like 
to display a form with only the two required fields during signup and the 
"full" ProfileForm during profile_update. 

Looking at the code in mezzanine.accounts I understand that "signup" view 
as well as the "profile_update" view use the same form (i.e. 
ACCOUNTS_PROFILE_FORM_CLASS). I know I could overcome this by writing my 
custom signup view but is there any other way to solve this so I can keep 
using the build-in code?

If not: Would it make sense to allow the definition of different form 
classes for signup and profile_update? Many modern websites try to 
encourage registration by asking only for minimal information during 
registration but allow users to add addtional profile information later.

Regards Chris

-- 
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: Production server works only when DEBUG=True else it throws internal server error

[christian . kuper1]

Have you set the ALLOWED_HOSTS setting correctly? This caused the problem 
with my first deployment

BR

Chris

Am Sonntag, 24. Januar 2016 18:02:48 UTC+1 schrieb Mani Kandan:
>
> After deployment, the production server throws Internal server error.
> After I included DEBUG=True, It is working
> Can anyone help me in this?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: Page Processor not being called

[christian . kuper1]

Hi Steve,

I haven't looked into your problem to deeply and am far from an expert. 
But: Are you sure the pageprocessor is not being called or is the 
pageprocessor not returning the correct result? The error code you posted 
says "Expected table or queryset, not 'str'.". Couldn't it be the 
pageprocessor is return an empty string? 

Chris

Am Freitag, 22. Januar 2016 05:27:15 UTC+1 schrieb Steve Harwin:
>
> Hi,
>
> I am not sure if my method for displaying a table of model data isthe best 
> way to do it, but i essentially followed the examples in the docs and on 
> this forum... unfortunately my page processor does not seem to be working. 
> Here is the code:
> In models.py:
> class GeolSitesList(Page):
> '''
> A page to list GeolSites
> '''
>  
> class Meta:
> verbose_name = _("Sites List")
> verbose_name_plural = _("Sites Lists")
> In tables.py:
> from ausgeolapp.models import *
> import django_tables2 as tables
> from django.utils.safestring import mark_safe
> from django.utils.html import escape
>
>
> class geolSitesTable(tables.Table):
> class Meta:
> model = geolsites
> exclude = ("geom", )
> attrs = {'class': 'SitesTable'}
> def render_site(self, value):
> return mark_safe(escape(value)+' width="300" src="http://ausgeol.utas.edu.au/data/public/AusGeolSites/'+
> escape(value)+'/'+escape(value)+'_thumb.jpg">')
> In page_processors.py:
> from mezzanine.pages.page_processors import processor_for
>
>
> from django.db import models
> from models import GeolSitesList
> from django.http import HttpResponse
> from django.template import loader
> from ausgeolapp.models import *
> from ausgeolapp.tables import geolSitesTable
> import django_tables2 as tables
>
>
> @processor_for(GeolSitesList)
> def geolSites_List(request, page):
> sitelist = geolsites.objects.all()
> sitelisttable = geolSitesTable(sitelist)
> sitelisttable.paginate(page=request.GET.get('page', 1), per_page=25)
> return {"sitelisttable": sitelisttable}
> I also tried: @processor_for("sites")
> In geolsiteslist.html
> {% extends "pages/page.html" %}
>
>
> {% load mezzanine_tags staticfiles %}
> {% block extra_assets %}
>   ="text/css" />
> {% endblock %}
> {% load django_tables2 %}
> {% block main %}
>
>
> {% render_table sitelisttable %}
> {% endblock %}
> I get the "Expected table or queryset, not 'str'." error because the 
> sitelisttable 
> is empty... the context is not being added because the page processor is 
> not being called. After hunting for suggestions I added the following to 
> urls.py:
> from mezzanine.pages import page_processors
>
>
> page_processors.autodiscover()
> and also tried adding this to my url patterns but it made no difference 
> and I would have thought it was not needed since I am adding a 
> GeolSitesList page via mezzanine admin (the page is called 'sites'):
> url("^sites/$", "mezzanine.pages.views.page", {"slug": "sites"},  name=
> "GeolSitesList"),
>
> and I tried this as well
> url("^sites/$", "mezzanine.pages.views.page", {"slug": "sites"},  name=
> "sites"),
>
> I am not sure what else to try... please can someone point me to my 
> mistake. I am using Python 3.3, Postgresql 9.4 (PostGIS 2), Django 1.8.6, 
> Mezzanine 4.0.1, and the latest django-tables2.
> Thanks,
> Steve
>
>
>

-- 
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] UnicodeDecodeError in Mezzanine ThreadedComments

[christian . kuper1]

Hello Stephen,

thank you for your reply! The Django docs 
 
indeed cover this and these settings were my first suspect. However, these 
settings are set correctly (by the mod_wsgi-express) so that doesn't seem 
to be the issue. I was wondering whether it has something to do with the 
ticket mentioned it in the source code.

I dug a little deeper and the following question cam to my mind: Why does 
mezzanine use a "str" to set the "expires" date (expires = datetime.strftime
(...))? I believe the Django set_cookie method (in django.http.response) 
also accepts datetime objects. I tested it changing the code in 
mezzanine.utils.views from

expires = datetime.strftime(datetime.utcnow() +
timedelta(seconds=expiry_seconds),
"%a, %d-%b-%Y %H:%M:%S GMT")



to

expires = datetime.utcnow() + timedelta(seconds=expiry_seconds)


As expected this change also solves the problem.


Regards

Chris

Am Montag, 21. Dezember 2015 00:04:16 UTC+1 schrieb Stephen McDonald:
>
> You might be missing the correct LOCALE settings for Apache - I think the 
> Django docs cover this.
>
> On Fri, Dec 18, 2015 at 8:27 PM, 
> > wrote:
>
>> I am working on a project which uses ThreadedComments in a couple of apps 
>> (Mezzanine Blog and a discussion forum). All was working fine in the 
>> development and production environment but from one day to the next posting 
>> a comment raised an Internal Server Error (500).
>>
>> My setup: Mezzanine 4.01, Django 1.8.5, Python 2.7.6. The production 
>> environment is a Ubuntu 14.04 server, Apache webserver. Mezzanine is 
>> deployed using mod_wsgi-express. Mezzanine is set up using "German" as 
>> language.
>>
>> The error log created by the server gives me the following:
>>
>> Traceback (most recent call last):
>> [Thu Dec 17 21:08:23.317452 2015] [wsgi:error] [pid 30806:tid 
>> 140269963933440] [remote 95.90.251.8:24357]   File 
>> "/home/chris/IT/Portal/veportal/local/lib/python2.7/site-packages/mod_wsgi-4.4.15-py2.7-linux-x86_64.egg/mod_wsgi/server/__init__.py"
>> , line 1346, in handle_request
>> [Thu Dec 17 21:08:23.317902 2015] [wsgi:error] [pid 30806:tid 
>> 140269963933440] [remote 95.90.251.8:24357] return self.application(
>> environ, start_response)
>> [Thu Dec 17 21:08:23.317919 2015] [wsgi:error] [pid 30806:tid 
>> 140269963933440] [remote 95.90.251.8:24357]   File 
>> "/home/chris/IT/Portal/veportal/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py"
>> , line 195, in __call__
>> [Thu Dec 17 21:08:23.317982 2015] [wsgi:error] [pid 30806:tid 
>> 140269963933440] [remote 95.90.251.8:24357] response_headers.append((
>> str('Set-Cookie'), str(c.output(header=''
>> [Thu Dec 17 21:08:23.317993 2015] [wsgi:error] [pid 30806:tid 
>> 140269963933440] [remote 95.90.251.8:24357]   File 
>> "/usr/lib/python2.7/Cookie.py", line 466, in output
>> [Thu Dec 17 21:08:23.318106 2015] [wsgi:error] [pid 30806:tid 
>> 140269963933440] [remote 95.90.251.8:24357] return "%s %s" % ( header
>> , self.OutputString(attrs) )
>> [Thu Dec 17 21:08:23.318116 2015] [wsgi:error] [pid 30806:tid 
>> 140269963933440] [remote 95.90.251.8:24357]   File 
>> "/usr/lib/python2.7/Cookie.py", line 514, in OutputString
>> [Thu Dec 17 21:08:23.318128 2015] [wsgi:error] [pid 30806:tid 
>> 140269963933440] [remote 95.90.251.8:24357] return _semispacejoin(
>> result)
>> [Thu Dec 17 21:08:23.318143 2015] [wsgi:error] [pid 30806:tid 
>> 140269963933440] [remote 95.90.251.8:24357] UnicodeDecodeError: 'ascii' 
>> codec can't decode byte 0xc3 in position 16: ordinal not in range(128)
>>
>> After some digging I found that this error was caused by the "set_cookie" 
>> method in mezzanine.utils.views. When creating the "expires" date the 
>> locale de_DE, utf-8 is used by strftime and the month of March in German 
>> contains a non ASCII character (i.e. "Umlaut"). Therefore the error only 
>> pops up if a cookie with expiry "March" is set.
>>
>> For testing purposes I tried running my project using the Django 
>> development server in the production environment - strangely enough I did 
>> NOT get the error there.
>>
>> As a quick fix I temporarily set the locale back to en_US, utf-8 before 
>> setting the cookie using this 
>> 
>>  
>> approach; i.e. mezzanine.utils.views like so:
>>
>> # This is a hack to avoid unicode decode errors caused on the production 
>> server
>> # by a german expiry date
>>
>> import locale
>> import threading
>>
>> from contextlib import contextmanager
>>
>>
>> LOCALE_LOCK = threading.Lock()
>>
>> @contextmanager
>> def setlocale(name):
>> with LOCALE_LOCK:
>> saved = locale.setlocale(locale.LC_ALL)
>> try:
>> yield locale.setlocale(locale.LC_ALL, name)
>> finally:
>> locale.setlocale(locale.LC_ALL

[mezzanine-users] Re: drum fields_for richtext wysiwyg

[christian . kuper1]

Hi,

I solved this in my app making the "description" field a TinyMceWidget:

BaseLinkForm = modelform_factory(Link, fields=["title", "description"], 
widgets={'description': TinyMceWidget()})


Regards

Chris

Am Samstag, 19. Dezember 2015 21:45:22 UTC+1 schrieb Icham Achtir:
>
> hi,
>
> i am new mezzanine & drum user,
>
> i am trying to add a richtextfield fields to drum, everything work in the 
> admin  (showing tinymce).
> But i am not able to show tinymce wysiwyg add link page for user.
> on the source page no tinymce js & css
>
> my code :
> class LinkForm(BaselinkForm):
>
> def clean(self):
> link = self.cleaned_data.get("link", None)
> description = self.cleaned_data.get("description", None)
> if not link and not description:
> raise ValidationError("Either a link or description is 
> required")
> return self.cleaned_data
>
> class Media:
> css = {'all': ('/static/mezzanine/tinymce/tinymce.css',)}
> js = ('/static/mezzanine/tinymce/tinymce.min.js',
>   '/static/mezzanine/js/tinymce_setup.js',)
>
>
> Could you help ?
>
>
>
>

-- 
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: Wiki for Mezzaine

[christian . kuper1]

Hi Sathishkumar,

could you elaborate a little on features you are looking for and missing in 
MezzanineWiki? I normally use the plugins as a basis for my own 
customization and rescently installed mezzanine-wiki without much problems.

IMHO even Mezzanine as it is provides many "Wiki like" features.

Regards

Chris

Am Dienstag, 15. Dezember 2015 17:36:18 UTC+1 schrieb Sathishkumar 
Duraisamy:
>
> Hi All,
>
> The https://github.com/dfalk/mezzanine-wiki is not active. What is good 
> wiki for mezzaine? 
>
> -- 
> Regards,
> Sathishkumar D
>

-- 
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] UnicodeDecodeError in Mezzanine ThreadedComments

[christian . kuper1]

I am working on a project which uses ThreadedComments in a couple of apps 
(Mezzanine Blog and a discussion forum). All was working fine in the 
development and production environment but from one day to the next posting 
a comment raised an Internal Server Error (500).

My setup: Mezzanine 4.01, Django 1.8.5, Python 2.7.6. The production 
environment is a Ubuntu 14.04 server, Apache webserver. Mezzanine is 
deployed using mod_wsgi-express. Mezzanine is set up using "German" as 
language.

The error log created by the server gives me the following:

Traceback (most recent call last):
[Thu Dec 17 21:08:23.317452 2015] [wsgi:error] [pid 30806:tid 
140269963933440] [remote 95.90.251.8:24357]   File 
"/home/chris/IT/Portal/veportal/local/lib/python2.7/site-packages/mod_wsgi-4.4.15-py2.7-linux-x86_64.egg/mod_wsgi/server/__init__.py"
, line 1346, in handle_request
[Thu Dec 17 21:08:23.317902 2015] [wsgi:error] [pid 30806:tid 
140269963933440] [remote 95.90.251.8:24357] return self.application(
environ, start_response)
[Thu Dec 17 21:08:23.317919 2015] [wsgi:error] [pid 30806:tid 
140269963933440] [remote 95.90.251.8:24357]   File 
"/home/chris/IT/Portal/veportal/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py"
, line 195, in __call__
[Thu Dec 17 21:08:23.317982 2015] [wsgi:error] [pid 30806:tid 
140269963933440] [remote 95.90.251.8:24357] response_headers.append((str
('Set-Cookie'), str(c.output(header=''
[Thu Dec 17 21:08:23.317993 2015] [wsgi:error] [pid 30806:tid 
140269963933440] [remote 95.90.251.8:24357]   File 
"/usr/lib/python2.7/Cookie.py", line 466, in output
[Thu Dec 17 21:08:23.318106 2015] [wsgi:error] [pid 30806:tid 
140269963933440] [remote 95.90.251.8:24357] return "%s %s" % ( header, 
self.OutputString(attrs) )
[Thu Dec 17 21:08:23.318116 2015] [wsgi:error] [pid 30806:tid 
140269963933440] [remote 95.90.251.8:24357]   File 
"/usr/lib/python2.7/Cookie.py", line 514, in OutputString
[Thu Dec 17 21:08:23.318128 2015] [wsgi:error] [pid 30806:tid 
140269963933440] [remote 95.90.251.8:24357] return _semispacejoin(result
)
[Thu Dec 17 21:08:23.318143 2015] [wsgi:error] [pid 30806:tid 
140269963933440] [remote 95.90.251.8:24357] UnicodeDecodeError: 'ascii' 
codec can't decode byte 0xc3 in position 16: ordinal not in range(128)

After some digging I found that this error was caused by the "set_cookie" 
method in mezzanine.utils.views. When creating the "expires" date the 
locale de_DE, utf-8 is used by strftime and the month of March in German 
contains a non ASCII character (i.e. "Umlaut"). Therefore the error only 
pops up if a cookie with expiry "March" is set.

For testing purposes I tried running my project using the Django 
development server in the production environment - strangely enough I did 
NOT get the error there.

As a quick fix I temporarily set the locale back to en_US, utf-8 before 
setting the cookie using this 

 
approach; i.e. mezzanine.utils.views like so:

# This is a hack to avoid unicode decode errors caused on the production 
server
# by a german expiry date

import locale
import threading

from contextlib import contextmanager


LOCALE_LOCK = threading.Lock()

@contextmanager
def setlocale(name):
with LOCALE_LOCK:
saved = locale.setlocale(locale.LC_ALL)
try:
yield locale.setlocale(locale.LC_ALL, name)
finally:
locale.setlocale(locale.LC_ALL, saved)


# End of hack


def set_cookie(response, name, value, expiry_seconds=None, secure=False):
"""
Set cookie wrapper that allows number of seconds to be given as the
expiry time, and ensures values are correctly encoded.
"""
if expiry_seconds is None:
expiry_seconds = 90 * 24 * 60 * 60  # Default to 90 days.
# Set back locale to avoid UnicodeDecodeError
with setlocale(('en', 'utf-8')):
expires = datetime.strftime(datetime.utcnow() +
timedelta(seconds=expiry_seconds),
"%a, %d-%b-%Y %H:%M:%S GMT")
# Django doesn't seem to support unicode cookie keys correctly on
# Python 2. Work around by encoding it. See
# https://code.djangoproject.com/ticket/19802
try:
response.set_cookie(name, value, expires=expires, secure=secure)
except (KeyError, TypeError):
response.set_cookie(name.encode('utf-8'), value, expires=expires,
secure=secure)

Although things seem to be working now I do not think fiddling with core 
code  is a good idea. I am not even sure whether this is really a Mezzanine 
issue or whether it has something todo with Apache, mod_wsgi or an issue 
with the setup of the production server as such.

Any thoughts welcome.

Regards

Chris




-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop rece

[mezzanine-users] Code error in cartridge.shop.checkout.initial_order_data

[christian . kuper1]

Hello There,

as I am just starting to get familiar with Mezzanine and Cartridge I feel a 
little reluctant to file an issue right away. However, I believe there is a 
code error in checkout.py of cartridge, line 133. 

The current code:


133: for order_field in OrderForm._meta.fields:

The result is that initial_order_data() will only try to pre-fill fields 
contained in the default OrderForm and no additional fields used in 
customized order forms.

IMHO the line should say:

133: for order_field in form_class._meta.fields:


Or did I overlook something here?

Chris


-- 
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.