Wagtail 2.0 beta 1 released

[Matthew Westcott]

Hi all,
I'm pleased to announce that a beta release of Wagtail 2.0 is now available!

http://docs.wagtail.io/en/latest/releases/2.0.html

As you'd expect from a 2.0 release, the changes this time are more wide-ranging than usual, and a few of them need particular attention when upgrading existing sites - so we'd like to encourage developers to try out this beta on their development and staging sites, to help us catch any unexpected compatibility issues.

Please note that this release drops support for Python 2.7 - you'll need to be running on Python 3 to upgrade. (For users who aren't able to upgrade, we'll be announcing Long Term Support arrangements for Wagtail 1.11 / 1.12 shortly.)

Notable new features and changes that we're particularly keen to test include:

* Django 2.0 support

* An improved rich text editor based on draft.js. This is a major rewrite of Wagtail's rich text support, and for projects using the standard RichTextField / RichTextBlock functionality, it should be a drop-in replacement available as soon as you upgrade. However, any code-level customisations (through hallo.js plugins or whitelisting rules) will no longer be available. Documentation on customising the new Draftail editor will be published in the next week or two. For projects that can't be upgraded to Draftail - for example, ones relying on users editing HTML source code directly - it's possible to swap back to the old hallo.js-based editor in your project's configuration, but this will no longer be supported with bug fixes.

* Shortened module paths: for example, `from wagtail.wagtailcore.models import Page` is now `from wagtail.core.models import Page`. You'll need to update these across your codebase when you upgrade, and while we appreciate that this will cause some short-term headaches, it will make developing with Wagtail much more pleasant in the long term! To ease the pain, Wagtail 2.0 provides a command-line tool `wagtail updatemodulepaths` to automatically update module paths across your codebase. We can't guarantee that it will catch everything (for example, it will only check *.py files), but it should at least get you 99% of the way there - of course, if you have a codebase where it fails dramatically, please do let us know!

* jQuery has been updated to 3.2.1 within the admin; all Javascript code within the admin has (hopefully!) been updated accordingly, but third-party libraries that extend the admin interface may need updating too.


To install:
pip install wagtail==2.0b1
or include
wagtail==2.0b1
in your requirements file. Be sure to check the release notes and upgrading instructions: http://docs.wagtail.io/en/latest/releases/upgrading.html

Cheers,
- Matt

[Joe Tennies]

So, I'm starting to move a site that hasn't been published yet to Wagtail 2.0, and I think there's some concerns with the way the shortened module paths has been done.

What is the expectation for 3rd party plugins to support backwards and forwards across this change? Should everything just try/except the old and new names?

I don't know what your policy is, but this change would not be allowed for the new Django deprecation policy. (You are dropping support between LTS versions on something that was never deprecated.) I believe you could meet the Django policy by having the old location do a "from <newlocation> import *" and raise a warning for now. Then in next LTS+1, you remove the old paths. (Requiring the INSTALLED_APPS to be updated is even fine to me. It's the imports that's a bigger issue to me as it breaks apps that likely aren't under your control.)

If I were to contribute such a change, would it be considered?

[Matthew Westcott]

Hi Joe,
It's a fair point! We investigated several options for doing the deprecation, as summarised here:

https://github.com/wagtail/rfcs/blob/64213564601d41dfc9721a30c1a8c789d2e9d7ca/draft/012-rationalise-apps.rst

Indeed, one of the reasons this change has been delayed for as long as it has, was the search for an elegant solution to this. In the end, we just couldn't make it work in a satisfactory way. Even if we could maintain 99% of the illusion of things remaining in their existing places, that would be no good: our message would have to be "you don't have to update your paths *yet*, unless <obscure scenario X>, in which case you do. If you're not sure if this applies to you, you'd better update them anyway, just to be safe..."

The more elaborate our compatibility layer is, the more chance there is for things to break in unexpected and subtle ways. Inevitably there'd be an awkward transition period where any bug report might be a legitimate issue, or might be a side effect of the renaming - and in the end the only thing we really gain out of it is the ability to push the "you really have to update your paths now" cutoff date a few months down the line. Instead, it made a lot more sense to use the 2.0 release as an opportunity to make a clean break and present an unambiguous message: you have to make this change as part of the upgrade.

(I think it's worth pointing out that Django isn't immune from making breaking changes that couldn't be anticipated by following deprecation warnings - for 2.0, dropping support for bytestrings in URLs was one such change.)

> What is the expectation for 3rd party plugins to support backwards and forwards across this change? Should everything just try/except the old and new names?

Yep, that's what we suggest - see for example https://github.com/alexgleason/wagtailfontawesome/blob/739ad953dfdbfd61bba628f585bf4b4b2b4b6caf/wagtailfontawesome/wagtail_hooks.py#L5-L10 .

> If I were to contribute such a change, would it be considered?

Unfortunately it's really too late for us to consider it at this point - we're in the final stages of preparing the 2.0 release now, and hoping to have a release candidate out in the next day or two. A change of this scale would mean that we'd have to go back to another beta release to ensure it had the proper testing.

Cheers,
- Matt

> --
> You received this message because you are subscribed to the Google Groups "Wagtail support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wagtail+u...@googlegroups.com.
> To post to this group, send email to wag...@googlegroups.com.
> Visit this group at https://groups.google.com/group/wagtail.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/357496df-ec48-4d40-b7d8-c21cba815fc3%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[David Moore]

Hi,

In blissful ignorance I also had a go at writing an ImportLoader. I
think my one imports model definitions ok. Or maybe I just haven't
found the problem yet? (Maybe it works because I save the module in
sys.modules as both the old and the new name?)

See if it is any use to you.
https://github.com/linuxsoftware/ls.joyous/blob/master/ls/joyous/utils/wagtailcompat.py

Cheers, David.

> To post to this group, send an email to wag...@googlegroups.com.

> Visit this group at https://groups.google.com/group/wagtail.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/B4E013B0-71CE-4434-A4E5-B35A66158A00%40torchbox.com.

[Benjamin Bach]

Hi Wagtail people,

I would in hindsight warn against this module refactor, even though it's too late (and yes I really agree, it's too late now).

The main problem (from reading release notes), is that no one seems to have addressed the community effort needed to carry out this refactor. The motivation seems to be about module path aesthetics.. not exactly a benefit.

The release notes are not very clear:

While this will require some up-front work to upgrade existing Wagtail sites, we believe that this will be a long-term improvement to the developer experience, improving readability of code and reducing errors.

Developer experience points towards "improving readability"? And then the "reducing errors", what's that? If it's about spelling errors, then it's because the readability is improved? So then the same point is made 3 times :P

I can understand why someone would do this kind of refactor: There has already been a tendency towards refactors based on aesthetics in Django -- so there is a common practice that disrupting people's projects with these sort of changes is okay.

I'm used to modules being called `wagtail.wagtailcore`, I think it's fine, I'm not bothered by it. Instead of being encouraged by an update, I now feel discouraged, because it will mean extra work with no benefit.. I will probably do the upgrade anyways, because I know that not keeping up2date also has high costs.

The more elaborate our compatibility layer is, the more chance there is for things to break in unexpected and subtle ways.

Then don't do a module refactor :) If arguing against having a compatibility layer that would be helpful to people is a logic that's not about a) value creation or b) problem solving -- but is about c) a (some what hypothetical) complexity analysis of a solution to an unnecessary problem.... then we need a much stronger argument for the module path refactor in the first place!

The fall-out for users is huge (let's say 1,000 deployments * 1h avg upgrade work?), and Wagtail community will be kept busy with ImportError support questions for some time, I would presume.

Then we also get problems with all reusable application. They will invent their own compatibility layers, or they will have to support odd breakages that they didn't anticipate (for instance if their test coverage is low). And a few will never adapt and be left abandoned.

Fixing this up and releasing new versions of all the reusable apps? Let's just say another 1,000 hours of work, if it's just left for the community to fiddle with (although a small, efficient task force visiting all the reusable Wagtail apps to fix them up for Wagtail 2.0 would be much more efficient).

I hope for the future of Wagtail that similar refactors will be considered a bit more carefully, and that's my only point!

Still your fan and contributor,
Ben

[Joe Tennies]

So, I'm just starting getting a new site going. And I'm very thankful that I only had 2 external reusable apps that I really used. wagtailmenus and wagtailmedia. wagtailmenus already had a pull request "in the wings" for wagtail 2.0. I had to do the update for wagtailmedia myself. (There's a pull request already submitted.) Now, while I'm not a seasoned wagtail guy, it still took me 2-3 hours to convert it.

Django did move a module around in Django 2.0. It moved django.conf.urls to django.urls. The old location is still there for backwards compatibility (for the time being at least). Surprisingly, I found code that used a third location that was removed (django.core.urlresolvers) that had reverse still.

I agree with the points Ben made that one needs to consider that this now means more sites can't upgrade to wagtail 2.0 until all the reusable apps have been ported to 2.0. All of those nice things you added in 2.0 (like draftail and scheduling updates on a Page) end up stuck behind a really hard to cross barrier or people reinventing the wheel instead of using existing reusable apps.

I kind of view this as the "magic removal" release for Django or Python 3.x. It's a bunch of things that should've been done differently to start. That stated, realize people left Python and not all modules have been updated 10 years later. As our company's local "Python guru", I still get questions and concerns about Python 3 today.

Also still a fan,

Joe

PS: Reason I hadn't gone live on the sites previously is that I was waiting for 2.0 and drafttail to not have to retrain people. Now that I can see it going, I'm pretty excited. Thanks!

 

Cheers, 
- Matt 


-- 
You received this message because you are subscribed to the Google Groups "Wagtail support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wagtail+unsubscribe@googlegroups.com.
To post to this group, send email to wag...@googlegroups.com.
Visit this group at https://groups.google.com/group/wagtail.
To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/357496df-ec48-4d40-b7d8-c21cba815fc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Wagtail support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wagtail/m1ETi2PIwxw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wagtail+unsubscribe@googlegroups.com.

To post to this group, send email to wag...@googlegroups.com.
Visit this group at https://groups.google.com/group/wagtail.

To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/68c6f7dd-3be0-057f-f1c3-7ae51973ab90%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Joe Tennies
ten...@gmail.com