Wrap-up Dutch Wagtail sprint

Ede, The Netherlands

In the start of 2015 I started introducing Django Wagtail as a potential CMS for building new websites. We did a test, in the form of a two weekend sprint, to see how easy it would be to build the new lukkien.com website. I found it amazing how easy it was and especially the usage of the just released StreamFields. Since that point I decided to make Wagtail the preferred platform for all upcoming websites of all kind of sizes.

At Lukkien, were I worked for several years as lead developer and spend my last year as Technical Director, I got in contact with Tom Dyson (Co-Founder of Torchbox, the company who has released Wagtail to open-source) and started sharing our experiences. From that point we started contributing small pieces of code and were getting familiar with the very kind people involved with Wagtail.

After a visit of Tom at the office and Wagtail had its first sprint in Cape Town we decided that Ede (The Netherlands) would be a perfect spot for hosting the second sprint!

Sprint goals

Most of the attendees were already familiar with Wagtail. I found it amazing to see how many production websites build with Wagtail were already shipped out by them. With these experiences we noticed that there wasn’t that much time needed to keep people get started (thanks to the simplicity of Wagtail!).

Previous to the sprint people had the change to provide their preferences on several suggestions to do for the sprint. Support for multilingual content turned out to be the most populair sprint goal (probably because of the awesome job on the multilingual proposal during the first Wagtail sprint in Cape Town)

After deciding what the sprint goals would be (no multilingual, since a two day sprint would be to less time to deliver something useful) it was time to get our hands dirty!

In the following chapters I’ll wrap-up the results per goal and other topics we talked about during the two day sprint.

Photo taken during the sprint in 1 of 2 sprint rooms

Django 1.10 compatibility

Since Django 1.10 will be released shortly Mikalai (Torchbox) and Paul (Lukkien) started working on making the Wagtail codebase compatible with Djang0 1.10. After fixing quite a lot of oneliners and doing some deep testing, the result turned out pretty awesome! Within 2 days Mikalai and Paul accomplished quite a lot.

Currently there is still some work left to do, review some PR’s, fix some minor issues and do some testing… The status of all of those todo’s can be found on GitHub.

Looking forward to Django 1.11

There was a discussion going on if we need to develop upon the Django master branch to help out testing Django fixes. Maybe it’s also a good change that, If we do so, the people at Django are getting familiar with the Django Wagtail platform…

Performance on StreamFields

Michael van Tellingen (self employed Python expert and core-developer of Django Oscar) ran into a performance issue on the StreamFields earlier during a implementation of Django Oscar with Wagtail on a high traffic e-commerce platform. With a workaround he already quite tackled the issue… but we found it that important to fix this issue in the core of Wagtail.

Michael, Roel a.k.a. “The Lion” Bruggink (FourDigits) and Matthew Westcott (Torchbox) discussed for hours what would be the best solution to fix this. After providing a quick fix early on the first day and we thought the issue was solved, it actually turned out to be a real brain-teaser :). During day 2 of the sprint the performance issue was finally solved, a pretty nice accomplishment if you ask me!

The issue only occurred using the StructBlock and ListBlock on large scale on a single page. By implementing lazy loading, the performance has become much better! The relevant pull request can be found here for more in-depth code insights (also see this commit).

Matthew, Roel and Michael arguing about how to solve the performance issue (from left to right)

Integration with Django Oscar

During a visit with Michael, Lars and myself at Torchbox Charlbury we showed the already pragmatic integrated version of Django Oscar. As Tom often get questions “Can Wagtail be integrated with e-commerce?”, a nice sprint goal would be to have a proper documentation on how-to setup this integration.

From Lukkien offices, multiple developers already have experience with Django Oscar as well as Wagtail. Peter (Lukkien) and Henk-Jan (Lukkien) were really excited to work on this sprint goal together with Coen (FourDigits) , who has also worked with Django Oscar before.

With relatively less changes to the code the integration has been done successfully. The guys did an awesome job on creating a demo project on GitHub and providing a clear documentation how to setup this project.

However there are still some small fixes to do, we are happy to open-source this integration.

Finally Peter, Henk-Jan, Coen and Michael came up with the idea to create a Python package for this integration to make some things a little bit easier (not decided yet what the planning of developing the package will be).

Explorer component in React

During the sprint in Cape Town, Josh (Springload) made a draft version of the Explorer component written in React (and Redux). We were keen to continue working on this component and try to make a pull request out of it which would be ready to merge into the master branch of Wagtail.

After defining the things left to do, we ran into multiple issues which needed to be solved first and some discussions about coding standards we should be agree on (the guidelines in the current documentation seemed to be outdated).

Thibaud (Springload), Janneke (Lukkien) and myself started working on this component while Maurice (Lukkien) and Dennis (Lukkien) started finding their way into React and how-to contribute for Wagtail.

The initial draft version of the Explorer component we continued to work on

After quite a lot of discussion about code standards and how we should make React components part of the Wagtail admin module, we did quite a lot of related things besides continue working on the Explorer component:

Updated endpoints and xhr request to math the updated REST API, which Karl (Torchbox) partly has been working on

Translated the component with a quick fix (key-values in JavaScript). On long term we planned to integrate the Django internationalization JavaScript (since we ran into some makemessages issues we decided to leave this out of the MVP version of the Explorer component)

Decoupled ESLint configuration and published it as a standalone package (eslint-config-wagtail) on NPM (third parties can now also use the same JavaScript config rules of Wagtail for ESLint by installing this node module)

Fixing lint errors (a lot!) based on the JavaScript guidelines, which still has some work left to do before making a pull request

At the end we still have some work to do before we can create the final pull request to the Wagtail master brach. Also we need to discuss the coding standard we decided to use back with Josh.

Admin and Search API

Karl and Thibaud discussed the latest changes Karl did on the Admin API. Currently is it completely done for handling all kind of requests coming from the new Explorer component.

Within the API it is now possible to specify which fields should be retrieved in the response. Booleans are now passed as true/false instead of 1/0 and a new method in the Search API should make it possible to get the score combined in the response (the score coming from elasticsearch). You can see the pull request from Karl on GitHub.

Wagtail release cycle

In the “early” morning of the second day Mikalai made a presentation about how to improve the release cycle of Wagtail and were it should be going on long term. Afterwards we had an open discussion about this topic and were Wagtail should go in general.

As we decided to publish all meeting notes (also the weekly ones at Torchbox) to GitHub, please see the outcomes and discussions we had on the temporary GitHub repository (while Tom is trying to get in hands of github.com/wagtail). Thanks Thibaud for these notes!

“Other stuff”

New block types (Integer, Float, Regex, Email and Decimal)

Oktay (Lukkien) did a great job by creating even more handful StreamFields Blocks into Wagtail. Thanks Andy (Rock Kitchen Harris) for helping and reviewen those as well!

Modeladmin

Andy has been written more documentation for the modeladmin integration in Wagtail.

Michael and Matthew added support for pytests (see #2735). It seems out pytests is able to run the testsuite in parallel which gives us a faster execution time of all the tests (and there are quite a lot!).

Dutch Wagtail Meetup

I initiated some months ago a Dutch Wagtail Meetup group. We’re pretty excited to host the first meetup in a short period of time. The venue (Amsterdam or Utrecht) is almost arranged, at that point we will be sending of requests for speakers and attendees!

Wrapping up

After two days of sprinting with 20 people I think we can look back on a pretty damn productive sprint!

It’s really nice to see the community is growing extensively and people are finding their way quite easy into Wagtail development.

I really enjoyed (and a bit proud) of making this sprint available at Lukkien, who has been an excellent host. A big thank you Lukkien for facilitating all the snacks, lunch, BBQ, hotel rooms and pickups for the attendees!

Also double thumbs up for Torchbox for sending their lead developers over and spending that much time in improving the quality of Wagtail and it’s community.

Really looking forward to the next sprint with all the guys from Lukkien, FourDigits, Springload, RKH and individuals involved with Wagtail! Maybe New Zealand will be a nice place for the third sprint ;).

Having a great BBQ on the end of day 1

No doubt I missed something to note in this blog post, please feel free to contact me if I need to update or add some context!