blue

Immer wieder kommt es vor, das man sich DNS Einträge von Domains einsehen bzw kontrollieren muss. Bisher bin ich immer über google und habe was wie mx record online/ dns checker online oder ähnlich Kram gegoogelt und bin zum Teil auf sehr dubiosen Seiten gelandet. Ab und an noch ein Captcha ausfüllen, CookieBanner wegklicken, nein ich möchte kein Newsletter anklicken, nein ich möchte keine Website Benachrichtigungen 😩😩😩 NUR die Information bitte …. NEIN, diese Services interessieren mich auch nicht *wegklicken* 🤬🤬🤬 ….
Ihr kennt es wahrscheinlich auch …

Zur Rettung kommt wie so oft, das Terminal/CMD/ITerm2 ….
die CommandLine:

In diesem Fall ist es das Tool „host – DNS lookup utility“

Beispiel:

host -t TXT blue-side.de

The -t option is used to select the query type. type can be any recognized query type: CNAME, NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified, host automatically selects an appropriate query type. By default, it looks for A, AAAA, and MX records, but if the -C option was given, queries will be made for SOA records, and if name is a dotted-decimal IPv4 address or colon-delimited IPv6 address, host will query for PTR records. If a query type of IXFR is chosen the starting serial number can be specified by appending an equal followed by the starting serial number (e.g. -t IXFR=12345678).

Ausgabe Beispiel

Ein kleines simples Tool, but it made my day:

How to delete history without any trace

history -d $((HISTCMD-1)) && history -d NO_of_History_you_want_to_delete

if you want to excute a command without leaving any trace.

history -d $((HISTCMD-1)) && type_your_command_here_and_execute

hier gefunden

Auch Ich bin über dieses Problem im Zusammenhang mit TYPO3 und ddev 1.19 gestossen und habe dann den Artikel von Sven Wappler gefunden, in dem Stefan Frömken die Lösung in den Kommentaren erläutert. Vielen Dank an euch beide 🙂

In der von ddev erstellten AdditionalConfiguration.php muss folgendes ergänzt werden:

            'DB' => [
                'Connections' => [
                    'Default' => [
                        ....
                        'charset' => 'utf8mb4',
                         ...
                    ],
                ],
            ],

Danach caches leeren und es läuft wieder.

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.

Apache config before:

RewriteRule ^(?:typo3/|fileadmin/|typo3conf/|typo3temp/|uploads/) - [L]

Apache config after:

RewriteRule ^(?:fileadmin/|typo3conf/|typo3temp/|uploads/) - [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^typo3/(.*)$ %{ENV:CWD}typo3/index.php [QSA,L]

Quelle:
https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/11.0/Breaking-93048-BackendURLRewrites.html

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:

$arguments = '&tx_nimeinenAltePiBaseExtension_pi1[showUid]=' . (int)$record['uid'];
$singleViewPageUid = '100';
$singleViewLink =  \tx_pagepath_api::getPagePath($singleViewPageUid, $arguments);
 

und nutzen dann wie auf dem StackOverflow Beitrag den Code von Mathias.

use TYPO3\CMS\Core\Site\SiteFinder;
use TYPO3\CMS\Core\Utility\GeneralUtility;

....


$arguments = [
 'tx_nimeinenAltePiBaseExtension_pi1' => ['showUid' => (int)$record['uid']],
];
$singleViewPageUid = '100';
$site = GeneralUtility::makeInstance(SiteFinder::class)->getSiteByPageId($singleViewPageUid);

$singleViewLink = (string)$site->getRouter()->generateUri((string)$singleViewPageUid, $arguments);

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

$site = GeneralUtility::makeInstance(SiteFinder::class)->getSiteByIdentifier('test');

Den Namen kann man im Modul Sites auslesen, das ist dann auf der Übersichtsseite der „Configuration Folder“

Für alle die Wissen wollen warum es einfacher wäre, ein Blick in den Code verrät warum es.
->getSiteByPageId vs ->getSiteByIdentifier

getSiteByPageId() ist aber einfacher (und damit auch sicherer) in der Handhabung, je nach Umgebung, Konfigurationen der Systeme und im Einsatz in verschiedenen Erweiterungen.