The constants of the sites become editable in Site Management >
Settings (admins only in TYPO3 13.4). settings.definitions.yaml of the
set ep/theme defines all 116 constants plus googleTagManagerId, with the
labels and categories of their constant editor annotations and today's
constants.typoscript values as defaults. Every setting is a string,
yes/no ones with a select of exactly '0' and '1': a bool setting would
hand '' instead of '0' to TypoScript.
config/sites/*/settings.yaml become shared files on the server and leave
git, like settings.php: production is leading, so backend edits survive
deploys, and each environment keeps its own values. Nine settings nobody
reads (twitterUrl, vimeoUrl, cookiefirstKey, ...) were dropped locally;
on production they stay in the seeded files until removed there.
deploy:check:site-settings aborts before anything else touches the
server if one of the shared files is missing or empty: deploy:shared
would create it empty, silently resetting that site to the defaults.
Rollout, after the site set is live: seed the shared files from the
live release once, then deploy:
cd <deploy_path> && for f in current/config/sites/*/settings.yaml; do
mkdir -p "shared/${f#current/}" && rmdir "shared/${f#current/}" &&
cp -p "$f" "shared/${f#current/}"; done
Verified locally: the resolved setup of 43 pages is unchanged and only
the nine unused constants are gone (switched state); the root template
state is unchanged; all 1912 frontend URLs are identical.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The set includes the same ep_theme TypoScript the root templates
included statically, and config/sites/*/settings.yaml hold the
constants of each site's root template, generated with TYPO3's own
TypoScript parser and kept under their old names, so no TypoScript
changes. They are plain values without definitions, so nothing is
type-converted.
Rolling out takes a second step: the root templates, with their clear
flags, still replace everything the set provides, so this deploy alone
changes nothing. .ddev/plans/sql/2026-10-27-site-sets.sql then hides
them and moves their setup (date picker presets, partner IDs, ...) into
extension templates editors keep maintaining. Extension templates
further down the tree keep applying on top.
Verified locally on a prod copy:
- the resolved constants and setup of 43 pages (every site root, every
page with an extension template below it, every page layout) are
identical before the deploy, between deploy and SQL, after the SQL
and after its rollback
- a crawl of all 1912 frontend URLs is identical before and after
Rollback: always run 2026-10-27-site-sets-rollback.sql BEFORE rolling
back this code, or the sites have no TypoScript at all in between.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The form page type (/form, 1704) existed because on the static pages of the
hybrid setup the page URL never reached TYPO3. With static rendering
retired, forms post to the page they are on, like the newsletter form:
the additionalParams in FormSetup.yaml, Page/Form.typoscript and the /form
entries of the PageType enhancers are gone.
Each form island gets the id form-island-<form identifier> (EXT:form
appends the content element uid), and Form.html targets and selects that
id instead of .form-island. With two forms on one page, a submission no
longer swaps in the first form's island.
Kept: hx-boost on the forms, HtmxRedirectMiddleware (Redirect finishers
under htmx) and /captcha (bw_captcha's image type).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The static export replaced every EXT:form form with a contact notice. The
forms are back, rendered by TYPO3 13 and embedded in the static pages:
- Page type 1704 (/<page>/form) renders only the form plugin of a page,
inside a .form-island element. Every form posts to that URL
(renderingOptions.additionalParams), because on www the page URL is a
static file that never reaches TYPO3. htmx swaps the island in place:
validation errors, multi-step pages and confirmations. A redirect to an
htmx request becomes HX-Redirect (HtmxRedirectMiddleware), so Redirect
finishers send the browser to the thank-you page.
- While a request runs, an overlay with a spinner (as in MyE&P) covers
the form. Styled inside the island: the static pages load the CSS of
the TYPO3 10 export.
- The bw_captcha image comes from /<page>/captcha for the same reason.
Both suffixes are in the PageType enhancer of every site with forms
(semesterende gets one with default '' to keep its URLs).
- Ported from TYPO3 10: form setup, templates and partials, the MyE&P
address finisher, the job application finisher with the MyE&P Team
API client (epTeamApi* in secrets.php), the page URL/referrer finisher
with ReferrerMiddleware (?ref=), the e-mail layout without the system
footer, bw_captcha 5 and form_element_linked_checkbox 6. The address
check forms are dropped.
- German language packs (EXT:form messages): availableLanguages = de,
fetched on every deploy (typo3:language:update).
- The checkbox partials passed null to VHS' substring, which PHP 8.5
reports as deprecated.
- DDEV no longer turns deprecations into exceptions, matching
production: EXT:form's RenderFormValueViewHelper uses null as an array
offset for empty optional fields (core bug, also in 13.4.37).
The static pages get their placeholders from the exporter in EP/website,
see .ddev/plans/static-export-form-islands.patch (local only).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Search page (searchresult plugin), AJAX results and filter panel, the
mobile filter overlay, search links ("Alle anzeigen", menu icon) and
the /reiseauswahl/{name} landing redirects are back. The search bar in
the page header stays out (SearchbarController not ported); on detail
pages the menu icon links to the search page instead of toggling it.
- Extbase requests are immutable: withArgument() instead of
setArgument()
- StaticSearchParamsMiddleware runs after site resolution and before
page resolution (the old position is a cycle in v13); FilterService
copes with the missing TypoScript there, as TYPO3 10 did
- Search and filter forms are sent URL-encoded instead of multipart, so
production can keep rejecting multipart requests
- ski-wochenenden: websiteTitle from the old sys_template sitetitle
Compared with TYPO3 10 on the same data (249 cases: search pages with
all 41 preset filters, landing redirects, AJAX results and filter
panel, GET and POST): 186 identical, 63 with the same results in a
different order (PHP 8 sorts stably, ties came out in arbitrary order
on PHP 7.4). Processed image names differ by their configuration hash.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- News records: EXT:news is not installed, so the default restrictions
lack its TCA; deleted, hidden, starttime and endtime are applied by
hand (TYPO3 13 listed 37 deleted or hidden news in the manifest)
- Site config ski-wochenenden is back: the content feed lists it
(contentFeedSites); DDEV host skiwe-ep13.ddev.site
Compared with the TYPO3 10 project on the same database (912 cases):
240 identical, 665 differ only because TYPO3 13 leaves out hidden
file references in image lists, 7 only in the order of MM relations
with equal sorting values.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
frommeandClaude Opus 5.5