Hello everyone!

This is my first release cycle officially as a core developer. I've been a bit bogged down with school since the new year but I was able to make some more improvements on the new Admin Panel released with beta 15. These improvements should resolve most of the headaches experienced from developer to admin.

  • Admin UX changes (flarum/core2593)
    • Abstracted reusable functions into AdminPage & refactored all admin pages to take advantage
    • Added some more functionality when registering settings for an extension (flarum/core2498)
    • Improved the overall extensibility and readability (converting to JSX) of components and pages
    • Simplified the extension categories to just 3: Features, Themes, and Languages
    • Others (flarum/core2503, flarum/core2504, flarum/tags116)
  • Small change that prevents raw bidi functions from getting pushed into the DOM (flarum/core2602)
  • A few other WIP changes that will not make it into beta 16 (flarum/core2611 & flarum/core2606)

While we're at it, here's my own update:

I've been working on the access token refactor (flarum/core2651)

For regular forum users, there will not be much to see. We implemented multiple security improvements previously described on our security roadmap, and this will allow introducing more session management tools to the forum in the future.

For anyone building a custom Flarum integration, this will bring a more clear and flexible framework. Unfortunately it comes with a range of breaking changes for integrations that might have relied on some of our previously undocumented features.

If you want to voice your thoughts, you can take a look at the first comment of the pull request which contains a summary of all the changes. I have also opened a new issue to discuss reducing the lifetime of remember me sessions flarum/core2659

A wild QA member appears!

I don't believe the community has heard from the QA team yet, but in terms of development, I am here to report our ongoing battle with QA automation 🙂

@katos and myself have spent restless months trying to figure out the best approach to QA automation and we went with Cypess. For those of you who don't know what Cypress is, it's a platform focused on E2E (End to End) automation. Part of being in QA is finding ways to automate most of our manual testing so that we can spend time elsewhere where it is needed most. Whether that be with our families, loved ones, other Flarum related tasks such as helping the rest of the team, automation saves so much time and man/woman power once it's set up and running.

The end goal is to fully automate our front end tests to make sure we find as much bugs as possible before a release so that the devs can either work on them before we publish a release, if the schedule allows, or work on a patch after a release to address these bugs, or even tackle them in a later release depending on it's priority.

We already have back end unit tests, thanks to our lovely development team for ruthlessly working on those so we don't have to essentially add that to our Cypress test collection. Nonetheless, one of our focuses in QA right now is automating as much as our processes as we can.

If being a non-experienced/profession QA tester has taught me anything, developing your tool-belt is only half the battle, the rest is getting those tools to work on your behalf and making sure your tests are easily readable for the next QA person to take a crack at.

To give you all an idea of the kinds of tests we are working on and figuring out what works best with our application, here is a simple login form test that I've been working on to get a feel of how Cypress can benefit us long-term:

Simple right? Well lets say you want to dig a bit deeper and stray from best practices:

Now we're digging deep!

The problem with the above code is that it falls away from best practices when developing test cases; we don't want to do this much in a test if we can easily simplify it in smaller and more organized tests.

In summary, QA testing isn't all about clicking on buttons and making sure everything works as intended in the UI; We get our hands dirty as well in some code and have the assistance of our dev team when we get stuck 😉 (shoutout to @askvortsov for helping me with an auth issue using the Flarum API!).

We are far from getting our automation pipeline working at 100% with most if not many of the test case scenarios created, but the foundation is already there for us and so is our CI/CD pipeline using GitHub Actions (shoutout to @askvortsov again for assisting QA with that as well!!).

P.S. please excuse my rambling if some of the things I said above doesn't make any sense or isn't essentially correct; it can be a huge learning curve especially for not having professional experience in QA. We all have to start somewhere right?!
😃

Today, 06/03/2021, the QA team (@IanM @Ralkage and I) got together to conduct our first ever team meeting!
I am pleased to report that this meeting was very successful, and we discussed a range of topics to ensure that we continue to deliver the highest quality product that we possibly can; with this in mind, a range of topics were discussed.

1) Our automated tests will be split out to individual test cases, allowing us to ensure that core functionality of Flarum continues to work with every commit – this allows us to quickly capture any issues, and create fixes where necessary, or revert commits where required.

2) We will be introducing a change to our QA suite to ensure that we test against a ‘golden image’ that we revert to prior to any test cases. This will help us to ensure that outside variables are eradicated and allows a fair baseline for comparing performance metrics between tests, allowing us to identify any performance impacts following a commit.

3) With thanks to @IanM we will be introducing Docker images (😮) to the suite. This will allow our QA members to quickly spin up local test suites on which they can test a range of PHP versions, Server types (NginX / Apache) and also to ensure a standardised testing environment across the team.

4) We will once again be reaching out to Cypress’ staff team to ascertain an open source license so as to gain access to priority support, better data retention periods for our test results, video recordings of tests, and more!

5) We will be creating a console job to clear the database and revert to a golden image prior to any test – again to standardise our test suite.
6) We will also be creating a QA lab, allowing our members to test and create any QA tool on an isolated instance without risk of ‘spill-out’

7) We have discussed our current testing checklist, and are pleased to announce that we will be adding additional tests for multi-browser, and multi-device (and OS) checks.

flarum_session cookie is uncategorized in beta15. Is it possible to categorized this cookie as Necessary cookie in future updates?

This will reduce the incident of it being turned off by users.

    Ffuser1 what do you mean by categorized? I don't think Flarum includes a list of cookies or their usage anywhere.

    Are you referring to some HTTP headers, a third-party database or a Flarum extension maybe?

        clarkwinkelmann I submitted site for check at cookiebot.com for General Data Protection Regulation (GDPR) compliance check and the report shows that my site sets a cookie with name flarum_session. The cookie was listed as uncategorized. I think this usually appears if a cookie doesn't have a description of its purpose.

            Ffuser1 that information seems to be part of the database maintained by the service itself.

            From https://www.cookiebot.com/en/functions/

            Cookie repository

            Cookiebot maintains a global cookie repository with descriptions of the purpose of commonly used third party cookies.

            When Cookiebot identifies a known cookie on your website it uses the information from the knowledge base to describe the purpose of the cookie to your website visitors.

            From the global repository Cookiebot creates a local repository after the first scan of your website.

            In the local repository you can change any applied description and set purpose descriptions on all cookies identified by the scanner.

            On subsequent scans Cookiebot reuses information from the local repository to describe both first and third party cookies.

            I assume once a number of Flarum owners register their website and manually flag the cookie purpose, their database will be updated to automatically guess it for future clients.

            I don't see any way for software vendors like us to submit anything to them.

              Perfectly on schedule, yesterday our QA team started testing the upcoming beta 16 release. @katos @Ralkage @Deebug and @IanM have since already completed over half of the testing tasks!

              Since most of our open issues for stable have been completed in this release we are hoping to tag the release as 0.1.0-rc.1 meaning this will be a release candidate!

              If all goes well, by the end of next week we will be shipping this new version 🚀

              Feel free to give this new version a spin on https://nightly.flarum.site (running php 8).

              One thing that might hurt is that making Flarum compatible with PHP 8 made us drop support for PHP 7.2. So if you can upgrade your PHP version to at least 7.3 (7.4 preferred) right away; the current Flarum version is compatible with that and so is RC 1.

                luceos is there anything special that was introduced with PHP 8? I mean, is upgrading mostly painless or is there the risk that some extensions break?

                    We are looking for someone to join our staff team in the role of Assistant Verified Community Coordinator. Currently @Kyrne and I work with our Verified Community Leaders to onboard them, help them and see whether they still adhere to their agreement. With the increasing number of these wonderful communities to be part of our ecosystem and both our responsibilities it would be great having someone assist us.

                    What would you do?

                    • Keep in touch with each Community Leader, pinging them on occasion on how things are going. Building a relationship and gathering feedback for our own community, but also for our product.
                    • Do a periodic screening of each community to look for any breach of agreement (sounds sad but it's a matter of principle not necessity).
                    • Report back to Charlie and the Foundation Board about anything that we should now about.
                    • Onboard new Verified Communities, including preparing the Agreement (template with a couple of fields).
                    • Help us further increase the value of these communities in our ecosystem, for instance by writing about them, by offering more (ideas for) tooling etc.

                    What I think is required?

                    • A friendly nature, even in tense situations you have to keep your cool.
                    • Excellent communication skills in at least English.
                    • Availability, let's roughly say half an hour every day (meaning regular involvement is necessary).

                    Feel free to ping me on Discord luceos#0001.

                    Just so that this is clear: this is non-paid position, like everyone else in the Flarum organisation (including the board).

                    Reading from the current progress and everything being said, plus the new job posting... Is Flarum moving into a paid product in the future? It sounds like that is the path you are aiming for.

                      ICANN Absolutely not. Being free and completely open source is an important part of Flarum's mission: the official entity backing us is a foundation, not a for-profit company. The core product is, and will always be, free and open source.

                      The "verified community" program (described on our site) is designed to provide non-english-speaking communities for Flarum users and developers. Note that one of the requirements is not being able to sell commercial products as the community.

                      The recent progress and momentum is the result of a LOT of procedural changes (described here) and many, many hours of volunteer work put in by our amazing team, contributors, extension developers, and ecosystem. (on an quick tangent, we could always be going faster! If you, whoever is reading this at the moment, has development experience/interest and is interested in contributing, we have a list of good first issues and documentation on how to get started)

                      I will note that one of our goals is to increase commercial activity around Flarum by unaffiliated entities. More and larger groups using Flarum means more money in the ecosystem for paid services / support / products, means more developers and contributors to Flarum. That in turn results in more extensions, faster core development, and better long-term stability. This includes:

                      Among others. Note that none of these are "official" or formally tied to the Flarum Foundation, and all of these are products and services around Flarum, not anything to do with core itself.