Django 3.0 compatibility for Suit 1.x

[coredumperror]

This is far form the cleanest PR I've ever written, but it does what I need it to do to make Suit 1.x work in my old site that I've just upgraded to Django 3.0.

There are two things that I think may need to be further cleaned up:

1. The string_types thing I did in suit_menu.py. There's surely a better way to change that code to make it Python 3 compatible.
2. Further changes having to do with the removal of "admin_static". There's a template tag called {% admin_static_url %} that may or may not need to be changed. However, it either isn't used by any templates that my site uses, or it doesn't need to change. Since I didn't know the answer to that, I left it alone.

[onyekaa]

Hi, thanks for this. Any idea when this would be merged in? Don't want to change to v2 yet.

[f213]

@darklow any updates on this?

[cuu508]

I'm using Suit 1.x in a commercial project, want to upgrade to Django 3 and am looking at my options.

1. Wait for Suit 1.x to get updated with Django 3 compatibility

But ... 1.x appears to abandoned, not sure if an update will ever come

2. Fork 1.x and use changes from this PR

But...

• not sure if the commercial license allows that
• in future there will be extra work to maintain compatibility with future Django versions

3. Migrate to Suit v2

But...

• Suit v2 is not a drop-in replacement, there will be work re-doing my admin customizations
• Suit v2 appears to be dead-ish already – if I do migrate, I may be in the same pickle again in a year or so

4. Migrate to vanilla Django admin, or a different skin

In my case this would require the most upfront work, but in exchange would be relatively future-proof. Perhaps also a good opportunity to revisit all the accumulated admin features and cutting stuff that isn't used much.

To help with deciding, @darklow it would be great to get your comments on:

• Is 0.2.28 the final 1.x release, or will there be future releases (and if yes, for how long?)
• does the commercial license permit me to fork 0.2.28 and add stuff to it? Publish it on Github under CC-BY-NC?

[madthew]

Django-Baton is another good alternative by the looks of it.

Yeah, django suit2 seems dead already unfortunately. It's a pity because it was great!

[gamesbook]

@madthew Until the developer confirms this, we can assume it is not. Even if he decides not to work on it, there is no reason the code cannot be further developed by others.

[cuu508]

Even if he decides not to work on it, there is no reason the code cannot be further developed by others.

The code is CC-BY-NC: you can develop it further, but you can only use it in noncommercial projects.

You can buy a commercial license from the author. IIRC it was just a one-time Paypal payment, with no additional information on what the license terms are.

Also, I'm totally not an expert on this, but I haven't seen copyright assignment mentioned anywhere. SO, IIUC, if you wanted to use Suit commercially, you would need a permission not only from @darklow, but also from the other 46 contributors.

[gamesbook]

The code is CC-BY-NC: you can develop it further, but you can only use it in noncommercial projects.

I am assuming that if the owner decides to abandon this project, that the license will be changed accordingly.

[darklow]

I can merge in if someone confirms that this (or any other PR) are indeed a good fix and compatible with other versions.
I've mentioned it often across other issues, that currently I have no time to maintain this project, but other than that, I am using Django Suit for my own projects in 10+ production level projects without any issues daily (mostly v2-dev). So I wouldn't say it is dead or abandoned, just that there are no intentions to develop is forever as this is just a skin+few nice extras and shortcuts for default django admin. Any extras or improvements I need I usually extend them using some new widgets or templates locally within project.
If you have a license, you can modify it however you want for your own use. Or if you decide to maintain fork and offer publicly, then it must have the same license and terms as original.
Also I've mentioned this earlier, that if there is someone who is willing to maintain project, I'd be happy to give permissions to review and accept PR.

This particular PR have 3 attempts, so it adds some concerns over stability and best approach, but as I've mentioned I have no v1 setup currently available in order to fully verify it.

[gamesbook]

@darklow While the project was being maintained by yourself, we were happy to pay licenses for commercial deployments - but if you have no intention to maintain or develop, please consider lifting the commercial restriction as this is really not an incentive for anyone else to maintain, or contribute to, the project.

[darklow]

@darklow While the project was being maintained by yourself, we were happy to pay licenses for commercial deployments - but if you have no intention to maintain or develop, please consider lifting the commercial restriction as this is really not an incentive for anyone else to maintain, or contribute to, the project.

License is for the value, not the maintenance/support, therefore I don't see any valid reasons for lifting license at this moment. v1 is really old release, v2 is working and being maintained to work with newest Django versions. Single license works for both v1 and v2.

[gamesbook]

@darklow Fair enough; but there are numerous messages from users saying this project is "dead". A proper (not "pre") release of v2 on PyPi would be one simple and useful way to demonstrate this is not the case.

[mhindery]

Picking this up, it would be great if this can be merged, either in master or in the develop branch, or in whatever structure you want which allows for bugfixes and compatibility updates of the old Suit with newer Django versions. Switching to V2 is a massive visual switch, and when you have an existing setup with possibly a lot of customization of the previous Suit, you don't just want to switch all that. You do want to keep up with new Django versions though, and one should not block the other as it currently does. The changes here make sense, I'm using similar changes to run the old Suit with Django 3.0 (develop...mhindery:develop)

[gustavo-sdo]

Picking this up, it would be great if this can be merged, either in master or in the develop branch, or in whatever structure you want which allows for bugfixes and compatibility updates of the old Suit with newer Django versions.

Just like @mhindery said.
I'm also locked in Django 2.2.14.

We also have a lot of customization.
I think the django-suit v1 interface is very intuitive and clean.
It would be great to be able to continue supporting django-suit v1 in newer versions of Django @darklow.

[mhindery]

For those still in the same situation using Suit v1 with the latest Django versions: Django 3.2 updated some pagination-related logic which breaks Suit v1. I've added some fixes on my branch (develop...mhindery:develop). Other than that it seems to be working with 3.2, I'll update that 'fork' should I encounter other problems.