Documentation, documentation, documentation.
The theme of our last sprint was documentation and it showed. We're super close to launching new documentation for new Faust. You'll see the updates on [https://faustjs.org] in the coming weeks.
This week the team finished Sprint 19, our latest 2 weeks of work, which was focused on polishing the new version of Faust and preparing to release it to you. We've been focusing on what to call the project, how to make sure those of you using existing Faust can continue to do so while needed as well as preparing plans for post-launch features and work that we want to focus on all while taking some time off and dodging hurricanes (you're reading this late as we're a fully-remote team and I am based in Sarasota, FL which was just hit by Hurricane Ian this week).
Most of our work was spent deciding how to best handle a new library that is vastly different than Faust has been built in the past. The syntax and other uses of moving from GQty to Apollo alone make things quite differently than it had been before. As a result we're working on solutions to ensure the new version is a separate install than what you've used in the past. This ensures, with a 4th quarter launch before the holidays, that your existing projects are safe and supported going forward. If you have, for example, "*" in your package.json for Faust (not a solution we recommend but, we realize, something a lot of people do), if we weren't careful that could break what you have. That won't be the case with the new version. Instead we're working on migration guides, package organization and more to ensure existing users are safe and supported and can migrate to the new library as needed.
Sprint 20 is focused on preparing that new release. We want to have the new Faust into your hands in the next couple of weeks and that is what we're currently working on. This includes setting up new packages, finishing testing, prepping documentation and more. We've also cleaned up our backlog and will be working on filling out future epics to ensure work on new features, such as full support for Gutenberg and the Block Editor that go beyond anything you've seen yet in headless WordPress, can kick off in the coming weeks.
Next week, on 1 October to be specific, we're also happy to announce we have an official lead developer on the team that builds Faust. If you're interacted with our support on Discord or elsewhere you've probably come across Blake Wilson. He's one of the original Faust developers and was instrumental both in the current version and the new version we're about to release. I'm happy to announce he's been promoted to Senior Software Engineer here at WP Engine and will officially be taking over the team lead spot for Faust as well.
It's an exciting time for Faust and the team building it. Personally it took me a long time to understand the value of headless WordPress. Once I came to Atlas I could see the value but the tools were still too immature to really unlock its full potential. With the new version of Faust the rocket has lifted off and I am super excited that we're finally bringing you a full framework that can grow with your projects and with WordPress itself all while making headless WordPress development as easy and powerful as WordPress heavyweights like Genesis have done for the WordPress framework over the past decade.
Let's do this!
We're 1/2 way through September and nearly finished with the first version of something completely new. This past Sprint was focused on getting the next major version of Faust ready so that we can get it in your hands by the end of this month. We're super excited about it. It's going to change everything!
The final feature of the next version of Faust was completed, post previews. This leaves us at a "code complete" point for the new version which will be ready later this month. It has all the same features as Faust currently does including authentication and post previews but adds some major new capabilities including a template system that mimics WordPress' template hierarchy and replaces GQty with the more capable Apollo library to ensure your Faust-powered site can be as powerful as you need it to be.
Sprint 19 is all about preparing for the release of the next version of Faust. The team will be splitting the code into a new repository, preparing a new site and setting up to launch the code with a brand new name.
Why a new name? The new version we're finishing up isn't just big, it's huge and a new name helps reflect that change. In addition, it helps us make sure we can continue to more easily support your existing sites already on Faust. We're excited about the change and, once we can show you more, I think you will be too.
We finished Sprint 17 yesterday, our 17th 2-week Sprint of the year. Our current focus has been two-fold: first, to release a new version of Faust using Apollo as our GraphQL library and, second, to build a plan for how to best integrate Gutenberg (the block editor) into a headless site with the minimum amount of developer friction. As far as progress on both those endeavors is concerned, the Sprint was a success.
One of our more important features in Faust has been the support of Sitemaps as implemented by plugins such as Yoast SEO and others. While we've had the feature for a while, Next.js 12.2 changed their middleware implementation rather significantly leaving the feature broken for our users. We now have a fix in place that avoids using Next's middleware and hope to have it in your hands in the coming weeks.
In addition to updating our sitemap feature, the team has also been learning Gutenberg development to better understand WordPress development as a whole. Most of our backgrounds are either in classic WordPress or in JavaScript, so Gutenberg, at least at the level we need to understand it, has been a learning experience for everyone this quarter. With the conclusion of Sprint 17 we feel we have enough experience with it to finally start looking at how we can use it to make headless development better. For example, what if you could re-use your components in both the editor and on your headless front-end? There are many questions and many avenues to pursue and, over the coming weeks, we'll be putting together a plan to do so. To me, personally, this is one of the most exciting possibilities for headless WordPress. Unlocking the potential of Gutenberg for headless sites will all for use and re-use of content on a scale that just isn't possible in classic WordPress and the potential is amazing.
Finally, we also worked to scrub a number of bugs in the Sprint including upgrading dependencies and plenty of others. Look for the results in our next release coming soon.
Our next Sprint will be focused on two things. First, better content previews for the next version of Faust. The new version will enable a whole new ability to easily develop headless WordPress sites, including its own plugin system and the ability to utilize a template system very similar to WordPress' own template hierarchy. Now we need to update our content previews to take advantage of it.
Second, we're moving beyond learning Gutenberg development ourselves and will be spending time this upcoming Sprint developing a high-level plan for how to best utilize it in headless WordPress development. Expect to see the results of these plans starting in the 4th quarter of 2022.
Finally, we'll be focusing heavily on documentation and other tasks to make sure you'll be able to hit the ground running when we re-release Faust at the end of September. We can't wait to show you what we've been working on here!
Hello folks! I’m Terri, one of the new software engineers working on the team developing Faust. I’ll be supplying the update on the team’s progress the last two weeks on sprint 16, as well as a quick peek at what we're working on for the remainder of August.
Yesterday, August 16th, the plugin system code was completed for the new version of Faust. The goal of this new plugin system is to allow developers to provide easy-to-implement solutions for themselves and other users. A plugin for this new version of Faust is a simple class with a constructor for options, and an “apply” method. This method has a function as an argument called callHook, which is a callback function to apply logic to certain types of hooks. For example, a developer may want to alter what data is fetched in the seed query, or what templates get resolved in the template resolver. Each of these actions now have a corresponding “hook” to which custom functionality can be applied.
In addition to this, plugins in the new system now have @wordpress/hooks behind an experimental flag, as well as tests that ensure that a developer’s experimental plugins have their apply methods called while those that don’t have an apply method fail silently when specified in the experimentalPlugins config property. Testing also now ensures that the possible lack of the experimentalPlugins property does not introduce any adverse effects, too, allowing developers to tinker with building plugins with less implementation.
Beyond the plugin system for the new version of Faust, we also completed an architecture document for a service to handle GA4’s new requirements with telemetry, ensuring that the team has a plan for keeping data anonymous and building a reliable reporting system. We implemented post previews and authorization for previews, too, so folks can examine posts while in the block editor.
The team is now closing in on a fix for the breaking changes introduced when Next.js took middleware out of beta. The handleSitemapRequests function used in conjunction with Next.js 12.2 will once again allow developers to easily proxy their WordPress sitemap to their headless frontend once these code changes are approved and merged.
In Sprint 17, we are also working on planning out our approach for implementing support for Next.js file-based pages. Our current data fetching conventions and abstractions work well inside the template hierarchy system, but we want to support Next.js based pages too, while maintaining the same level of functionality. Having this flexibility will help developers create pages outside of the template hierarchy without needing to create a page for every route, putting a wider range of options on the table.
Yesterday the team working on Faust finished Sprint 15 and started work on our next Sprint, 16, which we will be in for the next two weeks. The theme of the sprint was to finish porting the post previews feature to the new version of Faust as well as to address as many GitHub issues as we could.
Unfortunately we haven't yet finished the new preview feature as complexities of integrating the feature with the new Apollo library slowed the work down more than we would have liked. We should be able to complete it in the coming days but it was not completed as part of the sprint as we would have liked.
We did, however, catch up on our backlog of issues as planned. This included reducing the client bundle size and upgrading to GQty 2.3.0. We hope this work will make life a bit easier for folks currently using Faust in production.
Next up we're focusing solely on finishing out "plugin" system for Faust. This is a series of hooks that will allow folks to build on Faust for their own projects. Maybe you want to add in a feature or swap out something we're doing? No problem. Just like WordPress plugins you'll be able to extend Faust to fit your needs and, if you're so inclined, the needs of the community in general.
While the plugin system is our primary goal for these two weeks we're also still finishing up post previews and working to ensure we can get some basic telemetry data on how folks are using the framework. The latter is being done in GA4 but, due to changes in GA4, will require a bit more work for us to be able to implement it. On the positive side this will make analytics even more private due to a proxy that can mask IP address and other data. On the downside, building that proxy will mean more work for the team in the coming days. It will be worth it, however, as it can help us build the features you need in the future.
Yesterday, July 19th, the team completed Sprint 14, which is simply our 14th sprint of the year. This was one of more productive sprints, in terms of implementation, so far this year. We managed to release a new version of both the Faust.js library as well as the Faust WordPress plugin, we welcomed two new developers to the team and we worked hard to implement a way to help us better understand how folks are using the framework. Here's how it all breaks down:
The Faust WordPress plugin was updated to version 0.7.10 last week and all Faust JavaScript libraries were updated to version 0.15.7. These new versions didn't bring about any new features but they did solve some issues folks were seeing as well as updated some of the dependencies Faust relies on. You can see a full list of all the changes we made in our release notes.
In addition to new releases, our team also welcomed two new developers to the team bringing our total to 5 full-time developers focused solely on Faust. You'll see their contributions in our GitHub repo and they will help us bring the next evolution of Faust into your hands as quickly as possible.
We're not done here, though. We still have one more position open on our team for a staff developer. If you're interested in helping take Faust to the next level, apply now and let's talk.
The big goal of Faust.js was in implementing some basic telemetry into Faust so that our teams and stakeholders have some measure on how the product is actually being used. Note that this telemetry, while code complete, has not launched in a release yet.
To implement the telemetry we're using Google Analytics, a common analytics partner in WP Engine products, to collect data on version information and other build parameters solely from the JavaScript builds completed with Faust. All analytics are opt-in only so new users, once launched, will see a prompt asking you if you're willing to login. This can safely be bypassed, for those interested in doing so, without sending us any data. While we'd love to see you participate in helping us collect build data, and hope you'll do so, failing to opt-in means nothing at all will be transmitted to Google or elsewhere.
You can expect to see this in a new release in the coming months as we first finish a comprehensive privacy policy for the feature.
In Sprint 15, which started yesterday, the team is focusing on implementing content previews in the next version of Faust as well as reducing some technical debt that has lead to issues on our GitHub repo. Expect to see a new, faster, release as a result at some point in the next two weeks.
We launched this blog 7 months ago with a goal of keeping you informed of what is going on in the development of Faust.js as well as to help you get started using the framework in your own projects. To date, we simply have not prioritized keeping up here on the blog and it is time for that to change.
The WP Engine Headless (or WPE Headless) plugin has been renamed to FaustWP starting with version 0.7.0.