QFQ

1) Es gibt eine Versionierungsmatrix: https://project.math.uzh.ch/projects/qfq/wiki/Migration#Compatibility

1.1 V10) Bei uns wird Typo3 nicht direkt im Projektordner abgelegt sonder nur via Symlink darauf gezeigt. Wenn ich mich recht erinnere konnte ohne den Apache Eintrag der index vom Typo3 nicht gefunden werden. Mittlerweile sind wir schon bei vielen auf Nginx umgestiegen.

1.2 V10) Das Problem mit der automatischen Weiterleitung kennen wir schon länger und bisher keine saubere Lösung gefunden die auch funktioniert hat. Bei einen Projekt hab ich QFQ dafür benutzt, bzw. mit dem User Store das Handling gesteuert. Hier gibt es noch weitere Ansätze: https://stackoverflow.com/questions/63109489/typo3-access-restricted-pages-redirect-after-login

1.3 V10) Auf das Problem mit dem DatabaseUpdate file war ich bisher noch nicht gestossen. Die Upgrades haben wir immer Schrittweise von V8 > V9 > V10 > V11 ausgeführt. Dabei die Ubuntu und PHP Version immer im Auge behalten (siehe Matrix oben). Bei V10 macht Ubuntu 22.04 Probleme. Mit V11 klappts dort dann auch.

1.4 V10) Die Page-Slug Migration ist noch nicht optimal. Ich glaube es werden auch Seiten aufgelistet bei der Migration welche nach Typo3 als Deleted markiert sind.

1.5 V10) Zu den unpraktischen pageSlugs: Um eine Setie via pageSlug zu finden gibt es einen Trick - Mann wählt die List Ansicht und geht auf den Root Page. Dort kann dann oben (innerhalb des Content Bereichs) mit der Search Funktion nach dem pageSlug gesucht werden. Am besten rechts beim Pfeil die Search Levels auf Infinite stellen.
Zum jetzigen Zeitpunkt kenne ich keine Funkton welcher alle pageSlugs in Typo3 automatisch anpasst. Page IDs funktionieren bei manchen Features tatsächlich noch. Wurde jedoch bei der Weiterentwicklung nicht mehr berücksichtigt, da sich früh auf die pageAlias festgefahren wurde und mit pageSlugs weitergeführt.
Zur "forwardUrl" muss ich selbst prüfen ob das geht.

1.6 V10) Ob "DB set default values" gebraucht wird oder nicht hängt davon ab in welchem Mode du deine DB betreibst: STRICT_ALL_TABLES oder STRICT_TRANS_TABLES sorgen dafür dass du eine Fehlermeldung beim Speichern eines Formulars bekommst wenn: die verknüpfte Tabelle eine Spalte besitzt ohne Default Value und nicht nullable ist und im betroffenen Formular diese Spalte nicht verwendet wird.

1.7 V10) Searchbar sollte im neuen UZH CD 24.01.31 schon gefixed sein.

1.1 V11) Falls du beim Klicken auf "Try to fix" eine rote Fehlermeldung bekommst dann liegt es normalerweise daran dass die Berechtigungen vom typo3temp Ordner nicht korrekt sind. Bzw. Typo3 selbst nicht die Berechtigungen hat. Bei mir ist var/build in 99% der Fälle leer.

1.2 V11) Zu diesem Problem hatten wir verschiedenes probiert und sind letzten Endes bei dieser Lösung verblieben:
Im Root template unter Constants (Beispiel aus Geo):

# Instance Dependent: absolute path to custom css and images
[request.getNormalizedParams().getHttpHost() == 'webwork22.math.uzh.ch']
  cd.stylesheet = https://webwork22.math.uzh.ch/lean/fileadmin/templates/geo.css
[end]
[request.getNormalizedParams().getSiteUrl() == 'https://lean.geo.uzh.ch/']
    cd.stylesheet = https://lean.geo.uzh.ch/fileadmin/templates/geo.css
[end]
[request.getNormalizedParams().getSiteUrl() == 'https://lean.geo.uzh.ch/preview/']
    cd.stylesheet = https://lean.geo.uzh.ch/preview/fileadmin/templates/geo.css
[end]

1.3 V11) Mit der aktuellsten QFQ (24.3.0 - Beta) und UZH CD (24.01.17) Version funktoniert das mit dem Login Template wenn folgendes im TypoScript verwendet wird:

plugin.tx_felogin_login {
  view {
        templateRootPaths {
              10 = fileadmin/templates/Felogin/
    }
  }
}

1.4 V11) Deine Notation für die Restrictions sind schon länger deprecated bei Typo3. Neu kannst du folgende benutzen:
Template Constants:

# List of IP addresses to grant access
site.allowIP.list = 127.0.0.1,::1,130.60.244.239

Template Setup:

# Layout neu aufbauen
page = PAGE
page.typeNum = 0

# Check for allowed IP or logged-in user or logged-in user with specific user group (id)
[ip('{$site.allowIP.list}') || 1 in frontend.user.userGroupIds || 30 in frontend.user.userGroupIds || frontend.user.isLoggedIn]
  page.10 < styles.content.get
[else]
  page.10 = TEXT
  page.10.value = Please log in or access this page from an authorized host. Your current IP address:&nbsp;
  page.20 = TEXT
  page.20.data = getenv : REMOTE_ADDR
[end]

Bin noch auf weitere deiner Punkte eingegangen in meinem ersten Kommentar. ;)

Die Tabelle aufzuteilen wäre keine schlechte Idee. Es sollte nur übersichtlich bleiben.

Vielen Dank für deine Rückmeldungen.

Zwei Anmerkungen/Rückmeldungen/Wünsche:

1.5 V10)

Page IDs funktionieren bei manchen Features tatsächlich noch. Wurde jedoch bei der Weiterentwicklung nicht mehr berücksichtigt, da sich früh auf die pageAlias festgefahren wurde und mit pageSlugs weitergeführt.

Verstehe ich das richtig, dass dies eine QFQ und keine Typo3-Einschränkung ist? Wir haben nie pageAlias verwendet und ich möchte auch weiterhin mindestens Intern überall die Page-ID verwenden. Das ist die einzige konstante Eigenschaft einer Page und damit die sicherste Lösung um den Code unabhängig zu machen von neu generierten Page-Slugs (z.B. nach dem Verschieben von Seiten.) Leider scheint QFQ das aktuell zu unterbinden. Was ist nötig, damit links mit PageID wieder korrekt funktionieren?

1.2 V11)
Danke für die Lösung - aber das ist schon ein ziemlich übler Hack... ;-) Ich hoffe Typo3 implementiert da irgendwann eine elegantere Lösung für Domain-unabhängige Absolute URLs.

1.5 V10) Ich kann noch nicht zu 100% sagen ob es nur eine QFQ Einschränkung ist aber wir werden uns darum demnächst kümmern. Bald haben wir unser Coding Week und dort werden wir im Bezug zur page ID Kompatibilität sehr wahrscheinlich daran arbeiten.