Since the last monthly update, we have been fixing 24 bugs and made 41 enhancements. Most of them were about the documentation or concerning GraphQL. But the most significant improvement is the reduction of the build time, which has been reduced by 30% (2 minutes instead of 3 minutes on recent computers).
We are going to reach 20,000 stars on GitHub in the next weeks. We are keeping cool about it, but it proves that the Strapi project is more and more popular. It means a lot to us to see that the community appreciates what we do. It is also a way for us to know we are going in the right direction. Thank you very much for your support 🤝
And if you want to get even more involved, we are still looking for our new teammates! Feel free to check out our open positions here.
We made a significant improvement to the developer experience by reducing by 30% the build time. It has been made possible by removing the node-sass dependency and by updating the Webpack configuration. With these updates, the migration to styled-components we initiated a couple of months ago is now complete.
For more details, you can have a look at the GitHub PR here.
Settings Manager plugin deprecation
The Settings Manager plugin is the first plugin developed by the core team. This plugin was created when the vision for Strapi was closer to being a framework to build API in minutes than the headless CMS to manage content that it is now.
This plugin has not been maintained as it should have been, and only very few advanced developers were able to use it.
So for all these reasons, we decided to deprecate it. But if you were using it, don’t worry, you won’t be lost by editing the configuration by yourself. The documentation is complete to help you custom the settings.
As you might know by reading our latest post, we are going to start the development of a new feature: the Webhooks. A webhook can also be called a web callback. It is a simple way for an app A to provide real-time information to another app B: in other words, you set a URL that will be requested every time an event happens.
In the context of a headless CMS, it can be beneficial, for example, to rebuild the frontend *as soon as a content editor saves a new article. Another use case could be to *send a welcome email using Mailchimp, Sendgrid, or Mailjet API when a new user is registered.
Please note that the design and preview are not exactly what’s going to be featured in the latest version.
We also limited the scope of the feature but made it wide enough to work with most use cases. We will add more features in later versions, like the ability to custom HTTP verb, payload, or fine-tuned events.
Please find the up-to-date public roadmap by clicking here. We are on track to deliver what we expect for the end of the year, which is:
- Dynamic zones with new Components concept
- Media Library
But our roadmap didn’t mention one thing we are also focusing on: enhancing the onboarding process for new users. We are creating a Guided Tour for the new Strapi users.
We got a lot of insights saying users were confused about what to do after the creation of the first admin user. This guided tour will help them understand the first steps to get them started and see the value they can get from Strapi.
Security and critical issue
This month has also been marked by the discovery of a critical security issue. We fixed it and released a new version of Strapi in less than one hour. It proves how fast and how reactive we can be. However, it also highlighted the limits of our security protocol.
We took the decision to create a new security issue template on GitHub and to add a Security Policy. It asks the user who discovers the issue to reach us on Slack (DM) or to use the dedicated email address: security[at]strapi.io.
Our goal with this new process is to protect our users by reacting the fastest possible, but also to minimize the spreading of the news: ill-intentioned people could make use of this information to attack community members’ applications.
This is also why we highly recommend you to update your Strapi version to the latest.
I am going to create a new series of blog posts to explain the product decisions we took. I think there is a lot to tell and explain why some choices were made. The series will be called “A Product Story,” the first article should be available in a couple of weeks. I hope you will enjoy it. It will give you more insights into how we work and how we make decisions.
Also, feel free to engage with us and ask any questions you have by posting a comment below. We look forward to answering you!
See you soon 👋