Please be aware of an upcoming change to our rollback policy for headless sites hosted on WP Engine's Headless Platform.

We're updating the retention policy for our rollback functionality.

Starting , you will only be able to roll back to versions of your site that have been deployed within 90 days.

Please take some time before December 2nd, to review your site's version history and ensure your deployment workflow accommodates this new policy.

If you have any questions or concerns about this change, please don't hesitate to reach out to our support team. We're here to help you navigate this transition smoothly.

We're happy to share that Headless Platform now supports pnpm!

pnpm is an alternative package manager to npm and yarn, offering faster installation times and more efficient disk space usage through its unique approach to dependency management.

This addition gives our users more flexibility in managing their JavaScript dependencies, potentially improving build times and reducing storage requirements for their projects.

Visit our documentation for more details.

We're excited to announce significant improvements to our Runtime Logs feature, designed to streamline your debugging process and provide deeper insights into your headless front-end application's performance.

The runtime logs view provides real-time insights into your app's operations, errors, and custom log messages.

Runtime logs are retained for the past 24 hours for all environments.

We believe these enhancements will significantly improve your ability to diagnose issues and optimize your headless WordPress applications. As always, we're eager to hear your feedback!

Our new npm package enables selective edge cache purging for headless WordPress sites, allowing developers to clear specific pages or groups of pages instead of the entire cache.

Previously, purging the edge cache for headless WordPress sites on our platform was only possible at the environment level, which meant clearing all cached content indiscriminately at the edge.

While this approach ensured that content was refreshed, it also resulted in unnecessary purging of other assets, leading to inefficiencies.

WP Engine now provides a framework-agnostic npm package for purging the edge cache of your headless WordPress site at a granular level with .

Instead of purging the entire cache, you can execute the following:

This package can be integrated into an API endpoint in your application, allowing selective edge cache purging triggered by various sources, such as WordPress plugins or hooks.

For more details, examples and information about rate limits visit our documentation.

on the Headless WordPress platform is a check that runs at a high frequency at the environment startup - and then periodically while the environment is running to ensure it is operating correctly.

Once set up, during every deployment the platform will wait for the health check to respond with a successful response (HTTP code and ) before marking the deployment as successful.

Then, if the environment starts failing while it’s already running (health check will start returning HTTP code ), the platform will restart the environment.

A health check must be configured by the developer to be enabled for each of the environments that they wished to be monitored.

By default (without the HTTP health check enabled) Headless WordPress platform checks if your environment has bound to a port (see more details in our documentation). Once it has done so successfully, the environment will be marked as healthy and the deployment as successful which means that your environment is ready to serve the traffic.

If the health check is enabled on your environment, it will instead wait for the environment to respond with an response before marking it as healthy.

By default (without the HTTP health check enabled), if the environment is bound to a port our platform will not treat it as unhealthy if it starts returning HTTP responses.

However, once the health check is configured, the environment will be restarted if it starts returning HTTP responses.

For onboarding guide and additional details about this feature please visit our documentation.

We are excited to announce the beta release of support for Next.js On-Demand Incremental Static Regeneration for Pages Router on Atlas! 🎉

This feature allows you to manually trigger the revalidation of static pages based on specific events, ensuring your content is always up-to-date without the need for a full site rebuild.

Visit our documentation for a detailed onboarding guide.

For more information about current limitations visit our documentation.

We're eager to hear your feedback! Please use our WP Engine feedback form to contact us.

Stay tuned as we continue to enhance our platform with more features to keep the content of your headless WordPress site fresh and up-to-date!

We're thrilled to announce the launch of improved support for Next.js Incremental Static Regeneration (ISR) on Atlas.

In most cases, Next.js Incremental Static Regeneration (ISR) works as expected on Atlas - however, there are two issues:

Our solution for ISR support effectively addresses both issues, ensuring your site always displays the most recent content, regardless of traffic patterns. If your sites use Next.js Incremental Static Regeneration, we recommend using package to ensure your content is going to be up to date regardless of the traffic patterns to your sites.

Currently, on-demand ISR is not supported on Atlas. However, our team is actively working on adding this feature to our platform. Once it’s available, the use of the package will be required to enable on-demand ISR on Atlas.

In the meantime, we are excited to offer our users the opportunity to start utilizing this enhanced functionality on their headless WordPress websites.

Make sure to check our documentation for detailed onboarding information.

Should you have any feedback, please submit it using the our feedback form.

Following the official Node.js release dates, we’re ending support for Node.js version 16 on Atlas, effective May 6th, 2024. This decision allows us to focus our resources on supporting newer versions of Node.js, which include critical security updates and performance improvements.

If your applications or projects currently use Node.js version 16, they will continue to function without interruption. However, beginning on May 6th, any new builds of your Atlas applications set to utilize Node.js version 16 will not succeed. To avoid this issue, you'll need to upgrade your site to Node.js version 18 or newer.

We strongly encourage you to upgrade to one of the newer versions of Node.js supported on Atlas as soon as possible. This will ensure your applications can be updated seamlessly.

For the latest insights and updates, please ensure you visit our changelog regularly. It's your go-to source for detailed information on new features and improvements, helping you stay informed and maximize the benefits of our offerings.

We understand that this transition may require some adjustments, and we are here to assist you every step of the way. Our team of headless WordPress experts are available 24/7 to assist with any questions you may have.

Thank you for your understanding and cooperation as we make necessary enhancements to continue providing you with the best service possible. We appreciate your support and are excited to see your projects thrive on our platform.

We're excited to announce the launch of our new Environment Variables Management Screen, a dedicated feature designed to simplify the management of your project's environment variables.

This update reflects our commitment to improving your development workflow and user experience. Stay tuned for more UX updates in the upcoming weeks!

We're keen to hear your thoughts on this new feature. Share your feedback and suggestions on how we can further improve your platform experience via our feedback tool. Our team reviews all feedback suggestions immediately!

Happy coding!