[mezzanine-users] Re: Mezzanine CKEditor skin

[Radomir Wojcik]

Would love to see ckeditor replace TinyMCE in Mezzanine.

-- 
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/groups/opt_out.

[mezzanine-users] Re: FileSystemEncodingChanged exceptions

[Radomir Wojcik]

>
> I ran into this problem today, and I don't use supervisor, nor do I use 
> gunicorn. Today I switched to gunicorn though cuz I couldn't figure out 
> what was going on. There were no issues in dev mode when I ran the server 
> using runserver. The issues weren't obvious even when running the uwsgi 
> server from command line, it "seemed" to work, but there was a complete 
> issue when trying to run it as a service using upstart...  I should 
> probably use the same stack everyone else is using and learn the fab file 
> that comes with.. But anyways, I switched to gunicorn and it worked as a 
> service so I thought ok problem solved. But then I got the Local Changed 
> error.  What fixed it for me was exporting all these locale variables as 
> described above using export.  Now even uwsgi is working great now.. I'm 
> still sticking to sockets but I'll use gunicorn just to be safe.  I thought 
> uWSGI was supposed to be faster thats why I was using it.  I don't know 
> much about supervisor so I use upstart, and I use sockets because its 
> slightly faster (no TCP/IP overhead).

 

export LANG=en_US.UTF-8, LC_ALL=en_US.UTF-8, LC_LANG=en_US.UTF-8

exec gunicorn -k eventlet ${DJANGO_WSGI_MODULE}:application \
  --name $NAME \
  --workers $NUM_WORKERS \
  --log-level=debug \
  --bind=unix:$SOCKFILE 

-- 
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/groups/opt_out.

Re: [mezzanine-users] Re: step by step mezzanine deployment

[Ross Laird]

Glad you got it to work.
Web development is always an adventure...

On Wednesday, 5 March 2014 14:26:49 UTC-8, Federico Bruni wrote:
>
> 2014-03-05 17:25 GMT+01:00 Federico Bruni 
> >:
>
>> I'll try again from scratch a new project and set up immediately 
>> PostgreSQL also in local_settings.py, before running 'manage.py createdb'.
>>  
>>
> I've done the sync local>server manually, set up nginx on the server and 
> started mezzanine in background. Everything works fine finally!
> It was probably something related to the live settings. I'll try again a 
> deployment with fabric as soon as I have time.
>
> Big thank to Ross, who found the good words to put me on the right track.
>
>

-- 
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/groups/opt_out.

Re: [mezzanine-users] Re: step by step mezzanine deployment

[Federico Bruni]

2014-03-05 17:25 GMT+01:00 Federico Bruni :

> I'll try again from scratch a new project and set up immediately
> PostgreSQL also in local_settings.py, before running 'manage.py createdb'.
>
>
I've done the sync local>server manually, set up nginx on the server and
started mezzanine in background. Everything works fine finally!
It was probably something related to the live settings. I'll try again a
deployment with fabric as soon as I have time.

Big thank to Ross, who found the good words to put me on the right track.

-- 
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/groups/opt_out.

Re: [mezzanine-users] Re: admin translate_url throwing NoReverseMatch on '../auth/user/2/password/"

[David Kaylor]

I was experiencing the same issue and applied this change:

https://github.com/stephenmcd/mezzanine/commit/6956db15e0466c5d0bcfb3379e7c96254c0f292d

I had to modify it further to fix my problem though. I have a custom user 
model defined with AUTH_USER_MODEL, so the following pattern doesn't work 
for me:

"^auth/user/(\d+)/password/$"

I need to use a pattern like this:

"^app/model/(\d+)/password/$"

With that change, everything is working fine, but it specific to my site.

Regards,
Dave

On Tuesday, February 11, 2014 7:18:33 PM UTC-5, Stephen McDonald wrote:
>
> Thanks guys, here's the fix:
>
>
> https://github.com/stephenmcd/mezzanine/commit/008926f8fb28c66e14d54721436a565b0f73959f
>
>
>
>
> On Wed, Feb 12, 2014 at 10:22 AM, Geoffrey Sechter 
> 
> > wrote:
>
>> I'm hitting the same error as well. I was using 3.0.6, just upgraded to 
>> 3.0.9 but the issue is persisting.
>>
>> On Monday, February 10, 2014 4:32:32 AM UTC-5, Jacob wrote:
>>>
>>>
>>> Hello,
>>>
>>> While attempting to change a users password on the admin page this error 
>>> is thrown:
>>>

 *Exception Type: NoReverseMatch*
 *Exception Value: **Reverse for 
 'django.contrib.auth.admin.user_change_password' with arguments '(u'2',)' 
 and keyword arguments '{}' not found. 0 pattern(s) tried: []*
>>>
>>>
>>> Traceback points to mezzanine/core/templatetags/mezzanine_tags.py in 
>>> translate_url:
>>>
>>>1. 
>>>
>>>translation.activate(language)
>>>
>>>2. 
>>>
>>>try:
>>>
>>>3. 
>>>
>>>url_name = (view.url_name if not view.namespace
>>>
>>>4. 
>>>
>>>else '%s:%s' % (view.namespace, view.url_name))
>>>
>>>5. 
>>>
>>>url = reverse(url_name, args=view.args, kwargs=view.kwargs)
>>>
>>>6. 
>>>
>>>except NoReverseMatch:
>>>
>>>7. 
>>>
>>>url_name = "admin:" + view.url_name
>>>
>>>
>>>
>>>1. 
>>>
>>>url = reverse(url_name, args=view.args, kwargs=view.kwargs)
>>>
>>>...
>>>
>>>
>>>1. 
>>>
>>>translation.activate(current_language)
>>>
>>>2. 
>>>
>>>if context['request'].META["QUERY_STRING"]:
>>>
>>>3. 
>>>
>>>url += "?" + context['request'].META["QUERY_STRING"]
>>>
>>>4. 
>>>
>>>return url
>>>
>>>
>>>
>>> My urls.py:
>>>

 *urlpatterns = patterns('',*
 *(r'^i18n/', include('django.conf.urls.i18n')),*
 *)*
 *urlpatterns += solid_i18n_patterns("",*
 * (..., include(admin.site.urls)), ** ...* 
>>>
>>>  
>>> I'm using mez 3.0.8, solid i18n patterns, two languages with USE_I18N = 
>>> True. However I removed solid i18n integration yet the error still 
>>> persists. 
>>>
>>> The admin dropdown language selector appears to be working normally and 
>>> modifies the url/language but removing the translate_url code bypasses the 
>>> error.. Furthermore I can change the password of the current user as well 
>>> as add new users. 
>>>
>>> I had a look at https://github.com/stephenmcd/mezzanine/issues/901 but 
>>> I can't make sense of it.
>>>
>>> Any ideas? Do I have something setup incorrectly?
>>>
>>> Thanks!
>>> -Jacob
>>>
>>>
>>>
>>> Full traceback below...
>>>
>>>
>>> Traceback (most recent call last):
   File "/home/vagrant/.virtualenvs/mez/local/lib/python2.7/site-
 packages/django/core/handlers/base.py", line 139, in get_response
 response = response.render()
   File "/home/vagrant/.virtualenvs/mez/local/lib/python2.7/site-
 packages/django/template/response.py", line 105, in render
 self.content = self.rendered_content
   File "/home/vagrant/.virtualenvs/mez/local/lib/python2.7/site-
 packages/django/template/response.py", line 82, in rendered_content
 content = template.render(context)
   File "/home/vagrant/.virtualenvs/mez/local/lib/python2.7/site-
 packages/django/template/base.py", line 140, in render
 return self._render(context)
   File "/home/vagrant/.virtualenvs/mez/local/lib/python2.7/site-
 packages/django/test/utils.py", line 85, in instrumented_test_render
 return self.nodelist.render(context)
   File "/home/vagrant/.virtualenvs/mez/local/lib/python2.7/site-
 packages/django/template/base.py", line 840, in render
 bit = self.render_node(node, context)
   File "/home/vagrant/.virtualenvs/mez/local/lib/python2.7/site-
 packages/django/template/debug.py", line 78, in render_node
 return node.render(context)
   File "/home/vagrant/.virtualenvs/mez/local/lib/python2.7/site-
 packages/django/template/loader_tags.py", line 123, in render
 return compiled_parent._render(context)
   File "/home/vagrant/.virtualenvs/mez/local/lib/python2.7/site-
 packages/django/test/utils.py", line 85, in instrumented_test_render
 return self.nodelist.render(context)
   File "/home/vagr

[mezzanine-users] Re: can anyone suggest me some host which is Australia based and also mezzanine&django friendly?

[Sam W]

Rackspace has Sydney servers, if that's sufficient for what you want. 

On Tuesday, March 4, 2014 12:43:43 AM UTC+13, lu zou wrote:
>
> As above ,can anyone suggest me some host which is Australia based and 
> also mezzanine&django friendly? :)
>

-- 
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/groups/opt_out.

Re: [mezzanine-users] Re: Admin navigation

[Stephen McDonald]

Nice - definitely use the cookie, same pattern is in the page menu


On Thu, Mar 6, 2014 at 8:22 AM, Eduardo Rivas wrote:

> But wait, there's more! :) I have something that narrow screen users will
> appreciate. The panel now can be hidden to give the content full width.
> Only problem is panel state won't persist between page loads. I'm thinking
> on adding a cookie to the session and check it to determine the panel
> state. Will be ready soon.
>
> --
> 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/groups/opt_out.
>



-- 
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/groups/opt_out.

[mezzanine-users] Re: Admin navigation

[Eduardo Rivas]

But wait, there's more! :) I have something that narrow screen users will 
appreciate. The panel now can be hidden to give the content full width. 
Only problem is panel state won't persist between page loads. I'm thinking 
on adding a cookie to the session and check it to determine the panel 
state. Will be ready soon.

-- 
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/groups/opt_out.

Re: [mezzanine-users] Re: Admin navigation

[Stephen McDonald]

Demo site is now updated with a ton of fixes Ed has made (thanks!) as well
as a new theme for tinymce.


On Thu, Mar 6, 2014 at 7:08 AM, Stephen McDonald  wrote:

> I think it'd be more appropriate if the user could toggle this themselves,
> I just wasn't sure how to implement it visually so I conceded to a regular
> site setting.
>
>
> On Thu, Mar 6, 2014 at 6:38 AM, Eduardo Rivas wrote:
>
>> Sorry about the noise. I just noticed it depends on a setting.
>>
>> --
>> 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/groups/opt_out.
>>
>
>
>
> --
> 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/groups/opt_out.

Re: [mezzanine-users] Re: Admin navigation

[Stephen McDonald]

I think it'd be more appropriate if the user could toggle this themselves,
I just wasn't sure how to implement it visually so I conceded to a regular
site setting.


On Thu, Mar 6, 2014 at 6:38 AM, Eduardo Rivas wrote:

> Sorry about the noise. I just noticed it depends on a setting.
>
> --
> 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/groups/opt_out.
>



-- 
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/groups/opt_out.

Re: [mezzanine-users] CSRF fails on login during automated testing. Issue with caching on non-anonymous?

[Stephen McDonald]

Ah so potentially you just need to add the nevercache tag around the csrf
token? That would be a relief to know it all works, please let us know.


On Thu, Mar 6, 2014 at 4:25 AM,  wrote:

>
> Thanks for the answer.  You are entirely right.  I had forgotten that I
> overrode mezzanine's account forms as per the instructions here:
>
> http://mezzanine.jupo.org/docs/frequently-asked-questions.html#where-are-all-the-templates-i-can-modify
>
>
> ...and the issue only showed up when caching was turned on in a 'real'
> environment.
>
> Jennifer
>
>
> On Tuesday, March 4, 2014 3:24:56 PM UTC-8, Stephen McDonald wrote:
>
>> There are a few moving parts here, my guess is something failing in the
>> last of these:
>>
>> By default in Mezzanine, forms use the "fields_for" template tag, which
>> is just a helper for rendering forms: https://github.com/
>> stephenmcd/mezzanine/blob/master/mezzanine/core/templates/includes/form_
>> fields.html
>>
>> You'll see at the top of its template, it uses the "nevercache" tag which
>> is fairly self explanatory - it's wrapped around the csrf token so that
>> it's never cached.
>>
>> Then finally you'll see in both phases of the caching middleware, special
>> handling of the csrf token is required:
>>
>> https://github.com/stephenmcd/mezzanine/blob/master/
>> mezzanine/core/middleware.py#L169-L181
>> https://github.com/stephenmcd/mezzanine/blob/master/
>> mezzanine/core/middleware.py#L210-L213
>>
>> It's likely that last part is somehow incompatible with LiveServerTestCase
>> - I personally haven't used that before, but with regular Django test cases
>> I've experienced a lot of differences in how sessions, request objects and
>> everything related, actually work, compared to an actual running site.
>>
>> My advice would be to first verify these forms actually work for you in
>> production, so that you can isolate this issue down to testing only, and
>> then unless you're feeling particularly adventurous, disable caching for
>> those particular tests that are failing - I understand there's a decorator
>> in Django for modifying settings per test, but the name escapes me.
>>
>> Good luck!
>>
>>
>>
>>  On Wed, Mar 5, 2014 at 9:48 AM,  wrote:
>>
>>> Hi,
>>>
>>> I'm using LiveServerTestCase, as described 
>>> here,
>>> to automate remote staging testing my site which uses mezzanine 3.0.9.  The
>>> automated tests involve logging and out different users, sometimes quite
>>> rapidly.  When caching is turned on as per the settings in
>>> live_settings.py, I get CSRF errors on login. If I turn off caching to
>>> memcache, I don't get the errors.
>>>
>>> I see that the UpdateCache middleware will go to cache if the user is
>>> anonymous.  At the time the user fills out the login form, they are
>>> anonymous so therefore the login page must be cached, which is causing
>>> my CSRF failures (?).  Unless I'm missing something, this is also true for
>>> the signup page.  It seems like this could be a problem if people submit,
>>> say, a login or signup form with errors, that then happens to get cached
>>> and shown to the next user.
>>>
>>> Shouldn't there be a strategy to not cache these forms?
>>>
>>> Jennifer
>>>
>>> --
>>> 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/groups/opt_out.
>>>
>>
>>
>>
>> --
>> 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/groups/opt_out.
>



-- 
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/groups/opt_out.

Re: [mezzanine-users] Form validation in Page Processors

[Danny flack]

Well, I have a solution to my issue but I have a feeling its more of a
hack.  Let me explain, but bear with me because I'm typing/coding with one
arm as I broke my wrist last weekend and am in a cast. It's a painfully
slow experience.

*Problem*: Be able to run extra validation on a Page's Form via a Page
Processor (created by adding a new Page with a Form as the content model in
Mezzanine's admin)

*Solution*:

   - Run any extra validation necessary in the page processor
   - Reassign request.POST after removing whatever keys from the POST data
   which didn't validate
   - Manually add form field errors and return the form

I'm getting married and am creating a website with an RSVP page.  I added a
form field to the page where the user is expected to enter the bride or
groom's last name to prevent spam.  That context will hopefully shed some
light on the code below.

@processor_for('rsvp')
def rsvp_form(request, page):

if request.POST:

# get the right field for secret question from the form model
secret_field = page.form.fields.filter(label="What is Jen or
Danny's last name?")

if secret_field.exists():

secret_field = secret_field[0]
secret_field_post_key = 'field_%s' % secret_field.id
secret_value = request.POST.get(secret_field_post_key)

# answer should be one of our last names
prog = re.compile('sanchez|flack', re.I)

if request.POST.get(secret_field_post_key) and not
prog.match(secret_value):

# wrong answer to the secret question so invalidate form by
removing the secret value
# from the post data and reassigning the data back to the
request object's POST
form_data = request.POST.copy()
del form_data[secret_field_post_key]
request.POST = form_data

# add the error to the form
form = FormForForm(page.form, RequestContext(request),
form_data, None)
form_error = {
secret_field_post_key: form.error_class(['Are you sure
you know these folks?'])
}
if form.errors:
form._errors.update(form_error)
else:
form._errors = form_error

return {'form': form}
else:
raise forms.ValidationError('Missing expected secret field')

return {}




On Tue, Mar 4, 2014 at 10:41 AM, Josh Cartmell  wrote:

> So I'm not actually sure about adding extra validation to the Form content
> type.  I would start by looking at the default form page processor,
> https://bitbucket.org/stephenmcd/mezzanine/src/ea1095020def16365c418dd3a7541635d38a2916/mezzanine/forms/page_processors.py?at=default#cl-26
> .
>
> One problem you may run into is that I think that processor will always
> run, afaik there isn't a way to unregister a particular processor.
>
>
> On Tue, Mar 4, 2014 at 10:33 AM, Danny flack wrote:
>
>> Hey Josh,
>>
>> Thanks for that.
>>
>> I believe I have a grasp on validating a custom form and returning it in
>> the page's context, but what would be the strategy when you've created a
>> page that has the "Form" content model, where you dynamically define all
>> the form fields in Mezzanine's admin?  Is it possible to add validation to
>> those fields?
>>
>> I've attached a screenshot where the form fields were added.
>>
>> I may be going about this all wrong, but I just want to verify.
>>
>> Thanks
>>
>> On Tuesday, March 4, 2014 9:45:52 AM UTC-8, Josh Cartmell wrote:
>>
>>> Hey Danny,
>>>
>>> Check out the example at https://mezzanine.jupo.org/
>>> docs/content-architecture.html#page-processors, I think it will get you
>>> started down the right path and shows how to handle validation in a
>>> processor.
>>>
>>>
>>> On Tue, Mar 4, 2014 at 9:37 AM, Danny flack  wrote:
>>>
 Is it possible to validate a form in a page processor?

 I know you're able to override the associated form by something like:

 *@processor_for('rsvp')*
 *def rsvp_form(request, page):  *

 *form = RsvpForm()  #  a custom form i created to override the
 page's form *
 *return {"form": form}*

 But how would you go about intercepting and adding custom validation to
 the default page's form?

 For instance, I am trying to do something like:

 *@processor_for('rsvp')*
 *def rsvp_form(request, page):  *

 *form = page.getAssociatedForm()  #  fabricated method to get the
 Page's form instance *
 *form.addError('Some Error')  #  add custom validation*
 *return {"form": form}*


 Am I going down the wrong path?  Is there another way to go about 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

[mezzanine-users] Re: Admin navigation

[Eduardo Rivas]

Sorry about the noise. I just noticed it depends on a setting.

-- 
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/groups/opt_out.

[mezzanine-users] Re: Admin navigation

[Eduardo Rivas]

Wait a second, are menu sections supposed to be collapsible? Because that's 
not working for me in the official demo site or local dev server. 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/groups/opt_out.

[mezzanine-users] Re: Admin navigation

[Eduardo Rivas]

Ok, I've fixed the scrollbar, the font, and opened a new issue to track 
progress here: https://github.com/stephenmcd/mezzanine/pull/970.

I'm working on the collapse functionality right now, I'll keep you posted! 
:)

-- 
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/groups/opt_out.

Re: [mezzanine-users] Mezzanine Forms spam

[Josh Cartmell]

Thanks Danny!  I was under the impression that the spam filters only worked
on comments, but I see that i was wrong.

Regards,
Josh


On Tue, Mar 4, 2014 at 3:52 PM, Danny  wrote:

> You can use the SPAM_FILTERS setting to set a list of handlers that
> check form and comment submission for spam.
> The default uses Akismet (if you have it set up in your site
> settings), but you could easily add your own.
>
> For example, I have added the following to my site. I've genericised
> this code a bit:
>
> =
> # settings.py
> SPAM_FILTERS = ("mytheme.views.is_spam",)
>
> # mytheme/views.py
> def is_spam(request, form, url):
> """
> Validates form data as being 'spam' or not based on a validation
> question.
> Essentially this should be a field in the form always added that has
> the
> following properties:
>
> Label: *must* contain the string "validation code".
> Type: Single Line Text
> Required: True
> Visible: True
> Default: None
> Help Text: something useful as to why this question is being asked
>
> The answer for this example is "foobarqux" but you should change
> it as appropriate
>
> NOTE: The form submisison goes through regardless, the entry is
> just not saved/emailed if
> the answer is incorrect.
> """
> for name, field in form.fields.items():
> if field.label and "validation code" in field.label.lower():
> cleaned_data = form.cleaned_data.get(name)
> if "foobarqux" in cleaned_data.lower():
> # The form field was filled correctly! It's likely not
> spam!
> return False
> else:
> # It's spam, not good
> return True
> # else there's no "validation code" field in the form, so we
> accept all submissions
> return False
>
> =
>
> So for the forms that require the validation question, just add a
> field to your form following the comments above, and forms which
> answer incorrectly will be treated as spam.
>
> Unfortunately, this mechanism does not reject the form and tell the
> user they got the question wrong, it just prevents the form submission
> from being emailed.
> If anyone has an easier solution so that form validation can be done
> /prior/ to the submission being accepted, I'd love to see it too.
>
> Seeya. Danny.
>
>
> On 5 March 2014 10:12, Josh Cartmell  wrote:
> > Lately I've had a lot of clients (and a site of my own) getting a lot of
> > spam submitted to Mezzanine forms.
> >
> > I'm wondering if anyone else has encountered this and/or has
> ideas/solutions
> > to cut down on spam submissions.
> >
> > Thanks!
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Mezzanine Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to mezzanine-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> molo...@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/groups/opt_out.
>

-- 
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/groups/opt_out.

Re: [mezzanine-users] CSRF fails on login during automated testing. Issue with caching on non-anonymous?

[jenniferlianne]

Thanks for the answer.  You are entirely right.  I had forgotten that I 
overrode mezzanine's account forms as per the instructions here:
http://mezzanine.jupo.org/docs/frequently-asked-questions.html#where-are-all-the-templates-i-can-modify
  


...and the issue only showed up when caching was turned on in a 'real' 
environment.  

Jennifer

On Tuesday, March 4, 2014 3:24:56 PM UTC-8, Stephen McDonald wrote:
>
> There are a few moving parts here, my guess is something failing in the 
> last of these:
>
> By default in Mezzanine, forms use the "fields_for" template tag, which is 
> just a helper for rendering forms: 
> https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/core/templates/includes/form_fields.html
>
> You'll see at the top of its template, it uses the "nevercache" tag which 
> is fairly self explanatory - it's wrapped around the csrf token so that 
> it's never cached.
>
> Then finally you'll see in both phases of the caching middleware, special 
> handling of the csrf token is required:
>
>
> https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/core/middleware.py#L169-L181
>
> https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/core/middleware.py#L210-L213
>
> It's likely that last part is somehow incompatible with LiveServerTestCase 
> - I personally haven't used that before, but with regular Django test cases 
> I've experienced a lot of differences in how sessions, request objects and 
> everything related, actually work, compared to an actual running site.
>
> My advice would be to first verify these forms actually work for you in 
> production, so that you can isolate this issue down to testing only, and 
> then unless you're feeling particularly adventurous, disable caching for 
> those particular tests that are failing - I understand there's a decorator 
> in Django for modifying settings per test, but the name escapes me.
>
> Good luck!
>
>
>
>  On Wed, Mar 5, 2014 at 9:48 AM, >wrote:
>
>> Hi,
>>
>> I'm using LiveServerTestCase, as described 
>> here,
>>  
>> to automate remote staging testing my site which uses mezzanine 3.0.9.  The 
>> automated tests involve logging and out different users, sometimes quite 
>> rapidly.  When caching is turned on as per the settings in 
>> live_settings.py, I get CSRF errors on login. If I turn off caching to 
>> memcache, I don't get the errors.
>>
>> I see that the UpdateCache middleware will go to cache if the user is 
>> anonymous.  At the time the user fills out the login form, they are 
>> anonymous so therefore the login page must be cached, which is causing 
>> my CSRF failures (?).  Unless I'm missing something, this is also true for 
>> the signup page.  It seems like this could be a problem if people submit, 
>> say, a login or signup form with errors, that then happens to get cached 
>> and shown to the next user.
>>
>> Shouldn't there be a strategy to not cache these forms?
>>
>> Jennifer
>>
>> -- 
>> 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/groups/opt_out.
>>
>
>
>
> -- 
> 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/groups/opt_out.

Re: [mezzanine-users] Re: step by step mezzanine deployment

[Federico Bruni]

2014-03-04 18:15 GMT+01:00 Ross Laird :

> I don't actually use Fabric, so I have been a bit hesitant to make
> suggestions here. But my guess is that you have one problem and one problem
> only, and it just keeps changing how it looks depending on what you do. To
> step through a solution to this, I would take Fabric out of the equation
> and get the database connection running properly from the command line only
> (using pg_dump, pg_restore, and syncdb). If those commands work from the
> command line, then the problem is in the Fabric configuration. If those
> commands do not work from the command line, then you have a connection
> problem that sounds like it is related to permissions. In that case, try
> using psql from the command line to see who owns the database you are
> trying to connect to. Take as many things out of this equation as you can.
> Get right down to the core of it: who owns the database, what it's called,
> what its permissions are, and so on. Your problem lies in one of these
> areas, I think. Everything else that you try to do (using Fabric, Django,
> etc.) will fail -- and will give you different error messages -- until this
> one thing is resolved.


Thanks Ross! This is indeed the best approach.
I've found out that part of my problem is that the database and owner names
are different between local and server. I've solved following this tip:
http://stackoverflow.com/questions/12233046/django-permission-denied-when-trying-to-access-database-after-restore-migratio

and in particular:

psql database -c "GRANT ALL ON ALL TABLES IN SCHEMA public to user;"
psql database -c "GRANT ALL ON ALL SEQUENCES IN SCHEMA public to user;"
psql database -c "GRANT ALL ON ALL FUNCTIONS IN SCHEMA public to user;"

After this change, I did:

sudo supervisorctl stop all
python manage.py runserver

The server starts without errors but still it's not my local website.
I'll try again from scratch a new project and set up immediately PostgreSQL
also in local_settings.py, before running 'manage.py createdb'.

-- 
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/groups/opt_out.