Migrate changes to original projects

[batiste]

Hi people from ArabellaTech,

I just discovered this repository.

First thanks for at least giving me credits but apart from just changing the name of the project what prevented you to contribute to the original project?

I would have greatly appreciated any contributions to the orignal repository and I am sure we could have found a common ground for development.

Do you still use this code base? Is there anything in there I should try to backport to the original project?

[remik]

Hi,
Your project was dead for sometime (we did some PR and it was waiting for a long time).
Our main changes are to support SEO by default + small fixes.
We also plan to do new import/export (JSON + media files via website (oAuth connection) - not import/export).
@jacoor any hint what we can backport or can we sync to main project?

[jacoor]

Hello
I don't think we need to backport anything - stuff right now works for us. But, according to http://pythonhosted.org/django-page-cms/introduction.html#dependencies-compatibility original project does not support django > 1.7, which we did in version > 3.0 (and actually left earlier versions support at 0.2.x)
I'd go with merge if possible.

[batiste]

Sorry but the documentation is not fully up to date.
Right now the original project is compatible with Django 1.8, I think we really duplicated the work on maintaining and pushing it to 1.8.

I would love a merge if possible. But I imagine the fact you guys changed the name is an impediment. I planned to change the name of the module to gerbi (Gerbi CMS) because it seemed like a more appealing name. I decided against it after realising the mess that will be created with database migrations.

Tell me if changing the name of the module back to "pages" is an issue for you guys because it is obviously the elephant in the room.

[batiste]

Also note that from pep08

"Python packages should also have short, all-lowercase names, although the use of underscores is discouraged."

[remik]

Hi,
We will try to find some time next week to review changes and do few PR.
Change name could be a problem with migration but we will try to do some command to copy contents.
After this I think we can close this project and contribute to yours.
Sorry for any "bad" feelings but as I mention before we did it because your projects looks dead - no activity, no response for PR (16 May 2012 - 15 Mar 2013)

[jpic]

It's cool to fork any project, even more if it's un-maintained, but next time try to keep the git history, it can be useful (license, copyright and authors should be kept too but that I think is clear for everybody now ^^).

If a project need maintainers, non-profit orgs like djangonauts might be able to help.

[batiste]

You are talking about those 2 pull requests?

16 May 2012 batiste/django-page-cms#60
15 Mar 2013 batiste/django-page-cms#64

The first one was opened and merged on the same day. It is difficult to be more reactive than that. The second one took me 3 month to merge. Maybe this is too much? Who knows why I took so long. I can't recall.

Anyway we are not here to nitpick, if anybody wants to become part of the maintenance for this project I am all for it.

The migration path for the data is indeed an issue, you have to rename the tables especially with foreign keys, but I think this is possible.

[remik]

I am guessing dates now, I don't remember exactly. I just remember that it looks like dead. Sorry for wrong checking.

I don't remember why we didn't fork it. I did not copy it so I can't say for someone.

Somehow we did migration in past so I need to find our script (TODO: clean, tests, release) and use.

Just repeat: we will be happy to do PR and help with next features. Our users are happy (maybe except import/export but this longer talk) with this package and we already integrating it in all our projects so we want to do it better.

[batiste]

I draw your attention towards those commands I wrote:

https://github.com/batiste/django-page-cms/blob/master/pages/management/commands/pages_push.py

The provide a way to pull and push content from one instance of the CMS to another rather simply using the CMS API.

This might prove useful in some way. This is definitely a similar feature that the one provided by the JSON import/export plugin somehow... But more developer friendly.

[remik]

Just for tracking what to do:

• Grapelli support (Grappelli support batiste/django-page-cms#143)
• HTML Meta support - few metadata fields on all pages (in admin collapsed by default) (Support for grouping fields in admin batiste/django-page-cms#145)
• Update CSS/JS lib to new versions (this might be already outdated)
• Tox support to easier local testing (Django 1.9 and few others batiste/django-page-cms#121)
• Add tags to export/import (Support tags in JSON export/import batiste/django-page-cms#131)
• New template tag get_pages_with_tag (Added get_pages_with_tag templatetag batiste/django-page-cms#128)
• Do redirect if slug is changed - (Do redirect if slug is changed (with settings) batiste/django-page-cms#124)
• We had a lot issues with export/import (all fixes are already in master)
• Check PAGE_TEMPLATES (PR by @jpic - Check PAGE_TEMPLATES setting #9) - (Check PAGE_TEMPLATES setting batiste/django-page-cms#122)

In our backlog we have few features (early stage or not started):

• Support denormalise file names after upload eg. remove spaces as it breaks sometimes front-end code (Clean upload file names batiste/django-page-cms#146)
• Support for Django 1.9 (Django 1.9 and few others batiste/django-page-cms#121)

Migration plan:

• Set PAGE_REDIRECT_OLD_SLUG = True
• Set PAGE_TAGGING = True
• Replace basic_cms.urls to pages.urls in urls.py
• Set PAGE_API_ENABLED to the same as PAGE_ADD_API
• add section Metadata for SEO placeholders

[jpic]

@remik did you consider django-suit ?

[remik]

No, I might check it too. We are using Grappeli for our clients because of extra functions (inline sort, auto apply action, put inlines between formset etc) not style but looks like django-suit is similar.
Also we did Grappeli fixes in this fork.