FAQ 

Answers to the problems reported most often. If none of these help, please open an issue on GitHub.

Nothing appears in the frontend 

Work through this checklist — the cause is almost always one of these six points.

Backend user session
Are you logged into the TYPO3 backend? Without an active backend session nothing is injected into the frontend.
Backend user permissions
Does your user have permission to edit both the page and the content elements on it?
Site set
Is the Frontend Edit site set included in your site configuration? See Installation.
Frontend editing switched off
Check whether frontendEdit.enabled is true, whether the page is excluded via frontendEdit.filter.ignorePids, and whether the toggle in the toolbar is switched off for your user. It can also be disabled administratively via UserTSconfig.
Content element IDs
The rendered HTML must expose a "c-id" per element, e.g. id="c908" - or use the data-frontend-edit attribute instead. Without template changes, the experimental render markers are an alternative. See How it works and Setup requirements & limits (headless/SPA frontends are an explicit non-goal, for the same reason).
Content element on the current page
Only elements belonging to the current page are editable. Inherited content (e.g. a shared footer) cannot be edited from the inheriting page.

Frontend editing needs an active backend user session. On a different (sub)domain the session cookie is only valid for the backend domain and is therefore not available to the frontend.

Two ways out:

  • Configure a broader cookieDomain so the session cookie is shared between the domains.
  • Use the multisite_belogin extension, which provides backend login across multiple domains without a shared cookie domain.

A cross-domain setup can also cause a returnUrl to be rejected with an HTTP 400 error instead of silently redirecting to the root page: the extension only accepts a returnUrl whose host matches the current request or one of the site's configured base URLs (including per-language bases). A rejected return url is a sign to check your site configuration's base URLs rather than a bug — see Setup requirements & limits for the full picture.

Neither container nor DCE render the required content element ID in their default templates — you have to add it.

Template requirements has a ready-to-copy snippet for both, including a fluid_styled_content-based alternative for containers.

Alternatively, add the data-frontend-edit attribute instead (see How it works) - it avoids the "c-id" naming collision risk entirely and needs no sibling resolution:

DCE Template 
{namespace xfe=Xima\XimaTypo3FrontendEdit\ViewHelpers}

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

Only content elements belonging to the current page are editable. Content pulled in from another page cannot be edited from the inheriting page — the record simply does not live there.

Use the toolbar to navigate to the page that owns the record and edit it there.

Problems with the edit form 

This is usually caused by a strict referer header. If the return URL cannot be determined from the request, force it to be generated from page ID and language via the Return URL generation extension setting.

See Setup requirements & limits for the full picture of multi-domain setups, including SameSite and returnUrl behavior.

This is a TYPO3 backend limitation: the reduced edit form frame does not include the language switch.

Use the Redirect extension setting to open the edit form in the full TYPO3 backend, which does provide the language switch.