Removed APIs

Overview

As mentioned in the changelog, with this release, we’ve removed a couple of frontend and backend JavaScript APIs that were marked as deprecated in previous releases.

In this guide, we’ll go through the list of deprecated APIs and their replacements.

Headless CMS

Removed Methods Related to Checking Security Permissions (Performing Authorization)

We’ve removed a set of methods related to checking security permissions (performing authorization) that were accessible via the context.cms.permissions object. To provide more context, here’s an example of how the object could’ve been used in a simple CmsGraphQLSchemaPlugin plugin:

In the example above, the context.cms.permissions.entries.ensure method is used to check if the current user has the required permissions to read entries.

With this release, the context.cms.permissions object has been removed. Instead, you should use the context.cms.accessControl object to perform the same checks.

If we were to rewrite the previous example using the new context.cms.accessControl object, it would look like this:

RenamedcreateCmsModelandcreateCmsGroupPlugin Factory Functions

We’ve renamed the createCmsModel and createCmsGroup plugin factory functions to createCmsModelPlugin and createCmsGroupPlugin. By having a more explicit name of the function, we’re making it more clear what the function actually does.

With the 5.40.0 release, the old functions will be still available, but do note that they will be removed in the upcoming quarterly (5.41.0) release.

Page Builder

Multiple legacy methods used for subscribing to Page Builder application’s lifecycle events have been removed.

Pages

Menus

Page Categories

Page Builder Settings

Page Builder Installation

AppPbWebsiteSettingsReplaced WithWebsiteSettingsConfig

AddPbWebsiteSettings component to add website settings was replaced by WebsiteSettingsConfig. This was done to enable more features, and more control over the website settings view.

Until this release, you would use AddPbWebsiteSettings like this:

If we were to rewrite the previous example using WebsiteSettingsConfig, it would look like this:

Notice how, besides the code itself, the import changed; the WebsiteSettingsConfig is now imported from @webiny/app-page-builder. With this new config, we recommend creating dedicated components for your elements. Usage of children prop is no longer supported.

I18N

Multiple legacy methods used for subscribing to I18N application’s lifecycle events have been removed.

Locales

Installation

File Manager

RemovedFileManagerFileTypePluginClass

We’ve removed the FileManagerFileTypePlugin class, which was used to define custom file types in File Manager. More specifically, the class enabled developers to introduce custom file preview and custom file actions for all files of a specific type.

With this release, instead of using the FileManagerFileTypePlugin class, developers are encouraged to implement custom file preview and custom file actions using the new React components, both of which is covered in the following guides:

• Custom File Preview
• Custom File Actions

Forms

Removed theformObject FromBindComponent anduseBindHook

A reference to form was removed from the <Bind> component render prop, and useBind hook. You should now use the useForm hook to get a reference to the parent Form object. This was done to optimize re-rendering, and also make a clear separation between the form itself, and bindings to the UI.

Until this release, you could get a reference to the form instance from Bind’s render prop, like this:

From 5.40.0 on, you will have to write this differently. More often than not, you’re adding new inputs to existing forms via plugins, so you’re just mounting <Bind> elements, or use the useBind hook. To get access to the form object, you’ll need to use the useForm hook, like this: