Für die Integration der #93048 – Backend URL rewrites muss die htaccess angepasst werden. Eigentlich sollte es automatisch passieren, doch wenn die .htaccess zu sehr angepasst wurde funktioniert der Automatismus nicht mehr.
Als Entwickler hat man immer wieder mal die Aufgabe Links zu generieren, wenn man im Backend oder mit der CLI/Scheduler unterwegs ist um. Wenn die Links ins Frontend führen sollten, musste man immer erst das TSFE erzeugen um dann über typolink alles zu erzeugen.
Früher…., *ich werf mal einen Stein*…. (ja soviel früher), konnte man dafür die TYPO3 Erweiterung PagePath nutzen, ursprünglich von Dmitry Dulepov geschrieben und dann von Sebastian Michaelsen übernommen und für eine weitere TYPO3 Version geupdatet. …. Wenn man die Erweiterung selbst geupdatet hat, dann kann man sie auch noch in TYPO3 9 nutzen.
Doch man will ja nicht ständig patchen sondern irgendwann einfach mit dem Core Links erzeugen, von daher GoodBye PagePath and Hello PageRouter
Nach einer kurzen Suche zu dem Thema landet man natürlich auf …. genau Stackoverflow (wahrscheinlich die zweit häufigste Seite, nach Google, eines jeden Developers) und hier dann genau auf bei einer Erklärung von Mathias Brodala
Ich denke mal jeder der im TYPO3 im Slack Channel oder auf Stackoverflow was TYPO3 spezifisches gefragt hat, bekam von Ihm schon mal eine schnelle, freundliche fundierte Antwort 🙂 Man kann daher davon ausgehen, wenn er das empfiehlt dann passt das.
Hier noch mal kurz in Code :
Für die Linkerzeugung, tauschen wir hier nun den alten PagePath Code aus:
Kleine Anpassung noch von mir, sofern es keine Multidomain TYPO3 Installation ist kann man das „suchen“ nach der richtigen $site etwas vereinfachen wenn man statt wie oben die SiteConfiguration per $singleViewPageUid sucht, direkt den Namen der Configuration nutzt, also
getSiteByPageId() ist aber einfacher (und damit auch sicherer) in der Handhabung, je nach Umgebung, Konfigurationen der Systeme und im Einsatz in verschiedenen Erweiterungen.
Das ist eine 1 zu 1 Kopie, von diesem Snippet https://gitlab.apfelkiste.eu/snippets/1 da ich mir den Link nicht merken kann, das ganze hier noch mal gespeichert 🙂
Mit Hilfe einer .env-File können empfindliche Einstellungen wie Passwörter bzw. Einstellungen, die sich je System ändern zentral und außerhalb des Repositories abgelegt werden.
You can simply copy file: foundation-sites/scss/util/_unit.scss (its can work independently) & paste it to your app folder: assets/scss/ & import the same & then start using rem-calc
$ git branch -m master main
$ git push -u origin main
So what are we doing here? First with the -m command we are moving the git history from master to a new branch called main. Next we’re pushing the main branch up to the origin remote, and establishing an upstream connection with the -u command.
Durch die Symfony Expression Language hat sich ja einiges geändert, daher hier eine lose Sammlung wie die alten TypoScript Bedinungen ersetzt werden können
Zuerst hier schon mal 2 Blogs die das schon großartig umschreiben
und schon mal eine ganz wichtige aus GP: und einem nested Array wird folgendes
[globalVar = GP:tx_ttnews|tt_news > 0]
//POST && GET
[request.getParsedBody()['tx_news_pi1']['news'] > 0 || request.getQueryParams()['tx_news_pi1']['news'] > 0]
//only GET
[request.getQueryParams()['tx_news_pi1']['news'] > 0]
//mittlerweile ist diese Variante zu bevorzugen, da so keine exceptions in //der Log File geworfen werden wenn kein 'tx_news_pi1' in der aktuellen Anfrage vorhanden ist
[traverse(request.getQueryParams(), 'tx_news_pi1/news') > 0] # This condition matches if current query parameters have tx_news_pi[news] set to a value greater than zero [END]
[globalVar = TSFE:id=1]
[page["uid"] == 1]
bzw.
[getTSFE().id == 1]
in früheren Version von TYPO3 konnte man einfach folgenden Code nutzen damit ein entsprechender 404 geworfen wird.
$GLOBALS['TSFE']->pageNotFoundAndExit('text');
Mit TYP3 9 wird folgendes empfohlen:
return GeneralUtility::makeInstance(ErrorController::class)->pageNotFoundAction(
$this->request,
'The requested page does not exist',
['code' => PageAccessFailureReasons::PAGE_NOT_FOUND]
);
Ich nutze es nun immer in Zusammenhang mit einer DetailAnsicht welche meist auf einer eigenen Unterseite der Listen Ansicht, in folgender Art und Weise:
public function detailAction(MyObject $event = null)
{
if ($event === null) {
$this->handleContentNotFound();
}
...
}
/**
* @throws \TYPO3\CMS\Extbase\Mvc\Exception\StopActionException
* @throws \TYPO3\CMS\Extbase\Mvc\Exception\UnsupportedRequestTypeException
*/
public function handleContentNotFound()
{
$isThereAnEventId = $this->request->hasArgument('event');
if ($isThereAnEventId === true) {
return GeneralUtility::makeInstance(ErrorController::class)->pageNotFoundAction(
$this->request,
'The requested page does not exist',
['code' => PageAccessFailureReasons::PAGE_NOT_FOUND]
);
}
$parentPageUrl = $this->uriBuilder
->setTargetPageUid($this->getTypoScriptFrontendController()->page['pid'])
->setCreateAbsoluteUri(true)
->build();
$this->redirectToUri($parentPageUrl, 0, 301);
}
In der detailAction wird zuerst geprüft ob das injecten des Objectes NICHT erfolgreich war, also weiterhin null ist. Wenn dem der Fall ist geht es weiter zu „handleContentNotFound()“. Dort wird geschaut, ob mit dem request überhaupt eine Anfrage nach einer SingleView gestellt wurde, also ob eine, in meinem Fall „event“ Variable mit übergeben wurde. Wenn dem so ist, existiert das Event nicht oder ist bereits abgelaufen. Ansonsten gehen wir davon aus, das die nur die DetailSeite aufgerufen wurde und diesen Aufruf leiten wir mit einem 301 auf die übergeordnete Seite, also die Listenansicht weiter.
