Development
anchor

Watch Command - Removed Redundant Logs (#2603 )
anchor

When running the webiny watch command with the logs forwarding option, except for the actual logs, developers would also receive the underlying local tunnel URL, over which the logs would get forwarded to the developer’s machine.
Removed Redundant LogsRemoved Redundant Logs
(click to enlarge)

With this release, the redundant URL won’t be appearing anymore.

Destroy Command Now Works Even if the Project Wasn't Previously Deployed
anchor

With this release, we’ve fixed an issue with the webiny destroy command, where, in order for it to work correctly, a Webiny project application had to be previously deployed.

This is no longer the case. A Webiny project application doesn’t need to be previously deployed in order for the command to work.

Thanks goes to @ryohei-kamiya for discovering this issue! ❤️

Project Applications

Learn more about project applications and project organization in general, in the Project Applications and Packages key topic.

CI/CD Scaffold - Workflow Files Are Now Correctly Deployed (#2601 )
anchor

Prior to this release, upon using the CI/CD scaffold, the GitHub Actions workflow files would not be correctly generated in developer’s GitHub repository.

This has now been addressed. All the GitHub Actions workflow files should be generated correctly.

Watch Command - Introduced the hook-before-watch Lifecycle Event (#2607 )
anchor

We’ve introduced the new hook-before-watch lifecycle event to the webiny watch command.The Build and Deploy Hooks has been updated to reflect this change, so check it out to learn more.

Ensure WCP-Related Environment Variables Are Correctly Assigned With the Watch Command (#2609 )
anchor

While using the webiny watch command, we’ve noticed that the relevant Webiny Control Panel (WCP) environment variables would get removed from the previously deployed AWS Lambda functions, which causes the link between developer’s Webiny project and WCP to be temporarily broken.This has now been addressed. The link between the Webiny project and WCP should stay persistent, no matter if the project has been deployed via the webiny deploy command, or a developer is just doing development with the webiny watch command.

Admin App
anchor

Improve Dashboard Widgets Rendering (#2608 )
anchor

We’ve recently noticed that adding more widgets via plugins causes them all to be rendered in the same row, which eventually starts looking bad. In this release, we tweaked the layout in such a way that the widgets are nicely laid out in rows of 3 items, and all widgets within each row will be of the same size. The CTA button is now also always pinned to the bottom of the widget to have them all nicely aligned within each row.

Dashboard WidgetsDashboard Widgets
(click to enlarge)

Register and Sort File Type Plugins in the Right Order (#2605 )
anchor

Our File Manager supports custom file type renderers, as shown in this tutorial . However, at some point in time, we switched to that <Admin> component, which configures the entire admin app, and we unknowingly caused a change in the order of plugins registration (defaults vs. user-made plugins), which affected the logic of picking the right file type renderer.

With this release, we’ve fixed the order of plugins registration specifically for the File Manager, and also improved the decision-making logic within the File Manager itself.

A big shout-out goes to Marco Starker for contributing a solution!

Clear Apollo Cache When Content Model Is Deleted (#2602 )
anchor

This was a very peculiar bug with Apollo Client and Headless CMS content models, on the client side. If you deleted a content model, and then recreated a model with the same name (which results in the same modelId), you’d run into weird behavior and validation issues. This was caused by Apollo Client cache still containing the old content model. Note that “delete” is just a GraphQL mutation, and Apollo doesn’t know if you actually deleted anything, or if you want to delete something from cache. So this is something we had to implement ourselves, and do a cleanup of all normalized cache data related to the deleted content model.

Other entities in the system don’t suffer from this issue, because they all have unique IDs, unlike content models, which have a modelId, a human-readable string, which can be recreated.

This has now been addressed, and you can now safely delete and recreate content models with the same name.