Extending and customizing Compose
App framework support
You can install Marketplace apps and custom apps in your space to customize the editing experience and integrate with other services.
Currently Compose only supports a subset of App Locations.
The following table shows the support status for the App Locations:
|App Configuration||Not supported|
|Entry Editor||Not supported|
|Entry Sidebar||Not supported|
UI Extensions are not supported in Compose.If you need custom Entry Field editors then you should consider to migrate your UI Extension into an app.
App SDK support
Not all the App SDK methods are available in Compose.
The following table displays the SDK methods which are not supported (grouped by namespace):
|sdk.navigator||openNewEntry||doesn't open new entry in slideIn editor but only creates a new entry|
|openEntry||doesn't open the entry in slideIn editor but in a new window instead|
|not implemented: calls to these methods are ignored|
Extending the Compose content models with custom fields
It's possible to extend the "Compose: Page" and "Compose: SEO" content types with custom fields of any type except Rich text. If you need to include Rich text fields in your page, consider adding a reference to a content type with a Rich text field or consider adding the Rich text fields to your page types.
Compose allows you to edit custom reference fields in the "Page settings" tab by adding and removing references to existing content. Referenced entries can't be expanded and edited directly from the "Page settings" tab, though. Instead, clicking them will open them in the Web app where you can continue editing.
Compose supports field-level and entry-level localization of page content via the locale selector at the top of the page editor. Localization for media fields is not supported, so these fields are always treated as non-localized, allowing to see and edit only the default locale’s values.
Non-localized fields are always displayed in the default locale, regardless of the selected locale. If the selected locale is different from the default one, a label is also displayed next to those fields, showing their respective locale.
Supported localization patterns and best practices
Avoid relying on required fields for localizing content. This can create a possible issue where localized required fields block publishing of an entry if that entry has not been referenced to a locale. (This is more likely to happen if you use reference fields for region-specific content). For this reason, we also recommend always enabling "Allow empty fields for this locale" when adding or editing locales.
If an entry has field validation errors in a locale where the entry isn't linked (i.e. the entry doesn't show up if you select that locale) those fields will be displayed when trying to publish the page. This allows the user to fix the issue in an otherwise unreachable value.