Ich kann es mir einfach nicht merken… das folgende in die Repository Klasse:
public function initializeObject() { $querySettings = GeneralUtility::makeInstance(Typo3QuerySettings::class); $querySettings->setRespectStoragePage(false); $this->setDefaultQuerySettings($querySettings); }
Seit bestimmt zwei Jahren arbeite ich wie folgt: Docker Desktop, DDEV und WSL mit Ubuntu. Dazu nutze ich schon seit langer, langer Zeit mit PhpStorm mit ein paar nützlichen Plugins etc. Dabei liegen die Projekte in der Ubuntu Distribution und ich greife per \\wsl$\ auf sie zu. Im letzten Jahr hat PhpStorm schonmal Probleme bereitet – seit einem Update konnten auf einmal keine Projekte von WSL mehr geladen werden. Zum Glück war ich nicht die einzige mit diesem Problem und durch ein Rollback auf die vorherige Version konnte das Problem behoben werden.
Seit einem Windows Update (?) am Dienstag hatte ich nun wieder das Problem, dass PhpStorm keine Projekte aus der WSL laden wollte. Ich habe mehrmals verschiedene PhpStorm-Versionen installiert, leider immer das gleiche Ergebnis. Ein Kollege von mir schlug vor, alles (WSL, Ubuntu etc.) neu zu installieren. Gute Idee, aber dabei gingen ja die in Ubuntu abgelegten Projekte komplett verloren und mussten daher erstmal gesichert werden. In Linux ist ja das Windows-Laufwerk gemountet, der Zugriff aber ziemlich langsam, daher habe ich alle Projekte aus Ubuntu nach Windows verschoben. Das hat entsprechend den ganzen Tag gedauert. Am Ende des Tages alles neu installiert – und wieder das gleiche Ergebnis – langsamer Zugriff im Explorer und kein Zugriff aufs WSL in PhpStorm.
Dieser Kollege hat aber ein anderes Setup: bei ihm läuft DDEV direkt in Windows. Er startet ddev als nicht wie ich aus Ubuntu, sondern in PowerShell. Das hat bei mir leider nicht funktioniert. Beim Aufruf von ddev in PowerShell kamen nur Fehlermeldungen.
Auf purer Verzweiflung entschloss ich mich, ein vollständiges Backup einzuspielen. Ich nutze seit Jahren Acronis, um vollständiges Backup meiner Hauptplatte zu erstellen. Nun sollte sich zeigen, ob das funktioniert. Das Backup war von Dienstag früh, also zum Glück nicht so alt. Den ganzen Donnerstag rödelte mein armer Rechner, um das Backup einzuspielen (10 Std.?). Die Zeit habe ich zumindest sinnvoll genutzt, um eine Entwicklungsumgebung auf meinem Laptop einzurichten. Und da hat sich gezeigt, dass das folgende Setup erstaunlich gut funktioniert: Docker mit Hyper-V. Voraussetzung dafür ist, dass man Windows Professional nutzt und Virtualisierung erlaubt ist. Dann musste ich Docker nur noch neu installieren und dabei den Haken bei „WSL nutzen“ entfernen.
Das Einspielen des Backups hat sehr gut funktioniert – ein hoch auf Acronis. Das Problem war aber immer noch da – der Zugriff auf WSL war erstaunlich lahm. Nun habe ich also auf meinem Desktop-Rechner ebenfalls das genannte Setup mit Hyper-V und hoffe, dass es lange und update-sicher funktioniert.
Bei einem Projekt wurden die Zugriffsrechte der Dateien angepasst. Daraufhin wurden in Tortoise Git alle Dateien als bearbeitet aufgelistet. Allerding ist dabei die Anzahl Zeilen die dazugekommen bzw. entfernt wurden jeweils 0. Die Lösung ist einfach: (Forum-Eintrag siehe hier: https://superuser.com/questions/138669/why-is-tortoise-git-changing-my-file-permissions)
$ git config core.filemode false
Vor Weihnachten habe ich noch schnell die Prüfung zum TYPO3 CMS Certified Developer abgelegt und bin damit (wieder) zertifiziert.
Meiner Meinung nach war das die beste Lösung für eine Weiterleitung von ohne www auf mit www. Gefunden bei Stackoverflow.
RewriteCond %{HTTP_HOST} !^www\..+$ [NC] RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Es enthält keinen Domain-Namen und kann damit überall eingesetzt werden.
Vor TYPO3 9 und dem Routing im Core war RealURL sehr gnädig, was URLs anging. So konnte eine Seite mit .html Suffix und auch mit / aufgerufen werden (mein Empfinden). In TYPO3 10 funktioniert diese Verhalten nur in eine Richtung. Konfiguriert man eine .html Endung über den PageSuffix, ist die Seite weiterhin mit Trailing Slash aufrufbar. Es ist eigentltich gut, dass entweder das eine oder das andere geht. Wenn sie jemand die URL mit .html Endung gebookmarked hat und dann statt der Seite 404 bekommt, ist es ärgerlich.
Dank dieses sehr guten Beitrags auf stackoverflow hier mein Redirect-Schnipsel für die htaccess-Datei.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)\.html$ /$1/ [L,R=302]Als Tipp stand in dem Beitrag, dass man während des Testings den Fehlercode 302 verwenden sollte (found) und erst wenn es final ist, dann 301, weil dieser vom Browser gecached wird.
Dieser Blogbeitrag beschäftigt sich mit meiner zweiten Leidenschaft neben TYPO3 – dem Sport. Ich beschreibe meine Sport-Karriere und wie sich das ganze im letzten Jahr pandemie-geschuldet verändert hat.
Ich habe mir ein neues Modem (konkret eine FritzBox) zugelegt. Auf den ersten Blick schien alles so zu funktionieren wie vorher. Heute ist Montag, Zeit zu arbeiten: ddev gestartet und festgestellt, dass meine .ddev.site Domain mit der Meldung DNS_PROBE_FINISHED_NXDOMAIN nicht angezeigt wird. Beim ddev start gab es keine Fehlermeldungen, die Datenbank ist da und auf die Seite kann ich mit einer IP-Adresse zugreifen. Damit bleibt nur noch die Vermutung, dass die DNS-Auflösung die Ursache ist.
Nachdem ich die ddev-Troubleshooting-Seite und ein paar Foren durchsucht habe, stieß ich auf den entscheidenden Hinweis.
Die FritzBox hat ein Feature, das DNS-Antworten unterdrückt, die aufs eigene Netzwerk verweisen (DNS-Rebind-Schutz). Man muss die ddev.site dort unter Ausnahmen eintragen, damit die DNS-Auflösung funktioniert. Diese Option findet man unter Heimnetz > Netzwerk > Netzwerkeinstellungen.
Ich habe lokal unter Windows 10 ddev mit Ubuntu 20.04. aufgesetzt. Nach dem Login per SSH (ddev ssh) und dem Ausführen fast jeden Befehls (composer dump-autoload) kam die folgende Warnung:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20190902/redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902//usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902//usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'memcached.so' (tried: /usr/lib/php/20190902/memcached.so (/usr/lib/php/20190902/memcached.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/memcached.so.so (/usr/lib/php/20190902/memcached.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Erstmal hatte ich mich auf den „Unable to load“ block fokussiert. Sind die Dateien da? – ja. Ist der Pfad richtig? – ja. Ist das Modul installiert? – ja. Es gab viele „Lösungsvorschläge“ im Netz. Und es ist so unglaublich frustrierend, wenn das Problem als gelöst gilt („That solved it, thanks“) und es bei mir immer noch da ist. Ich habe sogar den ddev Installationsvorgang fast komplett neu gemacht. Immer noch die gleiche blöde Warnung, die mir die Konsole zumüllt.
Dann habe ich eher auf den zweiten Teil der Meldung geschaut und danach gesucht: „undefined symbol: igbinary_serialize“.
Lösung: Die aktuellere Version von redis (wohl auch memcached) setzt voraus, dass die Bibiothek igbinary bereits geladen ist. An einer Stelle stand, dass es theoretisch der Fall sein müsste, denn die Bibliotheken werden alphabetisch geladen und i kommt wohl vor r. Wenn man im Ordner .ddev/php eine Konfigurationsdatei ablegt, dann wird diese beim Starten des Containers geladen. Um das igbinary vor den anderen Bibliotheken zu laden, reicht es aus, wenn man eine leere Datei namens 10-igbinary.ini in diesem Ordner ablegt. Da alle anderen Biblitheken eine 20 als Priorität haben, wird die Datei mit 10- früher berücksichtigt.
Vielleicht ist ja jemand irgendwann genauso verzweifelt wie ich und diese „Lösung“ hilft ihm/ihr. Lasst es mich wissen…
(Custom error message for extbase validators)
Da ich auf die schnelle nichts gefunden habe und es mir selbst zusammengereimt hab, schreibe ich es hier besser auf. Um die Standard-Fehlermeldungen der Extbase-Validatoren zu ändern, schreibt man folgendes ins Setup:
config.tx_extbase._LOCAL_LANG.default { validator.notempty.null = This is a custom error message 1 validator.notempty.empty = This is a custom error message 2 }
Damit werden die Fehlermeldungen global für die Sprache geändert. Den Key (validator.notempty.null) findet man im Validator:
class NotEmptyValidator extends AbstractValidator { protected $acceptsEmptyValues = false; public function isValid($value) { if ($value === null) { $this->addError( $this->translateErrorMessage( 'validator.notempty.null', 'extbase' ), 1221560910);
Neueste Kommentare