Ein Beispiel im Video zu den Neuerung in Laravel 7 mit dem Titel “Supercharged Blade Components” von Jeffrey ist, wie auch in den Kommentaren festgestellt wird, in Minute 3:30 nicht ganz nachvollziehbar.
Continue readingAuthor: debugger
DIY: Browser Extension
Eine Browser-Extension bzw. Erweiterung selbst zu programmieren ist gar nicht so schwierig wie man vielleicht meint. Zudem sind die Einsatzmöglichkeiten wirklich vielfältig. Nachfolgend aufgelistet ein paar Ressourcen, die gut als Einstieg zur Erstellung der eigenen ersten Erweiterung dienen können:
Über Google bin ich bei Mozilla fündig geworden. Auf Github findet sich ein Repository mit vielen verschiedenen Beispiel-Erweiterungen die als Grundlage für das eigene Projekt dienen können.
In dem nachfolgenden Video wird gezeigt, wie man über about:debugging (in die URL-Zeile vom Browser eintippen und mit Enter bestätigen) eine Erweiterung schnell und einfach temporär einbinden kann:
Mittels about:addons kann die Erweiterung einfach per Klick immer wieder deaktiviert und aktiviert werden. So kann man schnelle und einfach Änderungen an der Erweiterung testen.
Mozilla bietet unter dem Schlagwort “Anatomy of an extension” eine interessante Übersicht der verschiedenen Möglichkeiten, eine Erweiterung in den Browser zu integrieren. Nach meinem derzeitigen Verständnis gibt es drei Möglichkeiten:
- Hintergrundskripte: diese laufen die ganze Zeit im Browser im Hintergrund und sind nicht abhängig von der jeweiligen Webseite, sondern werden sogar bei der Betrachtung von PDFs ausgeführt. Über das Schlagwort “background.js” findet man weitere relevante Informationen dazu.
- Sidebars, Pop-ups, Options-Pages: hier hast du die Möglichkeit eigene HTML-Seiten einzubinden, welche mit dem Hintergrundskript kommunizieren können.
- Content scripts: diese werden direkt in die jeweilige Webseite eingebettet, können von dieser aber auch blockiert werden. Über das Schlagwort “content_scripts.js” finden sich Informationen dazu.
Wie fängt man jetzt am besten an? Ich habe damit angefangen mit das Repo mit den Beispielen von Github herunterzuladen und mir die verschiedenen Erweiterungen anzuschauen. Wenn bereits eine grobe Idee der Erweiterung existiert, kann man einfach mal schauen, welche davon der Idee am nächsten kommt. Diese kann man dann in Firefox temporär einbinden, wie oben im Video erläutert und auch gleichzeitig in einer IDE öffnen und anfangen ein bisschen zu experimentieren.
Hinweis: einE oft verwendete Debug-Ausgabe ist sicherlich “alert(123);”, dies ist jedoch bspw. bei den Background-Skripten nicht verfügbar. Was jedoch immer funktioniert ist “console.log(123);” jedoch erscheint die die Ausgabe nicht wie sonst üblich in der Konsole, welche man mittels Strg+Umschalt+I öffnet, sondern in der Konsole, die mit Strg+Umschalt+J geöffnet wird.
Dieser Hinweis findet sich auch nochmals fast am Ende in einer gelben Box.
Praxis-Tipp: Ich habe mir die Seiten “about:debugging” und “about:addons” als Lesezeichen direkt in die “Lesezeichen-Symbolleiste” gelegt.
Außerdem habe ich mir das kleine Freeware-Programm “DeskPins” besorgt, mit welchem die Browser-Konsole, welche mittels Strg+Umschalt+J aktiviert wird, immer im Vordergrund bleibt.
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.
Laravel 6 From Scratch – Cheat Sheet
Das Cheat Sheet ist in permanenter Weiterentwicklung, abhängig davon wie ich schnell ich dazu komme mir die einzelnen Videos nochmals anszuschauen Laravel 6 From Scratch. Entsprechend den Videos werde ich versuchen auch immer jeweils auf die Version 6 zu referenzieren. Ursprünglich hatte ich mir schon alle Videos angeschaut aber eher nebenbei und daher jetzt nochmals richtig:
Die Ordnerstruktur
// Routen /routes/web.php // Views /resources/views/ // Welcome /resources/views/welcome.blade.php // Compiled Versions /storage/framework/views/
Routen / Routing: Laravel Docs 6.x Routing
// Standard Route
Route::get('/', function(){
return view('welcome');
});
// Test Route
Route::get('test', function(){
return view('test');
});
// Minimalistisch
Route::get('/', function(){
return "Hello World";
});
// JSON
Route::get('/', function(){
return ['foo' => 'bar'];
});
// Mit Parameterübergabe (Long Version)
// Url-Example: laravel6.test/?name=FooBar
// View-File: test.blade.php
Route::get('/', function(){
$name = request('name');
return view('test', [
'name' => $name
]);
});
// Mit Parameterübergabe (Short Version)
// Url-Example: laravel6.test/?name=FooBar
// View-File: test.blade.php
Route::get('/', function({
return view('test', [
'name' => request('name')
]);
});
// Wildcard
// URL: laravel6.test/posts/FooBar
// Result: FooBar
Route::get('/posts/{post}, function($post){
return $post;
});
Blade Template-Engine
// BAD: RAW-Output (Vulnerable for XXS)
<h1><?= $name ?></h1>
// BAD: RAW-Output mit Blade (Vulnerable for XSS)
<h1>{!! $name !!}</h1>
// BETTER: Traditional PHP
<h1><?= htmlspecialchars($name,ENT_Quotes) ?></h1>
// BEST: Laravel Template Engine
<h1>{{ $name }}</h1>
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.
Recent Comments