Editable regions and record editing¶
This is an introduction to configuring and customizing Frontend Editing. You can create frontend-editable regions using Fluid ViewHelpers or TypoScipt.
For in-depth configuration options, see Configure and Extend.
Fluid Styled Content¶
Basic Fluid Styled Content override templates with frontend editing enabled are included in the extension. To use them, include the static TypoScript template "Editable Fluid Styled Content v9". The templates are based on Fluid Styled Content for TYPO3 v9. Templates for other versions may be included in the future.
Custom Fluid templates¶
Custom fluid templates use ViewHelper Reference, especially the contentEditable ViewHelper.
Note
If you are using Fluid templates, but not fluid_styled_content on the website, editIcons must be set manually.
lib.fluidContent {
stdWrap {
editIcons = tt_content:header
}
}
CSS Styled Content¶
If the installation is using the old css_styled_content extension, the functionality works out of the box and you can start editing at once.
TypoScript¶
If you are rendering elements with TypoScript only, you can define editable
regions using the editIcons
property. This example makes frontend usernames
and email addresses editable.
page.20 = CONTENT
page.20 {
table = fe_users
select.pidInList = 38
renderObj = COA
renderObj.10 = TEXT
renderObj.10 {
field = username
wrap = Username:|<br/>
stdWrap.editIcons = fe_users: username
stdWrap.editIcons.beforeLastTag = 1
}
renderObj.20 = TEXT
renderObj.20 {
field = email
wrap = Email:|<br/><br/>
stdWrap.editIcons = fe_users:email
stdWrap.editIcons.beforeLastTag = 1
}
stdWrap.editIcons = pages:users
stdWrap.editIcons.hasEditableFields = 1
}
Custom record editing¶
There is a possibility to use the edit button when a single extension record is present. What then will happen is that an editor clicks the edit button and a modal with the form engine for the records is displayed instead of the plugin setup.
For example in this case a configuration is added so that it is possible to edit a single news record. As long as an extension have records it is possible to add any kind of records.
Tip
Frontend Editing ships with the configuration to make News extension records editable out of the box!
config {
tx_frontendediting {
customRecordEditing {
tx_news_pi1 {
actionName = detail
recordName = news
tableName = tx_news_domain_model_news
listTypeName = news_pi1
}
}
}
}
An example News template with support for Frontend Editing. Note that the headline, teaser and description are inline editable.
Handling fields with non-standard rendering¶
With non-standard rendering, we mean the fields that are no rendered the same way in the TYPO3 Backend and Frontend.
Problem¶
A good example is the standard "List" content element. In the Backend form, the
bullet points are entered into a plain-text field, with each bullet point
separated by a new line. In the frontend, these bullets are rendered as proper
HTML lists, using the <ul>
, <ol>
, and <li>
tags. When the data is saved in
Frontend Editing, the frontend version (with HTML tags) is persisted to the
database.
This is an example list as saved in the database:
Item 1
Item 2
Item 3
In the frontend, this content is rendered like below. This is also how Frontend Editing "sees" the data and how it tries to persist it to the database.
<ul>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ul>
Solution¶
To ensure the data is persisted to the database in the expected format, we must transform it. This can be done using one of two TypoScript properties:
contentPersistPreProcessing, which allows you to configure a specific transformation for a specific field.
contentPersistPreProcessingPatterns, which allows you to configure a transformation for any field using a specific RTE preset.
contentPersistPreProcessingPatterns is especially handy if the field doesn't have any rich-rext editing in the backend. Frontend Editing comes with two presets for this particular use case:
[config][enableFrontendRichtext] for RTE only in Frontend Editing.
[config][frontendRichtextConfiguration] for specifying an RTE preset that will only be used in Frontend Editing.
Here's an example of how we use a Frontend Editing-only RTE preset:
$GLOBALS['TCA']['tt_content']['types']['bullets']['columnsOverrides']['bodytext'] = [
'config' => [
'enableFrontendRichtext' => true,
'frontendRichtextConfiguration' => 'listonly',
],
];
Frontend Editing ships with two RTE presets and contentPersistPreProcessingPatterns configurations for solving the two most common use cases.
bronly for handling text that should only accept line breaks, but no other formatting.
listonly for handling lists that are stored as plain text in the database.
Here's an example of a Fluid template rendering a list:
<t3kit:contentEditable tag="ul" table="tt_content" field="bodytext" uid="{data.uid}">
<f:for each="{bullets}" as="bullet">
<li>{bullet}</li>
</f:for>
</t3kit:contentEditable>