Get started 

For editors 

For integrators 

For developers 

Reference 

What does it do? 

This extension adds editing tools to the frontend, allowing backend users to edit, hide, delete, reorder and create content elements and pages without leaving the site.

TYPO3 editors normally switch to the backend to find and change the right content element. The extension closes that gap: a small JavaScript is injected into the frontend, asks the backend which elements the current user may edit, and renders the matching actions right where the content is displayed.

Features 

Support 

There are several ways to get support for this extension:

• GitHub issues: https://github.com/xima-media/xima-typo3-frontend-edit/issues
• FAQ — answers to the most common problems

Security policy 

Please read our security policy if you discover a security vulnerability in this extension.

License 

This extension is licensed under GNU General Public License 2.0 (or later).

Requirements 

• PHP 8.2 - 8.5
• TYPO3 13.4 LTS - 14.x

Step 1: Install the extension 

composer require xima/xima-typo3-frontend-edit

Step 2: Include the site set 

The extension ships a site set that registers its settings and TypoScript. Without it, nothing is injected into the frontend.

dependencies:
  - xima/xima-typo3-frontend-edit

Step 3: Verify the setup 

1. Log into the TYPO3 backend.
2. Open a page of your site in the frontend in the same browser.
3. The toolbar appears in the bottom-right corner, and hovering a content element reveals its edit button.

Next steps 

1. Log in, then open your site 

Frontend editing only appears for logged-in backend users. Log into the TYPO3 backend, then open a page of your website in the same browser.

Two things appear:

2. Change a content element 

Hover the element you want to change and click its pencil button. The TYPO3 edit form opens — either in the backend, or, if your site has inline editing enabled, in a panel right next to the page.

Save with Save & Close and you land back on the same spot in the frontend, with a confirmation message.

3. Change the page itself 

The toolbar covers everything that concerns the page rather than a single element — page properties, opening the page module, page info.

4. Switch it off when it gets in the way 

The eye icon in the toolbar turns frontend editing off. Your choice is stored for your user and survives a reload, so you can check the page exactly as a visitor sees it and switch back when you are done.

Delete Confirmation 

Clicking Delete opens a confirmation dialog before the record is removed. The dialog shows the record title and identifier (e.g. My Element [tt_content:42]) so editors can verify they are deleting the correct element.

• Escape, the close button, or clicking the backdrop cancels the action
• Focus returns to the previously focused element after closing
• On success, a notification is shown and the page reloads automatically

Requirements 

The Edit Menu needs each content element to be identifiable in the rendered HTML. With fluid_styled_content this works out of the box; custom templates need one small addition.

Actions 

The Toolbar includes:

• Toggle - (eye icon) Enable or disable frontend editing for the current session
• Edit page properties - Open the current page properties
• Edit page - Open the page module in the backend
• Info - Display page information
• Move - Reorder page

Position 

You can configure the Toolbar position via Site Settings:

frontendEdit:
  toolbarPosition: 'bottom-right'

Available positions:

• top-left, top-center, top-right
• bottom-left, bottom-center, bottom-right
• left-top, left-center, left-bottom
• right-top, right-center, right-bottom

Disabling Frontend Edit 

You can temporarily disable frontend editing by clicking the toggle button in the Toolbar. This setting is stored per user and persists across sessions.

To disable the Toolbar entirely, set showStickyToolbar: false in the Site Settings.

Setup 

Inline editing is off by default. Enable it in your site settings:

frontendEdit:
  enableContextualEditing: true

Or via the TYPO3 backend: Site Management > Sites > Edit site > Settings > Frontend Edit > Appearance.

How the form is presented 

The extension picks the presentation automatically, based on whether the TYPO3 core route record_edit_contextual is available. There is nothing to configure beyond the setting above.

• TYPO3 v14.2 and newer
• TYPO3 v13 and v14.0 / v14.1

Edit links open a sidebar panel that slides in from the right, driven by the native record_edit_contextual route.

Creating new content still uses the slide-in modal, because the New Content Element Wizard is hosted in the page module.

Edit links open a slide-in modal that loads the standard backend edit form in an iframe. The route record_edit_contextual does not exist on these versions, so the modal takes over both editing and the New Content Element Wizard.

From an editor's perspective the workflow is the same: open, edit, save, close.

Usage 

With inline editing enabled:

• Clicking an edit button opens the panel instead of navigating to the backend.
• The page properties link in the toolbar opens in the panel as well.
• Ctrl+Click (or Cmd+Click on macOS) bypasses the panel and opens the full backend editor directly.

Limitations 

The FormEngine runs outside its intended context, so some advanced features are limited:

Fallback behavior 

Setting disabled

All edit links navigate to the backend, exactly as without this feature.

JavaScript disabled

Edit links fall back to their href attribute, which points to the standard backend URL.

Setup 

Enable the feature in your site settings:

frontendEdit:
  enableDragAndDrop: true

Or via the TYPO3 backend: Site Management > Sites > Edit site > Settings > Frontend Edit > Appearance.

{namespace xfe=Xima\XimaTypo3FrontendEdit\ViewHelpers}

<div class="main-column">
    <xfe:columnTarget colPos="0" />
    <f:cObject typoscriptObjectPath="lib.dynamicContent" data="{colPos: 0}" />
</div>

Usage 

With drag & drop enabled, each content element toolbar gains a drag handle next to the edit and context menu buttons. Pick the element up by its handle and drop it at the desired position — an indicator shows where it will land.

After a successful move the page reloads and a notification confirms whether the element was reordered within its column or moved to another column.

Permissions 

A move is only carried out when the backend user is allowed to edit the record. The same permission check the backend applies is enforced server-side, so restricted editors cannot reorder content they may not edit.

The target page is always derived from the moved record itself. A manipulated request therefore cannot move an element to a different page — cross-page moves remain a backend operation.

Container columns 

Columns of an EXT:container element are drop targets as well, as long as the template marks them with the container's uid:

{namespace xfe=Xima\XimaTypo3FrontendEdit\ViewHelpers}

<xfe:columnTarget colPos="201" containerUid="{data.uid}" />

Content can be reordered inside a container column, moved between the columns of a container, moved out into a page column and moved from a page column into a container.

A container element itself can be reordered within page columns, but cannot be dropped into another container — nesting stays a backend operation.

Limitations 

The following cases are out of scope and keep the classic move button in the edit menu as a fallback:

Translated elements

Only default-language elements can be reordered. Translations follow the ordering of their parent record, so reordering a translation would have no meaningful effect.

Nesting containers

A container element cannot be dropped into another container. Use the move button in the edit menu for that.

Keyboard operation

Dragging relies on the browser's native drag & drop, which is pointer-only. The drag handle is therefore deliberately kept out of the tab order and hidden from assistive technology, so it does not present a focusable control that cannot be used. Use the move button in the edit menu instead, which opens the backend move dialog and is fully keyboard-accessible.

Fallback Behavior 

• Setting disabled: No drag handles are rendered and nothing changes for editors.
• Columns not marked: No drag handles are rendered, because drop targets cannot be resolved.
• JavaScript disabled: The frontend edit tooling does not load at all; reordering happens in the backend as usual.

Content element toolbar 

The buttons attached to a content element form a single tab stop. Once focused, you move between the buttons with the arrow keys — the same pattern the TYPO3 backend uses.

Edit Menu 

The three-dot button opens the menu. Inside it:

Dialogs and the inline editing panel 

The delete confirmation dialog and the inline editing panel behave as modal dialogs:

• Esc closes them.
• Tab cycles within the dialog and does not escape to the page behind it.
• Closing returns focus to the element that opened the dialog.

The delete dialog names the record it is about to remove — including its identifier, e.g. My Element [tt_content:42] — so the target is unambiguous when the dialog is announced.

Known limitations 

Drag & drop reordering

Native browser drag & drop is pointer-only. The drag handle is therefore kept out of the tab order and hidden from assistive technology on purpose, so it does not offer a focusable control that cannot be operated. Use the move entry in the Edit Menu instead — it opens the backend move dialog, which is fully keyboard-accessible. See Drag & Drop Reordering.

FormEngine inside the panel

Inside the inline editing panel the TYPO3 edit form runs outside its usual context. Context menus are not available; the Expand button opens the record in the regular backend when you need the full form.

Respecting user preferences 

Available Settings 

Example Configuration 

Full example with all available options:

frontendEdit:
  enabled: true
  colorScheme: 'auto'
  showContextMenu: true
  showInsertButtons: true
  showStickyToolbar: true
  toolbarPosition: 'bottom-right'
  enableOutline: true
  enableScrollToElement: true
  enableFlashMessages: true
  enableContextualEditing: false
  enableDragAndDrop: false
  filter:
    ignorePids: '1,2,3'
    ignoreDoktypes: '4,199,254'
    ignoreCTypes: 'html,div'
    ignoreListTypes: ''
    ignoreUids: ''

Disable frontend editing 

By default, frontend editing is enabled for all backend users.

Examples 

tx_ximatypo3frontendedit.disabled = 1

tx_ximatypo3frontendedit.disabled = 1

Features 

Debug 

Multi-domain setups 

Frontend editing needs an active TYPO3 backend session in the browser that is viewing the frontend. Whether that session is available depends on domain/cookie configuration:

Session cookie reach (``cookieDomain``)

The backend session cookie is only sent to the domain(s) it was issued for. If the frontend and backend live on different (sub)domains, set cookieDomain so the cookie is shared across them.

SameSite

A restrictive cookieSameSite setting can also prevent the backend session cookie from being sent on the frontend request, with the same symptom as a cookie domain mismatch: the Edit Menu never appears, with no error visible in the frontend.

Cross-domain backend login

If sharing a cookie domain is not an option (fully separate domains, not subdomains of one another), use the multisite_belogin extension, which provides backend login support across multiple domains without a shared cookie domain.

``returnUrl`` behavior

The returnUrl passed to backend edit routes is validated against the current request's host and the site's configured base hosts (including language bases); a foreign host is rejected rather than followed. In a cross-domain setup (frontend and backend on different domains), this can mean a returnUrl that legitimately points at the frontend domain gets treated as foreign to the backend request. If a strict referer header is also masking the real frontend host - see the FAQ entry on this - enable forceReturnUrlGeneration to generate the return URL from pid/language instead of trusting the request's own host.

External caches (Varnish, CDN) 

After a hide or delete action, the extension clears TYPO3's own page cache for the affected page - that part happens automatically. It has no way to purge an external cache layer (Varnish, a CDN) sitting in front of TYPO3, since that requires cache-tag/ban integration specific to that layer. If such a cache is in front of your site, the redirect after hide/delete may briefly show a stale version of the page until that external cache's own TTL or invalidation logic catches up.

Anchor pattern requirement (and the headless/SPA non-goal) 

Matching a content element in the frontend HTML to its backend record requires either the id="c{uid}" anchor pattern or the data-frontend-edit="{table}:{uid}" attribute to be present in the rendered markup - see How it works for both patterns and how to add them to a custom template.

Headless/SPA frontends are an explicit non-goal: the script that performs this matching is injected server-side into TYPO3's own rendered HTML (via a PSR-15 middleware). It never runs for a frontend that TYPO3 itself does not render HTML for - there is no client-side integration path for a JSON-API/decoupled frontend.

Preview links (ADMCMD_prev) 

A backend preview link (ADMCMD_prev=...) lets someone view a page - e.g. an unpublished draft - without a full backend login. No frontend editing UI is shown for such a viewer: there is no active backend user session behind an ADMCMD_prev link, and the extension's access checks require one. This is expected behavior, not a bug - a preview link is meant for reviewing content, not editing it.

The content element ID 

Each content element needs a "c-id" — its UID prefixed with c — on the element that wraps it:

<div id="c10" class="frame frame-default frame-type-textpic">
    ...
</div>

This is how the injected JavaScript maps a DOM node to a database record. No c-id means no edit button for that element.

<div id="c{data.uid}">
    ...
</div>

<div id="c{data.uid}">
   <f:for each="{children_200}" as="record">
       <f:format.raw>{record.renderedContent}</f:format.raw>
   </f:for>
</div>

<div class="dce" id="c{contentObject.uid}">
    Your template goes here...
</div>

Alternative: the data-frontend-edit attribute 

For templates that cannot carry the c-id anchor - dynamic content element extensions (DCE), other custom Fluid templates - a second matching channel exists: a data-frontend-edit="tt_content:{uid}" attribute on the content element's own wrapping HTML element.

<div data-frontend-edit="tt_content:10" class="my-custom-wrapper">
    ...
</div>

The bundled <xfe:editable> ViewHelper renders this attribute for you:

{namespace xfe=Xima\XimaTypo3FrontendEdit\ViewHelpers}

<div class="my-custom-wrapper"<xfe:editable record="{data}" />>
    ...
</div>

Both patterns can be mixed freely on the same page; an element only needs one of them. Unlike the c-id anchor pattern, a data-frontend-edit element is always treated as the content element itself - no sibling resolution is attempted.

Editing foreign records (news, addresses, ...) 

The data-frontend-edit attribute also works for records from any other table - not just tt_content - by adding a table prefix: data-frontend-edit="{table}:{uid}". This covers the classic case of editing foreign records displayed on a detail page, e.g. a news detail page rendered by EXT:news:

{namespace xfe=Xima\XimaTypo3FrontendEdit\ViewHelpers}

<div class="news-detail"<xfe:editable record="{newsItem}" table="tx_news_domain_model_news" />>
    <h1>{newsItem.title}</h1>
    ...
</div>

This is deliberately thin: the menu offers exactly edit, info and history - no hide, delete or move, since those are meaningful only for tables this extension understands specifically (tt_content, pages). Permissions are checked the same way as everywhere else in the extension (the backend user's actual edit rights on that record); a table the current user cannot edit - or that TYPO3 does not know at all - never gets a menu. Translated records resolve to the current frontend language automatically, the same way tt_content does.

Extend the menu the same way as for content elements, via the FrontendEditDropdownModifyEvent - the record row carries a _table key so a listener can tell it apart from a tt_content row.

Optional markers 

Two features need additional markers in your templates. Both are opt-in — omit them and the corresponding feature simply does not appear.

What cannot be edited 

Only content elements belonging to the current page receive a menu. Inherited content — a shared footer pulled in from another page, for example — cannot be edited from the inheriting page. Use the toolbar to jump to the page that owns the record.

ColumnTargetViewHelper 

The ColumnTargetViewHelper renders a hidden <div> element as a DOM marker. No content, no styling, no logic — just a marker that the JavaScript picks up after the page loads.

Register the namespace in your Fluid template:

{namespace xfe=Xima\XimaTypo3FrontendEdit\ViewHelpers}

Or use the XML namespace syntax:

<html xmlns:xfe="http://typo3.org/ns/Xima/XimaTypo3FrontendEdit/ViewHelpers"
      data-namespace-typo3-fluid="true">

{namespace xfe=Xima\XimaTypo3FrontendEdit\ViewHelpers}

<f:cObject typoscriptObjectPath="lib.dynamicContent" data="{pageUid: '{data.uid}', colPos: '0'}" />
<xfe:columnTarget colPos="0" />

<f:cObject typoscriptObjectPath="lib.dynamicContent" data="{pageUid: '{data.uid}', colPos: '1'}" />
<xfe:columnTarget colPos="1" />

{namespace xfe=Xima\XimaTypo3FrontendEdit\ViewHelpers}

<div class="column-left">
    <f:for each="{children_201}" as="record">
        <f:format.raw>{record.renderedContent}</f:format.raw>
    </f:for>
    <xfe:columnTarget colPos="201" containerUid="{data.uid}" />
</div>

<div class="column-right">
    <f:for each="{children_202}" as="record">
        <f:format.raw>{record.renderedContent}</f:format.raw>
    </f:for>
    <xfe:columnTarget colPos="202" containerUid="{data.uid}" />
</div>

How it works 

1. The ViewHelper renders <div data-xfe-colpos="0" hidden></div> (invisible, no layout impact)
2. The extension's JavaScript scans the page for these markers after loading
3. A "+" button is injected at each marker position, regardless of whether the column already contains content
4. Clicking the button opens the page module inside the iframe modal and auto-clicks the matching wizard button, so TYPO3's native New Content Element Wizard appears with the correct colPos pre-filled
5. The wizard lets the editor choose a content type before the record editor opens — inside the iframe modal on both v13 and v14

Container support requires the b13/container extension. The service automatically detects whether it is installed. Without it, only page columns are supported and container markers are silently ignored.

Request flow 

1. A PSR-15 middleware injects the CSS and JavaScript before </body> — but only if a backend user is logged in. For regular visitors the response is untouched.
2. On page load the script collects the content element IDs from the DOM and calls the AJAX endpoint /typo3/ajax/xima-frontend-edit/edit-information.
3. The server filters that list — backend user permissions, the site settings filters (pages, doktypes, CTypes, UIDs) and translation resolution (see Languages) — and returns only the elements the current user may actually edit, together with the menu for each of them.
4. The script assigns each menu to its DOM element and renders the edit button, the context menu and, where enabled, insert buttons and drag handles. The menu entries link to the corresponding edit views in the TYPO3 backend.

Permissions are decided server-side 

Permissions are never evaluated in the browser. Every action link is generated server-side from the backend user's actual permissions, and write operations such as drag & drop re-check those permissions before touching a record.

What the client needs 

The only hard requirement is that content elements are identifiable in the rendered HTML — fluid_styled_content already covers this:

<div id="c10" class="frame frame-default frame-type-textpic frame-layout-0">
    ...
</div>

FrontendEditDropdownModifyEvent 

Use the FrontendEditDropdownModifyEvent to modify the Edit Menu for content elements. You can add, remove or modify buttons for specific content elements.

Available methods:

• getContentElement() - Returns the content element data array
• getMenuButton() - Returns the current menu button
• setMenuButton() - Sets the modified menu button
• getReturnUrl() - Returns the return URL for edit links

Example:

<?php

declare(strict_types=1);

namespace Vendor\Package\EventListener;

use TYPO3\CMS\Backend\Routing\UriBuilder;
use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Core\Imaging\IconFactory;
use Xima\XimaTypo3FrontendEdit\Enumerations\ButtonType;
use Xima\XimaTypo3FrontendEdit\Event\FrontendEditDropdownModifyEvent;
use Xima\XimaTypo3FrontendEdit\Template\Component\Button;

#[AsEventListener(
    identifier: 'my-extension/modify-edit-menu',
)]
class ModifyEditMenuListener
{
    public function __construct(
        protected readonly IconFactory $iconFactory,
        protected readonly UriBuilder $uriBuilder
    ) {}

    public function __invoke(FrontendEditDropdownModifyEvent $event): void
    {
        $contentElement = $event->getContentElement();
        $menuButton = $event->getMenuButton();

        // Add a custom button for a specific plugin
        if ($contentElement['CType'] === 'list' && $contentElement['list_type'] === 'news_pi1') {
            $menuButton->appendAfterChild(new Button(
                'Edit news settings',
                ButtonType::Link,
                $this->uriBuilder->buildUriFromRoute(
                    'record_edit',
                    [
                        'edit' => ['tt_content' => [$contentElement['uid'] => 'edit']],
                        'returnUrl' => $event->getReturnUrl(),
                    ],
                )->__toString(),
                $this->iconFactory->getIcon('content-news', 'small')
            ),
            'edit_page',
            'edit_news_settings'
            );
        }

        // Remove a button
        $menuButton->removeChild('div_action');

        $event->setMenuButton($menuButton);
    }
}

FrontendEditPageDropdownModifyEvent 

Use the FrontendEditPageDropdownModifyEvent to modify the Toolbar menu for page-level actions.

Available methods:

• getPageId() - Returns the current page ID
• getLanguageUid() - Returns the current language UID
• getMenuButton() - Returns the current menu button
• setMenuButton() - Sets the modified menu button
• getReturnUrl() - Returns the return URL for edit links

Example:

<?php

declare(strict_types=1);

namespace Vendor\Package\EventListener;

use TYPO3\CMS\Backend\Routing\UriBuilder;
use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Core\Imaging\IconFactory;
use Xima\XimaTypo3FrontendEdit\Enumerations\ButtonType;
use Xima\XimaTypo3FrontendEdit\Event\FrontendEditPageDropdownModifyEvent;
use Xima\XimaTypo3FrontendEdit\Template\Component\Button;

#[AsEventListener(
    identifier: 'my-extension/modify-toolbar',
)]
class ModifyToolbarListener
{
    public function __construct(
        protected readonly IconFactory $iconFactory,
        protected readonly UriBuilder $uriBuilder
    ) {}

    public function __invoke(FrontendEditPageDropdownModifyEvent $event): void
    {
        $menuButton = $event->getMenuButton();

        // Add a custom page action
        $menuButton->appendChild(new Button(
            'Clear page cache',
            ButtonType::Link,
            $this->uriBuilder->buildUriFromRoute(
                'tce_db',
                [
                    'cacheCmd' => $event->getPageId(),
                    'redirect' => $event->getReturnUrl(),
                ],
            )->__toString(),
            $this->iconFactory->getIcon('actions-system-cache-clear', 'small')
        ),
        'clear_cache'
        );

        $event->setMenuButton($menuButton);
    }
}

FrontendEditDataEnrichmentEvent 

Use the FrontendEditDataEnrichmentEvent to attach structured, serializable data to content elements - e.g. a status color, an assignee, a comment count - which the frontend JavaScript can then render, for example via a registerBadge() call. Since element data is delivered via the uncached editInformation AJAX request, this is also the only cache-safe transport for volatile third-party data, and it rides along on the existing request without an extra roundtrip.

The event is dispatched once per request, with the full filtered content element list - not once per element - so a listener backed by a database can resolve its data in a single query instead of being invoked N times with no way to batch.

Available methods:

• getContentElements() - Returns all content element rows for this request, keyed by uid (read-only)
• getContentElementUids() - Returns just the uids, for a batched lookup
• getPageId() / getLanguageUid() / getReturnUrl() - Request context
• addElementData(int $uid, string $namespace, array $data) - Attaches data for one element under your namespace; $data must be serializable (scalar, null, or arrays thereof)
• getElementData(int $uid) - Returns the data attached so far for one element (namespace => data)

Data attached via addElementData() is merged into the JSON payload under element['_ext'][$namespace] - namespacing prevents key collisions between listeners, and _ext is reserved for this purpose (core frontend-edit keys are never exposed under it). Namespaces must be lowercase letters, digits and underscores, starting with a letter (e.g. your extension key).

Example:

<?php

declare(strict_types=1);

namespace Vendor\Package\EventListener;

use TYPO3\CMS\Core\Attribute\AsEventListener;
use Xima\XimaTypo3FrontendEdit\Event\FrontendEditDataEnrichmentEvent;

#[AsEventListener(
    identifier: 'my-extension/enrich-comment-data',
)]
class EnrichCommentDataListener
{
    public function __construct(
        protected readonly CommentRepository $commentRepository,
    ) {}

    public function __invoke(FrontendEditDataEnrichmentEvent $event): void
    {
        // One query for all elements on this page instead of N.
        $counts = $this->commentRepository->countByContentElementUids(
            $event->getContentElementUids(),
        );

        foreach ($counts as $uid => $count) {
            $event->addElementData($uid, 'my_extension', [
                'color' => $count > 0 ? '#ff9800' : '#9e9e9e',
                'count' => $count,
            ]);
        }
    }
}

On the frontend, render it via registerBadge() when the element is rendered:

document.addEventListener('xfe:element-rendered', (event) => {
    const { uid, payload } = event.detail;
    const data = payload.element._ext?.my_extension;
    if (!data) return;

    window.XimaFrontendEdit.registerBadge(uid, {
        html: `<span style="background:${data.color}">${data.count}</span>`,
    });
});

How translations are resolved 

The injected script collects the content element ids (c<uid>) from the DOM and sends them to the backend. In connected mode (language overlay) TYPO3 keeps the default-language uid on the overlaid row, so the DOM anchor carries the default-language (L0) uid rather than the translation uid.

Frontend Edit therefore resolves translations on the server side via the l18n_parent pointer: for every requested L0 uid it also looks up the matching translation and, when both exist, the translation wins. This guarantees that the edit link targets the translation uid — TYPO3 FormEngine cannot switch the edited record via a language parameter alone.

Mode support matrix 

Facade methods 

const info = window.XimaFrontendEdit.getElementInfo(42);
// { uid: 42, element: HTMLElement, payload: { element: {...}, menu: {...} } }

window.XimaFrontendEdit.notify({
    title: 'Comment added',
    message: 'A new comment was posted on this element.',
    severity: 'info',
});

window.XimaFrontendEdit.registerToolbarItem(42, {
    html: '<svg>...</svg>',
    label: 'Show comments',
    onClick: () => openCommentsPanel(42),
});

window.XimaFrontendEdit.registerBadge(42, {
    html: '<span class="my-badge" title="3 comments">3</span>',
    position: 'top-left',
    id: 'comment-count',
    onClick: () => openCommentsPanel(42),
});

window.XimaFrontendEdit.setBadgeMode('prominent');

/* Small dot only, by default */
.my-badge-label { display: none; }
/* Full label once prominent mode is active */
[data-xfe-badge-mode="prominent"] .my-badge-label { display: inline; }

window.XimaFrontendEdit.openBackendView(commentsBackendUrl, {
    title: 'Comments',
    width: '480px',
    linkPolicy: { match: '/typo3/module/web/layout', action: 'close' },
    onClose: ({ reason }) => console.log('comments panel closed:', reason),
});

Lifecycle events 

All events are dispatched on document.

document.addEventListener('xfe:element-rendered', (event) => {
    const { uid, payload } = event.detail;
    if (payload.element.CType === 'list' && payload.element.list_type === 'news_pi1') {
        window.XimaFrontendEdit.registerBadge(uid, { html: '<span>News</span>' });
    }
});

Minimal integration example 

document.addEventListener('xfe:ready', (event) => {
    console.log('Frontend Edit ready with', Object.keys(event.detail.elements).length, 'element(s)');
});

document.addEventListener('xfe:element-rendered', (event) => {
    const { uid } = event.detail;
    window.XimaFrontendEdit.registerToolbarItem(uid, {
        label: 'Open comments',
        onClick: () => window.XimaFrontendEdit.openBackendView('/comments/' + uid),
    });
});

Nothing appears in the frontend 

{namespace xfe=Xima\XimaTypo3FrontendEdit\ViewHelpers}

<div class="dce"<xfe:editable uid="{contentObject.uid}" />>
    Your template goes here...
</div>

Problems with the edit form 

Version 2.0 

Migration from version 1.x to version 2.x.

frontendEdit:
  showContextMenu: false

use TYPO3\CMS\Core\Attribute\AsEventListener;
use Xima\XimaTypo3FrontendEdit\Event\FrontendEditDropdownModifyEvent;

#[AsEventListener]
final class ModifyMenu
{
    public function __invoke(FrontendEditDropdownModifyEvent $event): void
    {
        $event->getMenuButton()->removeChild('history');
    }
}

Need Help? 

• Check the FAQ for common issues
• Open an issue on GitHub

At a glance 

visual_editor (FriendsOfTYPO3) 

visual_editor provides inline WYSIWYG editing using Web Components and CKEditor 5. Editors can modify text fields in place, reorder content elements via drag-and-drop, and save changes without leaving the page. It runs exclusively within a dedicated backend module that embeds the frontend page in an iframe — it does not inject editing capabilities into the regular frontend. It also requires ViewHelper integration in Fluid templates. In contrast, this extension works directly in the frontend, requires no template changes, and links to standard backend forms for editing.

feedit 

feedit was the original TYPO3 core extension for frontend editing. It injected edit icons directly into the rendered HTML on the server side. The core integration it relied on has since been removed. This extension uses a different approach with PSR-15 middleware and client-side AJAX menus.

frontend_editing 

frontend_editing is an older extension that provided frontend editing capabilities for TYPO3. This extension is not a further development of frontend_editing. While the general goal is similar, the technical approach is entirely different — this extension uses lightweight JavaScript injection and links to backend forms.

content_preview 

content_preview provides a split-view with a live frontend preview within the TYPO3 backend Page module. It enhances the backend interface, while this extension enhances the frontend. Both approaches can be used together.