Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the demo more suitable for Wagtail testing #175

Closed
9 of 12 tasks
thibaudcolas opened this issue Nov 24, 2017 · 2 comments
Closed
9 of 12 tasks

Make the demo more suitable for Wagtail testing #175

thibaudcolas opened this issue Nov 24, 2017 · 2 comments

Comments

@thibaudcolas
Copy link
Member

thibaudcolas commented Nov 24, 2017

I've been trying to set up automated testing for Wagtail using the bakerydemo. Since it's also used as the default development project by Wagtail contributors, I think it would make sense for it to be the go-to project for automated and manual testing.

Overall, the bakerydemo does much more than the previous wagtaildemo so it's already a great leap forward. Nonetheless, there are many things that are hard to test at the moment, of which I made a list below. There is one general theme: more features should be used in the demo "out of the box", so that there is the least setup / content loading required when we need to test a given feature.

Here is the list:

  • Wagtail styleguide – should be enabled in the INSTALLED_APPS.
  • [ ] Making sessions last a very long time (infinite!).
  • Have different accounts with different roles, in different groups.
  • [ ] Have an account with Gravatar.
  • Have promoted search results.
  • Have redirects.
  • Have documents.
  • Have content/media in collections.
  • Have focal area used on some images.
  • Enable the image link generator (I couldn't find it, might have missed it)
  • Have revisions for some pages
  • Have pages in draft, live + draft status.
  • Add rich text using all available formats: bold, italic, p, h2, h3, h4, UL, OL, hr, embed, docs, image, link
  • Add Streamfield instances, and content, using more complex features (More complex StreamField instances #168).

Before we go creating fixtures, I think it would be good to discuss which of those things would also be useful for people experimenting with Wagtail, and which are clearly catering for testing only and should be "hidden" one way or another from the normal bakerydemo experience.

@hminnovation
Copy link
Contributor

We had quite a few conversations along these lines when first setting up the demo. The general consensus was that we should try and keep things as simple as possible for first time users, whilst giving enough complexity for people new to Wagtail and/or Django to starting getting a sense of how things work. I've no data to back it up with but personally seeing people engage with the demo for the first time I feel like we've got that balance of complexity right.

That said, it definitely could work better as a developer resource. Could one solution be to point to a specific branch for developer installs - much as we currently have where vagrant-wagtail-develop is currently pointing to the Wagtail 2.0 branch?

Agree on all counts with what we need in here. The only one I think I disagree with is:

Making sessions last a very long time (infinite!).
Given how critical login is to the general health of the CMS I think it's important that we be forced through it regularly.

@thibaudcolas
Copy link
Member Author

Closing in favour of #440 and #438. In the future if there is a need for more demo data I think we can use more specific issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants