[mezzanine-users] Re: Editable setting disappearing repeatedly
I figured it out. In case anyone sees this, and wants a fun story about me being dumb: I had an older version of my site that did not have the new setting running on a different domain (for QA), but forgot I'd left it hooked up to the production database. Unbeknownst to me Mezzanine will delete any settings in the database that are not registered. So probably some web spider was hitting the other domain and caused this. On Thursday, 8 November 2018 11:09:55 UTC-5, Chris Hawes wrote: > > > I added a setting in defaults.py in on of my apps: > > > from mezzanine.conf import register_setting > > register_setting( > name='MY_SETTING', > label='My setting', > description='Some stuff.', > editable=True, > default='' > ) > > I set it to a value in the admin, but a few hours later, I noticed that it > was blank. I set it again, and a few hours later I came back, and it was > blank again. Repeat ad nauseum. > > When I look in the database, I see what is happening: the row in > conf_setting for this setting is simply disappearing. It's getting dropped > somewhere. I set it again, and then it disappears again a few hours later. > I've looked through the code in mezzanine.conf.__init__.py and cannot see > any reason why this row would get dropped. I have other editable settings > in my project that do not exhibit this problem. > > I am perplexed. Has anyone seen anything like this before? Any ideas what > to look at? > > I'm using: > >- Django 1.11.16 >- Mezzanine 4.3.1 >- PostgreSQL 9.6 > > Thanks for any help, > 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] Editable setting disappearing repeatedly
I added a setting in defaults.py in on of my apps: from mezzanine.conf import register_setting register_setting( name='MY_SETTING', label='My setting', description='Some stuff.', editable=True, default='' ) I set it to a value in the admin, but a few hours later, I noticed that it was blank. I set it again, and a few hours later I came back, and it was blank again. Repeat ad nauseum. When I look in the database, I see what is happening: the row in conf_setting for this setting is simply disappearing. It's getting dropped somewhere. I set it again, and then it disappears again a few hours later. I've looked through the code in mezzanine.conf.__init__.py and cannot see any reason why this row would get dropped. I have other editable settings in my project that do not exhibit this problem. I am perplexed. Has anyone seen anything like this before? Any ideas what to look at? I'm using: - Django 1.11.16 - Mezzanine 4.3.1 - PostgreSQL 9.6 Thanks for any help, 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] Modifying behavior of TimeStamped `updated` timestamp for subclasses
I want to display a timestamp on each BlogPost showing when the post was last updated. My first attempt at this was to just show the `updated` timestamp from the TimeStamped superclass. However, this timestamp is bumped up every time the post is saved for any reason. For instance if a user adds a comment, BlogPost gets saved in order to update its comment_count field, and `updated` gets bumped as a result. That's no good. I also have two other RichText-TimeStamped classes that require similar functionality. Since I own those classes, the obvious thing would be to make an abstract superclass that adds a new modified timestamp field and updates it appropriately on save. But what do I do about BlogPost? I don't own it so my options are limited, and I am struggling to come up with a nice way to handle it. - I could add a field through EXTRA_MODEL_FIELDS and monkey patch BlogPost.save() to update it. But I would prefer to use the same logic for the other two classes as for BlogPost. - I could monkey patch TimeStamped.save(), but would have to put a super ugly hack so that it only affects the 3 subclasses that I care about. - Subclassing BlogPost might be an option, but it would create a new table, which is not fun, plus I already have a bunch of existing blog posts so I'm not sure offhand what I'd do about those. I am wondering if anyone has a better idea? Is there a nice way to handle cases like this that I am missing? -- 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] Case insensitive username login
There are two problems I see with doing this for email addresses. 1) Email addresses could be case sensitive -- not the domain, but the host-specific part (though I doubt many hosts actually allow this in practice). CHRIS@server could be a different user than chris@server. 2) Mezzanine does not enforce case-insensitive email addresses, unlike usernames (see `mezzanine.accounts.forms.ProfileForm.clean_email()`). It is possible that existing installations could have users with email addresses that differ only by case. Perhaps somebody sneaky posing as multiple users. This would have to be a setting so that an admin could look at their particular case and see whether it is safe to turn on. Usernames are different. I think the typical non-tech-savvy web user doesn't think about case or even realize that 'c' and 'C' are not the same. It's just another name for themselves, and in the real world, names are not case sensitive. The name on my birth certificate may be Chris, but when a letter arrives at my house addressed to CHRIS, I don't send it back. Chris On Sunday, 5 November 2017 15:27:09 UTC-5, Danny S wrote: > > On 5/11/2017 1:24 PM, Chris Hawes wrote: > > I'm wondering if there is a reason > mezzanine.core.auth_backends.MezzanineBackend doesn't support > case-insensitive usernames for logging in? > mezzanine.accounts.forms.ProfileForm enforces case-insensitive username > uniqueness when registering, so it seems like it would be natural to allow > them for logging in. It feels to me like a bug that it doesn't. > > > I bring this up because I've had users of my site write to me bewildered > that they can't log in, and then it turns out they had capitalization in > their username and just assumed that it wouldn't matter, as is the case on > other sites. > > > If others do not agree that it is a bug, perhaps adding a setting for this > would be appropriate. In any case I would be happy to work on a PR if there > is agreement on a change. > > > I've certainly had the case where users have contacted me because they'd > put some capitalisation in their original signup email address and then > tried to log in using it in all lowercase -- and in the case of email > addresses, case is DEFINITELY not important - so I don't know why it seems > to be for the Mezzanine/Django login. > > So if usernames are also not case sensitive, we should definitely fix it > for both. > > Seeya. Danny. > > -- You received this message because you are subscribed to the Google Groups "Mezzanine Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[mezzanine-users] Case insensitive username login
I'm wondering if there is a reason mezzanine.core.auth_backends.MezzanineBackend doesn't support case-insensitive usernames for logging in? mezzanine.accounts.forms.ProfileForm enforces case-insensitive username uniqueness when registering, so it seems like it would be natural to allow them for logging in. It feels to me like a bug that it doesn't. I bring this up because I've had users of my site write to me bewildered that they can't log in, and then it turns out they had capitalization in their username and just assumed that it wouldn't matter, as is the case on other sites. If others do not agree that it is a bug, perhaps adding a setting for this would be appropriate. In any case I would be happy to work on a PR if there is agreement on a change. -- 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_blogpost_add URL missing
In case anyone stumbles upon this, I found the problem. I replace the
default BlogPostAdmin with my own subclass which adds some functionality.
At some point I'd fat-fingeredly commented out the line that registers my
new admin class while debugging a problem, which left just the line that
unregisters the old one. So there was no blog post admin registered.
To answer the question of where blog_blogpost_add url comes from, it seems
to be auto-generated by the admin. That URL resolves to
/admin/blog/blogpost/add/ on my site.
On Thursday, 1 December 2016 18:44:30 UTC-5, Chris Hawes wrote:
>
> FWIW, I've gotten around this by using the DASHBOARD_TAGS setting to
> remove the quick_blog section. However, I'm still baffled as to why this
> suddenly started failing, and would also like to restore the quick_blog
> section if possible...
>
>
> On Thursday, 1 December 2016 18:38:11 UTC-5, Chris Hawes wrote:
>>
>> I'm at a bit of a loss. Some time yesterday, loading my admin page on my
>> Mezzanine site started failing with the following error:
>>
>> Reverse for 'blog_blogpost_add' with arguments '()' and keyword arguments
>> '{}' not found. 0 pattern(s) tried: []
>>
>>
>> Of course I tried undoing whatever recent changes I'd made, but nothing
>> there seems to remedy it. I haven't made any changes that would seem
>> suspect.
>>
>> The trouble is that in trying to debug it, I can't even see where the
>> blog_blogpost_add URL is supposed to come from. I see the (failing) url
>> lookup in the quick_blog.html template, but nowhere do I see a urlconf
>> with the name blog_blogpost_add. So I can't even see how it's supposed
>> to work, let alone why it's not.
>>
>> Can anyone point me in the right direction here? I'm tearing my hair 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/d/optout.
[mezzanine-users] Re: blog_blogpost_add URL missing
FWIW, I've gotten around this by using the DASHBOARD_TAGS setting to remove
the quick_blog section. However, I'm still baffled as to why this suddenly
started failing, and would also like to restore the quick_blog section if
possible...
On Thursday, 1 December 2016 18:38:11 UTC-5, Chris Hawes wrote:
>
> I'm at a bit of a loss. Some time yesterday, loading my admin page on my
> Mezzanine site started failing with the following error:
>
> Reverse for 'blog_blogpost_add' with arguments '()' and keyword arguments
> '{}' not found. 0 pattern(s) tried: []
>
>
> Of course I tried undoing whatever recent changes I'd made, but nothing
> there seems to remedy it. I haven't made any changes that would seem
> suspect.
>
> The trouble is that in trying to debug it, I can't even see where the
> blog_blogpost_add URL is supposed to come from. I see the (failing) url
> lookup in the quick_blog.html template, but nowhere do I see a urlconf
> with the name blog_blogpost_add. So I can't even see how it's supposed to
> work, let alone why it's not.
>
> Can anyone point me in the right direction here? I'm tearing my hair 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/d/optout.
[mezzanine-users] blog_blogpost_add URL missing
I'm at a bit of a loss. Some time yesterday, loading my admin page on my
Mezzanine site started failing with the following error:
Reverse for 'blog_blogpost_add' with arguments '()' and keyword arguments '{}'
not found. 0 pattern(s) tried: []
Of course I tried undoing whatever recent changes I'd made, but nothing
there seems to remedy it. I haven't made any changes that would seem
suspect.
The trouble is that in trying to debug it, I can't even see where the
blog_blogpost_add URL is supposed to come from. I see the (failing) url
lookup in the quick_blog.html template, but nowhere do I see a urlconf with
the name blog_blogpost_add. So I can't even see how it's supposed to work,
let alone why it's not.
Can anyone point me in the right direction here? I'm tearing my hair 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/d/optout.
[mezzanine-users] LOGIN_URL troubles
I'm having a strange problem with LOGIN_URL.
I have SITE_PREFIX set to 'content'. So, I can login by going to
/content/accounts/login. This works as expected.
However: I also have COMMENTS_ACCOUNT_REQUIRED = True. The problem is that
when I try to post a comment from a non-logged in browser, it redirects me
to '/accounts/login', which results in a 404. Poking through
generic/views.py, it seems that it's redirecting to LOGIN_URL, which is
still '/accounts/login'.
So, I think to myself, I must need to set LOGIN_URL in my settings.py. So I
add this to my settings:
LOGIN_URL = '/content/accounts/login'
But after doing that, when I try to load /content/accounts/login, I get a
404 from the mezzanine.pages.views.page. It seems to me it should not be
getting into the page view; it should be in the
mezzanine.accounts.views.login view.
I thought maybe another URL was interfering or something, so I reduced my
urlconf to just this, still getting 404:
urlpatterns = [
url(r'^%s/' % SITE_PREFIX, include("mezzanine.urls")),
]
Anyone have any ideas what is wrong here?
--
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.
