I'd suggest that part of putting something on a stable/release branch
should also involved cherry picking it to master if needed. That way
nothing is forgotten and there's no huge, error-prone merge task to do at
some later time by someone who's not familiar with all the patches involved.
Looks
Hi,
This question has nothing to do with django-cms, so in the future please
use the https://groups.google.com/forum/#!forum/django-users mailing list,
although it's more of a Python question than a Django one.
Anyway, for the solution, please read about @classmethod here:
https://docs.python.
One of my users just
reported https://github.com/divio/django-cms/issues/5694 to me. I see it'll
be fixed in 3.4.1 so I was wondering if there's a release coming soon or if
I should use a git checkout install in the meantime. Thanks!
It might be nice to add something
to
http://docs.django-cms
Just wanted to follow up on a positive note and say "nice work on the new
release". It was an easy upgrade after I fixed my own issues.
On Monday, September 12, 2016 at 5:12:32 PM UTC-4, Tim Graham wrote:
>
> Correct, we never use git merge in Django. We always cherry-pick
>
:
>
> On Thu, Sep 1, 2016, Tim Graham > wrote:
>
> >I'll
> >admit that I don't really understand how git merging works but I find
> >Django's cherry picking of commits to make backports to be very reliable
> in
> >terms of making history bi
t the same as
> page_permissions.user_can_add_page(), the latter is for adding a root page
> while the former is for adding a subpage.
>
> On Sunday, September 4, 2016 at 3:01:04 PM UTC-4, Tim Graham wrote:
>>
>> Thanks, Paulo, and I'm sorry, this was my fault. My app was
> Most of the functions there were replaced by more specific functions in
> cms.utils.page_permissions, if you still rely on the CMS permissions system
> feel free to ping me to get more information
> on the new API. Like the old one, it's still private but now it's ver
Hi,
I wanted to share my experience trying to update to django-cms 3.4. When I
launch my app, I get a NoReverseMatch exception related to URL reversing,
so I tried to use git bisect to find the commit where the behavior changed
in the django-cms. This wasn't so pleasant as there were a long str
Will it be released to PyPI as past release candidates were?
--
Message URL:
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to
django-cms-developers+unsubscr...@googlegroups.com
---
You received this message because you are subscribed to t
I should have asked this before Django 1.10 was released, but here I am
now. I like to monitor if third-party packages run into any unexpected
issues, so please ping me when there's a PR for this so I can take a look.
--
Message URL:
https://groups.google.com/d/msg/django-cms-developers/topic-
I haven't used it so I can't say for sure, but I think you might be able to
use channels for realtime notifications to show who else is editing the
page at any moment. I guess this would be a more elegant solution in the
long run.
On Monday, July 25, 2016 at 3:51:36 AM UTC-4, Angelo Dini wrote:
I've found the first two weekly updates interesting and informative.
On Tuesday, June 21, 2016 at 4:01:20 AM UTC-4, Angelo Dini wrote:
>
> Dear django CMS developers,
>
> We want to keep everyone updated better about work that's going on in the
> project, so we are going to try posting weekly b
It might be more effort than it's worth to test every example. Even in
Django's docs, there are only a handful of places that use six:
howto/outputting-csv.txt:from django.utils.six.moves import range
ref/urlresolvers.txt:from django.utils.six.moves.urllib.parse import
urlparse
ref/utils
13 matches
Mail list logo