Bei einem Projekt mit einer vor öffentlichen Zugriffen geschützten Website sollte auch die REST-API nur für eingeloggte User aktiv sein, um zu verhindern, dass darüber Inhalte abgefragt werden können.
Nachdem ich zunächst geprüft habe, ob sich irgendwie die Permission-Callbacks verändern lassen, bin ich auf den rest_authentication_errors-Filter gestoßen, mit dem die Aufgabe relativ einfach zu lösen ist.
Bei der Entwicklung von Gutenberg-Blöcken ist die InnerBlocks-Komponente ein (zumindest bei mir) oft eingesetztes Mittel. Diese Komponente ermöglicht es, innerhalb eines Blocks weitere Blöcke einzufügen – bei den Core-Blöcken ist sie beispielsweise beim Spalten- und Cover-Block im Einsatz.
Dieser Komponente kann über das Attribut allowedBlocks ein Array von Blocknamen übergeben werden, um festzulegen, welche Blöcke eingefügt werden dürfen. Das ist zum Beispiel bei Wrapper-Blöcken hilfreich, wie dem Spalten-Block, der als direkten Kindblock nur den Block Spalte erlaubt.
Etwas komplizierter wird es, wenn nur bestimmte Blöcke nicht erlaubt sein sollen, denn etwas wie disallowedBlocks gibt es nicht.
Bisher hatte ich als Betriebssystem immer Windows und war damit meist auch sehr zufrieden. Mit dem Windows Subsystem for Linux waren meist auch die ganzen CLI-Tools, die es im Bereich Webentwicklung gibt, ohne große Probleme einsetzbar.
Allerdings gab es immer mal Kleinigkeiten, die dann doch nicht funktioniert haben, und in letzter Zeit ist mein Laptop immer mal wieder an seine Leistungsgrenze gekommen (was eventuell aber auch damit zusammenhing, dass ich eine Preview-Version von Windows verwendet habe).
Mit einem Wechsel auf Ubuntu habe ich schon ein paar Mal geliebäugelt, und vor ein paar Wochen war es dann soweit: ich habe Ubuntu als zweites Betriebssystem neben Windows installiert und nutze es seitdem fast ausschließlich, und abgesehen von ein paar Problemen am Anfang bin ich damit jetzt sehr zufrieden.
"Wechsel von Windows auf Ubuntu als Haupt-Betriebssystem" WeiterlesenBei einem Slider-Gutenberg-Block habe ich die Möglichkeit eingebaut, über ein Textfeld CSS einzugeben, das sich nur auf diesen einen Block auswirkt. Natürlich soll der User dabei nicht darauf achten müssen, die Selektoren so zu schreiben, dass sie wirklich nur für diesen Block gelten – das soll im Hintergrund vor der Frontend-Ausgabe geschehen.
Um das umzusetzen, habe ich mich nach einer PHP-Lösung zum Parsen von CSS umgeschaut und mit PHP CSS Parser ein passendes Tool gefunden.
"CSS-Selektoren in PHP eine Klasse voranstellen" WeiterlesenMit visuellen Regressionstests kann überprüft werden, ob es visuelle Unterschiede zwischen zwei Versionen einer Website gibt. Ein sinnvolles Szenario für so einen Test wäre beispielsweise, den Stand einer Website auf einem Testserver vor und nach dem Deployment einer Änderung zu überprüfen, und die Änderung nur auf den Live-Server zu schieben, wenn es keine visuellen Unterschiede gibt.
Es gibt verschiedene Lösungen zur Durchführung dieser Tests, hier stelle ich euch JLineup vor.
"Visuelle Regressionstests mit JLineup" WeiterlesenWenn ein PHP-Skript ausgeführt wird, lädt die Seite normalerweise so lang, bis die Aufgabe ausgeführt ist (oder es einen Fehler gibt). In vielen Fällen ist das auch kein Problem, da das Skript nicht lange braucht. Wenn es aber eine oder mehrere aufwendige Aufgaben erledigen muss und damit eventuell mehrere Minuten oder sogar Stunden beschäftigt ist, wäre es praktisch das im Hintergrund ablaufen zu lassen. Hier zeige ich, wie das in WordPress umgesetzt werden kann.
"Hintergrundprozesse in WordPress erstellen" WeiterlesenBisher war im WordPress-Core keine Funktion vorhanden, mit der sich externe Dienste einfach bei der Nutzung der REST-API einer WordPress-Website authentifizieren konnten. Mit WordPress 5.6 und der Integration des Application-Passwords-Plugins in den Core hat sich das geändert und es steht ein User-Flow zur Verfügung, um Dritt-Services bei einer WordPress-Website für spätere Anfragen zu autorisieren.
"Anwendungspasswörter in WordPress 5.6" WeiterlesenTorsten Landsiedel hatte für dieses Jahr das Projekt26 gestartet, bei dem alle zwei Wochen ein Blog-Artikel und ein Kommentar unter einem anderen Artikel geschrieben werden sollte. Bis Anfang Juni war ich auch noch gut dabei, habe dann allerdings stark nachgelassen.
Torsten hat auf seinem Blog im Beitrag »Projekt26 – Jetzt erst recht!« eine schöne Zusammenfassung geschrieben, und es wird auch im nächsten Jahr wieder ein Projekt26 geben. Ich werde dabei sein und diesmal hoffentlich auch bis zum Ende durchhalten.
Bei Gutenberg-Blöcken gibt es zwei Möglichkeiten: entweder wird das Block-Markup direkt beim Speichern eines Inhalts generiert und fertig in der Datenbank gespeichert (statisch). Oder es wird nur der Block-HTML-Kommentar in der Datenbank gespeichert, gegebenenfalls mit Attributen, und dann vor der Anzeige im Frontend das Markup dynamisch generiert.
Theoretisch sind dynamische Blöcke für Fälle wie Anzeige der letzten Beiträge gedacht, und statische für alle anderen Fälle, wo sich nichts ändern soll, ohne das bei dem Block etwas geändert wird. Allerdings gibt es bei den statischen Blöcken ein ziemlich großes Problem.
"Mein Problem mit statischen Gutenberg-Blöcken" WeiterlesenWordPress 5.5 bringt Unterstützung für das Markup zum nativen Lazy Loading mit. Dadurch kommt die Frage auf, ob die vielen Lazy-Loading-Plugins jetzt ausgedient haben. Ich werde das hier für mein Plugin Lazy Loader beantworten.
"Lazy Loading in WordPress 5.5 – warum Lazy Loader trotzdem weiter nützlich ist" Weiterlesen