CategoryBugs | Vulnerabilities

Laravel bei All-Inkl installieren

Für die Installation von Laravel gibt es eine Doku und sogar ein kostenloses Video. Darin wird empfohlen Laravel via Composer zu installieren. Letzteres steht standardmäßig auf einem All-Inkl Hosting zunächst nicht zur Verfügung. Aber All-Inkl stellt eine kleine Anleitung bereit, mittels der Composer installiert werden kann.

Der Aufruf von laravel new blog schlägt jedoch trotzdem mit folgender Meldung fehl sh: composer: command not found, obwohl Composer ordnungsgemäß installiert ist, was mittels dem Aufruf composerüberprüft werden kann.

Ursächlich dafür ist, laut Support von All-Inkl:

Die Verwendung des Befehls “laravel new” ist in der chroot Umgebung nicht möglich, da hier die nötige Verlinkung mit Composer nicht möglich ist. Sie müssen hier den Alternativen Befehl “composer create-project –prefer-dist laravel/laravel ZIEL_ORDER” nehmen.

Dieses Szenario wird auch auf der Installationsseite von Laravel beschrieben.

 

The response is not a valid JSON response. [Workaround] (Update)

Nach über vier Jahren wollte ich mal wieder einen Artikel posten und wurde im Editor nach kurzer Eingabe einiger Zeichen mit folgender Fehlermeldung begrüßt:


Updating failed. Error message: The response is not a valid JSON response.

Zunächst vermutete ich die Ursache bei einem meiner Plugins. Aber auch nachdem ich ein paar deaktiviert hatte, veränderte sich nichts. Im Frontend wurde mir immer nur Auto-Draft angezeigt, statt meiner eigentlichen Überschrift.

Die einzige für mich nachvollziehbare kurzfristige Lösung bzw. Workaround war die Installation und Aktivierung vom Classic Editor. Damit hat es auf Anhieb wieder wie gewohnt funktioniert.

Die Fehlermeldung scheint eine Vielzahl von Ursachen haben zu können. Nachdem ich noch ein bisschen weiter gesucht hatte, fand ich noch den Hinweis auf die Entwicklertools in Chrome, welche mit Strg+Umschalt+i aktiviert werden können. Die Console zeigte mir auch gleich eine ganze Latte von Einträgen an:


Mixed Content: The page at 'https://www.bugblog.de/wp-admin/post.php?post=1661&action=edit' was loaded over HTTPS, but requested an insecure resource 'http://www.bugblog.de/wp-json/wp/v2/posts/1661?_locale=user'. This request has been blocked; the content must be served over HTTPS.

Offensichtlich läuft mein Blog mittlerweile über HTTPS, nur Worpress habe ich das wohl bisher noch nicht mitgeteilt, so das intern die URL noch ohne das “s” aufgerufen wird. Also unter Settings->General die Einträge bei “WordPress Address (URL)” und “Site Address (URL)” aktualisiert. Damit verschwanden zwar die Einträge in der Console, aber für die Erstellung eines neuen Post muss ich weiterhin den Classic-Editor nutzen.

Falls jemand weitere Ansätze für die Fehlersuche hat, würde ich mich über einen entsprechenden Kommentar freuen.

Update: Ursächlich scheint irgend eine installierte Erweiterung zu sein. Nachdem ich jetzt mal alle Erweiterungen deinstalliert habe, funktioniert es jetzt wieder. Im Laufe der Zeit hatten sich einige Erweiterungen angesammelt und vermutlich sind nicht alle mit dem Gutenberg-Editor kompatibel.

BASE: Passwort size matters

Als ich heute auf der BASE-Seite mein Passwort ändern mußte, ein Initial-Passwort wird einem per SMS zugeschickt, war ich etwas überrascht über die Angabe der Passwortlänge bzw. erinnerte mich das an ein Gif, welches bestimmt schon etwas älter ist, aber deshalb nicht weniger wichtig, ganz im Gegenteil, denn mit steigender Rechner-Power bzw. dem Cloud Computing stehen heute für vergleichswenig wenig Geld fast unendliche Ressourcen zur Verfügung.

Zunächst der Ausschnitt aus der BASE-Webseite:

BASE Passwort Richtlinie

BASE Passwort Richtlinie

Wie auf dem Ausschnitt zu sehen, soll das Passwort genau 8 (in Worten acht) Zeichen lang sein. Erwartet hätte ich eine Angabe wie “mehr als 8 Zeichen”.

Intel Passwort Komplixität

Intel Passwort Komplixität

Basierend auf der Grafik werden für ein 8 stelliges Passwort nur ca. 15 Stunden benötigt. Mich würde wirklich mal der Grund interessieren, warum das Passwort auf acht Stellen begrenzt ist. Ich hoffe das Passwort wird nicht im Klartext gespeichert und das entsprechende Datenbankfeld ist nur 8 Zeichen lang.

SSD Festplatte wird nicht mehr erkannt – Crash!

Ohne jede Vorwarnung oder irgend ein Anzeichen wird meine SSD Vertex 2 nicht mehr in meinem Notebook erkannt. Ich muss zugeben, dass mir das Risiko bekannt war und nach über 4 Jahren in Benutzung und immer treuen Diensten kann ich der Festplatte auch keinen Vorwurf machen. Da ich im Keller noch die Original-Festplatte liegen hatte, welche sich ohne Probleme starten ließ und auf der auch noch das ursprüngliche Betriebssystem, ein Windows 7 Home, installiert ist, ging der Umstieg / Austausch relativ schnell. Wobei schnell relativ ist, denn man merkt schon bzw. hat das Gefühl, dass die Festplatte mit ihren 5.400 Umdrehungen deutlich langsamer reagiert als die SSD. Die Installation von Updates hat gefühlt 3 Tage gedauert, weil ich auch immer nur morgens und abends auf den Update-Button klicken konnte. Andererseits muss ich mir um den Speicherplatz erstmal keine Sorge mehr machen, denn mit 285 GB habe ich 2,5 mal so viel wie bei der SSD. Ausgehend von diesem Post bzw. dem Ereignis habe ich mir eine Reihe von Gedanken gemacht wie grundsätzlich mit Daten umzugehen ist. Wenn ich die Zeit finde, werde ich es hier im Blog entsprechend protokollieren.

Tipp für den nächsten Festplatten Crash: Bei der Installation kein Windows Passwort setzen, denn die ganzen Updates brauchen immer wieder einen Neustart und wenn sich keiner anmeldet, glaube ich, sucht der PC nicht nach weiteren Updates. Daher zur Beschleunigung des Update-Prozesses erstmal auf ein Passwort verzichten, welches später man immer noch setzen kann.

Call to undefined method GeneralUtility::readLLXMLfile()

Eine Aktualisierung von der TYPO3 CMS Version 4.5 LTS auf die 6.2 LTS wird wahrscheinlich die Tage häufiger durchgeführt, da es sich um die LTS-Versionen handelt und bei der 4.5 der Support ausläuft. Besonders wenn viele Extensions installiert sind, kann der Umstieg mehr als holprig werden. In diesem Fall kam es im Backend zu einer Fehlermeldung, wenn man neue Inhalte anlegen wollte:

Fatal error: GeneralUtility::readLLXMLfile

Folgende Fehlermeldung wird angezeigt, wenn auch ggf. in einer anderen Datei:

Fatal error: Call to undefined method TYPO3\CMS\Core\Utility\GeneralUtility::readLLXMLfile() in class.tx_xyz_wizicon.php on line 65

Glück im Unglück, die Fehlermeldung ist sehr sprechend und es ist auch gleich der Dateiname und die Zeilennummer angegeben, wodurch die Behebung schnell durchgeführt werden kann.

Der Fix: makeInstance(‘t3lib_l10n_parser_Llxml’)

Einfach in die angezeigte Datei wechseln und mittels Strg+F die entsprechende Stelle suchen und folgende Ersetzung durchführen:

// $LOCAL_LANG = t3lib_div::readLLXMLfile($llFile, $GLOBALS['LANG']->lang);
$parser = t3lib_div::makeInstance('t3lib_l10n_parser_Llxml');
$LOCAL_LANG = $parser->getParsedData($llFile, $GLOBALS['LANG']->lang);

Anschließend den Cache leeren und erneut Testen, ggf. kommt in einer Datei der Aufruf mehrmals vor, bzw. in vielen unterschiedlichen Dateien.

Gefunden hier: http://forge.typo3.org/issues/44413

Eine weitere Problematik ist häufig die Depraction-Meldung bzgl. Split().

[random_content group_id=”211″ num_posts=”1″]

© 2020 BugBlog.de

Theme by Anders NorénUp ↑