WordPress Entwickler in Augsburg

Wer in Augsburg eine WordPress-Seite betreibt, pflegt sie meist nicht allein mit einem Entwickler, sondern mit einer Redaktion: Vertrieb, Marketing, Personal. Diese Seite beschreibt, wie ich WordPress so baue, dass diese Redaktion Seiten selbst anlegt und das Layout trotzdem zusammenhält. Ich bin Mariusz Szatkowski, Einzelentwickler aus Gdynia in Polen, arbeite remote und stimme mich schriftlich mit Ihnen ab.

Foto: Diego Delso, CC BY-SA 4.0, Wikimedia Commons.

#Warum die Redaktion im Mittelpunkt steht

Die IHK Schwaben beschreibt in ihrer Prognos-Studie 2026 zu den Branchenportfolios in Bayerisch-Schwaben, dass die Industrie mit 25,9 Prozent der Wertschöpfung eine zentrale Säule bleibt und die Luft- und Raumfahrt in allen vier Wirtschaftsräumen wächst, der Maschinenbau nur in dreien (IHK Schwaben). Für eine Website folgt daraus kein Muster, aber eine Gewohnheit: Wer erklärungsbedürftige Produkte verkauft, hat viele ähnliche Seiten. Produktlinien, Branchenlösungen, Stellenanzeigen, Ansprechpartner. Sie sehen gleich aus und werden von wechselnden Personen gepflegt.

Genau dort entscheidet sich, ob eine Seite nach zwei Jahren noch einheitlich aussieht. Bei Seitenbaukästen entsteht die Einheitlichkeit durch Disziplin der Redaktion. Im Block-Editor lässt sie sich in die Technik legen: Die Redaktion bekommt Bausteine, die nur so zusammenpassen, wie das Layout es vorsieht.

#Pattern, Block oder Vorlage: was wofür

Drei Werkzeuge liegen im Block-Editor nebeneinander, und die Wahl entscheidet über den späteren Pflegeaufwand.

Patterns zuerst. Das Theme-Handbuch von WordPress empfiehlt, Patterns im Ordner /patterns des Themes abzulegen, außer in Randfällen. WordPress erkennt dort jede Datei mit gültigem Datei-Header und registriert sie automatisch (Registering patterns). Im Header stehen unter anderem Titel, ein eindeutiger Slug der Form namespace/pattern-name, Kategorien, Block Types und Post Types. Mit Letzterem begrenze ich ein Pattern auf bestimmte Beitragstypen, damit die Redaktion bei einer Stellenanzeige nicht die Auswahl für Produktseiten sieht.

Ein Punkt aus dem Handbuch spart später Ärger: Vom Theme registrierte Patterns sind laut Einführung in Patterns nicht synchronisiert. Jede Einfügung erzeugt eine neue Instanz, und spätere Änderungen am Pattern erreichen bereits angelegte Seiten nicht. Das ist gewollt, hat aber eine Folge: Wer ein Pattern nach einem Relaunch ändert, ändert nicht automatisch die alten Seiten. Das gehört vorher in den Umfang, sonst kommt die Frage nach der Abnahme.

Eigener Block nur mit Grund. Ein Block lohnt sich in drei Fällen: Er holt Daten aus einer Quelle, etwa aus einem Beitragstyp für Datenblätter, er enthält Logik, die sich nicht aus Kernblöcken bauen lässt, oder sein Markup soll sich nicht verändern lassen. Die Beschreibung liegt in block.json. Das Handbuch nennt dort unter anderem apiVersion, name, title, category, parent, allowedBlocks, editorScript, viewScript, style und render (Block metadata). parent verlangt, dass ein Block nur innerhalb eines bestimmten übergeordneten Blocks erscheint, allowedBlocks legt fest, welche Blöcke direkt darin stehen dürfen. Zusammen ergeben sie Bausteine, die sich nur so verschachteln lassen, wie es der Entwurf vorsieht.

Bei serverseitig gerenderten Blöcken zeigt render auf eine PHP-Datei. Dort stehen $attributes, $content und $block zur Verfügung, die Ausgabe läuft über get_block_wrapper_attributes(), und Attribute aus dem Editor behandle ich als Eingaben, die vor der Ausgabe escaped werden. Der Nachteil: Die Datei läuft laut Handbuch für jede Instanz des Blocks beim Rendern der Seite. Ein Block mit schwerer Abfrage kostet deshalb bei jeder Verwendung Zeit, und eine Seite mit zwanzig Instanzen bekommt zwanzig Abfragen, wenn ich nichts dagegen tue.

#Sperren: was die Redaktion nicht anfassen soll

Bausteine allein halten ein Layout nicht zusammen, wenn jede Seite beliebig umgebaut werden kann. Das Handbuch zu Block-Templates beschreibt dafür zwei Mittel (Block templates).

Erstens eine Vorlage je Beitragstyp: Beim Registrieren des Typs lässt sich ein Startzustand aus Blöcken mit Platzhaltertexten festlegen. Zweitens die Sperre über template_lock:

• all verhindert Einfügen, Verschieben und Löschen,
• insert verhindert Einfügen und Löschen, erlaubt aber das Verschieben,
• contentOnly verhindert ebenfalls alle Strukturänderungen, blendet Blöcke ohne Inhalt aus der Listenansicht aus und lässt sich von untergeordneten Blöcken nicht aufheben.

In einem Block mit InnerBlocks gilt dasselbe als templateLock. Ist es dort nicht gesetzt, übernimmt der Bereich die Sperre des übergeordneten Bereichs, ein Block der obersten Ebene die des Beitragstyps. Einzelne Blöcke lassen sich über das Attribut lock gegen Verschieben und Entfernen schützen, und diese Einstellung hat Vorrang vor der Sperre der Vorlage.

Für Augsburger Auftritte nutze ich das vor allem bei Seitentypen mit fester Struktur, etwa Stellenanzeigen mit festen Pflichtabschnitten oder Produktseiten mit Datenblatt-Block. Wer die Sperre zu eng setzt, bekommt allerdings Rückfragen der Redaktion. Deshalb lege ich sie nicht pauschal fest, sondern mit Ihnen zusammen je Seitentyp, und halte das Ergebnis in der Pattern-Liste fest.

#Vom Layout-Raster zu den Blöcken

Design gehört nicht zu meinem Angebot. Layout und Gestaltung liefern Sie oder Ihre Designerin, als Figma-Datei oder als Tabellenvorlage, in der Sie je Ansicht markieren, welches Element wohin gehört. Aus diesem Raster entsteht die Block-Liste:

1. Ich zähle, welche Abschnitte auf mehreren Ansichten wiederkehren. Ein Abschnitt, der dreimal vorkommt, wird zum Pattern.
2. Ich prüfe je Abschnitt, ob Kernblöcke ihn tragen. Wenn ja, bleibt es beim Pattern.
3. Kommt eine Datenquelle, Logik oder festes Markup ins Spiel, wird daraus ein eigener Block mit block.json.
4. Ich lege je Seitentyp fest, was gesperrt wird.
5. Sie bekommen die Liste als Dokument: Name, Zweck, Pattern oder Block, Sperre. Gebaut wird nach Ihrer schriftlichen Bestätigung.

Zusätzliche Wünsche während der Arbeit bekommen ein eigenes Angebot und gehören nicht zum ursprünglichen Umfang.

#Ein Beispiel aus dem Maschinenbau-Umfeld

Ein Zulieferer hat 40 Produktseiten mit gleichem Aufbau: Kurzbeschreibung, technische Daten, Download der Datenblätter, Ansprechpartner. Das ist als Gedankenbeispiel gemeint, nicht als Kundenarbeit.

Die Kurzbeschreibung ist Fließtext und braucht keinen eigenen Block, ein Pattern aus Überschrift, Absatz und Bild genügt. Die technischen Daten kommen aus Feldern, die für alle Produkte gleich heißen müssen, damit ein Vergleich möglich ist: Hier trägt ein Block mit render.php die Ausgabe, die Redaktion füllt nur Felder. Das Datenblatt hängt als Datei an, der Ansprechpartner ist ein Eintrag aus einem eigenen Beitragstyp. Die Vorlage des Beitragstyps setzt die Reihenfolge, und contentOnly verhindert, dass jemand die Abschnitte umsortiert.

Ändert sich später die Darstellung der technischen Daten, ändere ich den Block an einer Stelle, und alle 40 Seiten ziehen nach. Eine Änderung an einem Pattern würde dagegen keine der bestehenden Seiten erreichen. Genau diese Unterscheidung bestimmt, was ich als Block baue.

#Einbettungen und Einwilligung

Redaktionen binden gern Karten, Videos und Formulare ein. § 25 Abs. 1 TDDDG erlaubt das Speichern von Informationen auf dem Endgerät oder den Zugriff darauf grundsätzlich nur nach informierter Einwilligung (§ 25 TDDDG). Die Ausnahmen stehen in Absatz 2. Für Einbettungen heißt das: Ein Block für Karten oder Videos lädt den Dienst erst nach der Zustimmung und zeigt vorher einen Platzhalter. So muss die Redaktion bei jedem Einbetten nicht daran denken.

Zuständig für private Unternehmen in Bayern ist das Bayerische Landesamt für Datenschutzaufsicht (BayLDA) in Ansbach. Es bittet darum, Beratungsanfragen, Beschwerden und Meldungen von Datenschutzverletzungen über seine Online-Formulare zu schicken (Kontakt des BayLDA). Für Soloselbstständige und kleine Unternehmen im Handel bietet das Amt eine Checkliste zur Umsetzung der datenschutzrechtlichen Anforderungen an (BayLDA). Eine Rechtsberatung ersetzt das nicht, und ich gebe keine.

#Was Sie vorbereiten

• das Layout als Figma-Datei oder ausgefüllte Tabellenvorlage,
• eine Liste der Seitentypen, die Ihre Redaktion anlegt, mit ungefährer Zahl,
• Namen oder Rollen der Personen, die pflegen, damit ich die Rechte passend setze,
• bei einer bestehenden Seite den Zugang als Administrator und die Angabe des Hosters,
• die Frage, welche Seitentypen strikt gesperrt sein sollen und wo die Redaktion frei arbeiten darf.

#Wie ein Projekt abläuft

1. Sie schicken Ziel, Layout-Raster und gegebenenfalls Zugang zur bestehenden Seite.
2. Ich lege die Block-Liste mit Umfang, Ausschlüssen und Abnahmekriterien als Dokument vor.
3. Ich baue Theme, Patterns und Blöcke in Branches und zeige Stände auf einer passwortgeschützten Staging-Kopie.
4. Ihre Redaktion legt dort echte Seiten an. Ich prüfe Tastaturbedienung, Kontraste, Formulare, Weiterleitungen und Core Web Vitals, die Schwellen stehen auf web.dev: LCP bis 2,5 s, INP bis 200 ms, CLS bis 0,1.
5. Sie erhalten Dokumentation, Pattern-Liste und einen kurzen Redaktionsleitfaden.
6. Auf Wunsch folgt die Wartung, siehe Wartung und Support in Augsburg. Stunden daraus gelten im jeweiligen Monat und rollen nicht über.

Einen Shop mit Zahlarten und Rechtstexten behandelt die Seite WooCommerce Entwickler Augsburg, das Angebot ohne Ortsbezug steht unter WordPress Entwickler.

#Fragen aus Augsburg

Wann reicht ein Block-Pattern und wann brauche ich einen eigenen Block? Ein Pattern genügt, wenn die Redaktion Texte, Bilder und Reihenfolge verändern soll und der Aufbau aus Kernblöcken besteht. Ein eigener Block lohnt sich bei Logik, einer Datenquelle oder Markup, das sich nicht verändern darf.

Ändert sich eine Seite, wenn ich ein Pattern später anpasse? Nein. Vom Theme registrierte Patterns sind laut Handbuch nicht synchronisiert: Jede Einfügung ist eine eigene Kopie, spätere Änderungen am Pattern erreichen bestehende Seiten nicht.

Kann die Redaktion das Layout versehentlich zerstören? Das lässt sich einschränken. Vorlagen können gesperrt werden, sodass Blöcke weder eingefügt noch verschoben oder gelöscht werden, und mit contentOnly bleibt nur der Inhalt bearbeitbar.

Gestalten Sie das Layout der Blöcke? Nein. Layout und Gestaltung liefern Sie oder Ihre Designerin. Ich setze sie um, auf Wunsch aus einer Tabellenvorlage, in der Sie je Ansicht markieren, welches Element wohin gehört.

Was passiert mit eigenen Blöcken, wenn ein Entwickler wechselt? Jeder Block liegt als Ordner mit block.json im Repository, mit Beschreibung und Beispiel. Ein anderer Entwickler findet Name, Attribute und Renderdatei an festen Stellen.

Gilt für eingebettete Karten und Videos eine Einwilligung? Wenn dabei Informationen auf dem Endgerät gespeichert oder ausgelesen werden, verlangt § 25 Abs. 1 TDDDG grundsätzlich eine Einwilligung. Ein Block für solche Einbettungen lädt den Dienst deshalb erst nach der Zustimmung.

#Wer hier entwickelt

Seit 2006 arbeite ich mit WordPress, mein Profil bei wordpress.org ist öffentlich einsehbar. Namen von Kunden gebe ich nicht weiter.

#Anfrage

Schreiben Sie über die Kontaktseite, welche Seiten Ihre Redaktion anlegt, ob ein Layout vorliegt und bis wann die Seite stehen soll. Dazu hilft die Adresse der bestehenden Seite und der Hoster. Das erste schriftliche Angebot ist kostenlos.