ew favored plugins
production ready? A quick glance at the djangocms-picture README suggests
that beyond needing to do some sort of data migration, users would
potentially need to also update templates, settings, etc. Any other known
hurdles that will need to be addressed when paving the migration
s has been answered/solved elsewhere.
Thanks!
John-Scott
On Sunday, September 11, 2016 at 11:25:03 PM UTC-7, Angelo Dini wrote:
>
> Hello @john
>
> Yes we want to replace cmsplugin-filer with more specific plugins
> following the Python Zen "Do one thing, and that good&qu
This is one of the things I'd like to see on a code review checklist so
this could be caught before a release.
Any field that uses 'choices' needs to have its migrations modified to
point to the variable name (e.g. choices=DJANGOCMS_STYLE_CHOICES) instead
of the raw values. Otherwise, 'makemig
ting/code.html
>
> any other opinion?
>
> Cheers
> Angelo
>
> On Saturday, 22 October 2016 06:08:08 UTC+2, John-Scott wrote:
>>
>> Is there any sort of code review checklist used internally by the core
>> developers? Something that could be referenced by rev
Is there any sort of code review checklist used internally by the core
developers? Something that could be referenced by reviewers before
approving changes, e.g. 'If this change modifies a public API call
signature, be sure to clearly document the impact/follow the deprecation
policy/etc'.
It'
e goal to deprecate & retire cmsplugin-filer? If so, will there be an
upgrade path for those using cmsplugin-filer?
Thanks,
John-Scott
On Friday, September 9, 2016 at 12:39:33 AM UTC-7, Angelo Dini wrote:
>
> Activity Report 9th of September 2016
> -
>
> *News*
>
>-
FYI, the PageExtensions link was broken (missing the 'l' in the 'html' file
extension), here's the correct url
=> http://docs.django-cms.org/en/release-3.3.x/how_to/extending_page_title.html
On Tuesday, August 23, 2016 at 2:56:56 PM UTC-7, czpython wrote:
>
> Hello Philippe,
>
> We are in the pr
The issue is documented here
=> https://github.com/divio/django-cms/issues/5344
It appears CMS_INTERNAL_IPS defaults to Django's INTERNAL_IPS, but this
wasn't clearly documented, resulting in many of us being locked out of
being able to edit our sites.
If you need to use INTERNAL_IPS for reaso
