WordCamp Polen 2023 - Gliwice Bericht und Zusammenfassung

Das WordCamp Polen 2023 in Gliwice, offiziell WordCamp Gliwice 2023, fand vom 12. bis 14. Mai 2023 im Bildungs- und Kongresszentrum der Schlesischen Technischen Universität in der ul. Konarskiego 18B statt (Veranstaltungsseite, Veranstaltungsort). Der Freitag war der Tag der Mitarbeit am Projekt, Samstag und Sonntag gehörten den Vorträgen, Workshops und dem Business-Mastermind.

Dieser Bericht hält sich an das offizielle Programm. Jeder Name und jedes Thema unten stammt aus der Agenda und den Sessionbeschreibungen, die die Organisatoren veröffentlicht haben. Wo wir über den Inhalt eines Vortrags schreiben, stützen wir uns auf die Sessionbeschreibung oder die Aufzeichnung, nicht auf Erinnerungen aus den Pausengesprächen. Die Codeausschnitte sind unsere eigenen Beispiele zu den Themen von der Bühne und als solche gekennzeichnet.

Wenn Ihr Unternehmen erfahrene technische Unterstützung braucht oder Sie eine komplexe Migration planen, sehen Sie sich an, was wir bei WPPoland als WordPress-Entwickler machen.

#Programm des WordCamp Gliwice 2023 Tag für Tag

Die Organisatoren teilten das Programm in sieben Tracks auf. Samstag und Sonntag liefen parallel in mehreren Sälen, daher konnte niemand alles live sehen.

Den Samstag eröffnete Tomasz Karwatka, nach ihm sprach Krzysztof Dyszczyk über das Leben im Zeitalter der KI. Beide Tage endeten mit einer Q&A-Session. Die vollständige Liste der Sessions finden Sie auf der Seite Sessions.

#Was passiert am WordCamp Contributor Day

Die Konferenz begann am Freitag, dem 12. Mai, mit dem Contributor Day. Statt Vorträge zu hören, arbeiten die Teilnehmenden an diesem Tag in Arbeitsgruppen, die das WordPress-Ökosystem weiterentwickeln.

Laut der Seite zum Contributor Day sah der Tag so aus:

• 9:30-10:00: Registrierung, Kaffee und Tee.
• 10:00-10:30: Begrüßung, Aufteilung in Teams und Start der Arbeit an den Tischen, mit einem kurzen Einführungsworkshop für alle, die zum ersten Mal dabei waren.
• 10:30-12:30: Arbeit (Contributing), danach Mittagspause und eine zweite Arbeitsrunde.
• Zum Abschluss eine Zusammenfassung des Tages und die Besprechung der Ergebnisse.

Die Organisatoren betonten, dass der Tag allen offensteht, nicht nur Programmierern: auch Grafikern, Marketingleuten, Übersetzern und Fotografen, unabhängig von der Erfahrung. In der Beschreibung wurden das Beheben von Fehlern, das Ergänzen fehlender Übersetzungen, das Erstellen von Inhalten und das Hinzufügen von Fotos zur offenen Mediendatenbank genannt. Für die Teilnahme brauchte man ein Konferenzticket und eine separate Anmeldung.

Für Agenturen hat dieser Tag einen praktischen Nutzen. Wer selbst einen Fehler meldet oder eine Übersetzung korrigiert, versteht besser, wie Änderungen in den Core gelangen und wie lange der Weg von der Meldung bis zum Release dauert. Anleitungen zu Full Site Editing und zum Blockeditor entstehen genau auf diese Weise.

#Business-Vorträge auf dem WordCamp Gliwice 2023

Der Business-Track am Samstag drehte sich um die Führung eines Unternehmens rund um WordPress. Die Sessionbeschreibungen sind konkret, daher fassen wir sie nah an der Quelle zusammen.

#Vom Dienstleister zum Produktunternehmen (Tomasz Karwatka)

Tomasz Karwatka war unter anderem Mitgründer von Divante, Vue Storefront, Callstack und Open Loyalty und leitet heute Catch The Tornado, ein Unternehmen, das in Technologiegründer investiert (Biografie des Sprechers). In der Vortragsbeschreibung erklärte er, dass es bei Divante und Callstack gelang, Produkte aufzubauen, darunter Vue Storefront, das den Accelerator Y Combinator durchlaufen hat.

Angekündigte Themen: warum so wenige Dienstleistungsunternehmen beim Aufbau von Produkten Erfolg haben, welche Fehler sie am häufigsten machen, was das wirklich kostet, wie aus einem Projekt ein vollwertiges Unternehmen wird, wie man externe Finanzierung gewinnt und wie der Inhaber eines Dienstleistungsunternehmens den Wert für sich selbst maximieren kann. Die Aufzeichnung finden Sie auf WordPress.tv.

#Zwei Jahre OKR in einem WordPress-Team (Michał Kaźmierczak)

Über die Methode OKR (Objectives and Key Results) sprach Michał Kaźmierczak. Sein Vortrag war eine Bilanz aus über zwei Jahren OKR in einem WordPress-Entwicklerteam: was funktioniert hat, was nicht und wer diese Methode überhaupt braucht. Die Sessionbeschreibung nennt keine konkreten Kennzahlen, daher ergänzen wir hier keine. Die Details stehen in der Aufzeichnung.

#WooCommerce als Herz des Geschäfts (Łukasz Wilczak)

Łukasz Wilczak stellte eine Fallstudie zu einem WooCommerce-Shop vor, dessen Jahresumsatz in Millionen Złoty gemessen wird. Der Shop verkauft Unikate und Produkte auf Bestellung, und WooCommerce verbindet Zahlungen, Versand, Rechnungen und CRM. Der Vortrag zeigte den Produktkonfigurator, den Warenkorb, die Bestellabwicklung und wie der Shop die Arbeit des Teams und den Kontakt zu den Kunden verändert hat (Aufzeichnung).

#Weitere Vorträge zum Thema Business

Im selben Track sprachen: Ola Gościniak (Angebotstreppe digitaler Produkte), Aleksander Misky (Abomodell in WordPress), Izabela Karkocha (Projekte so abschließen, dass der Kunde weiterempfiehlt), Adrian Kałamajski (Verkauf von Kursen und E-Books), Tomasz Kołkiewicz (Tauschgeschäfte als Weg zu Nachfrage, wenn Kunden Kosten senken), Dariusz Pichalski (der Weg zum größten polnischen Kanal über WordPress), Krzysiek Dróżdż, Dominik Kawula (ein Unternehmen, zu dem Kunden zurückkehren) und Marta Domasz (Investitionen in die Entwicklung der Mitarbeitenden). Am Sonntag stellte Przemysław Hernik fünf Regeln für das Schätzen von Aufgaben vor, die Entwicklern ebenso helfen wie Managern.

#Headless WordPress mit Astro auf dem WordCamp Gliwice

Maciek Palmowski hatte zwei Programmpunkte zum selben Thema, aus zwei Richtungen.

Am Samstag leitete er einen Workshop zur Integration von WordPress mit Astro (Saal J). Laut Beschreibung lernten die Teilnehmenden die Grundlagen von Astro kennen: Dateistruktur, Komponenten, Layouts und Routing, und verbanden zum Schluss WordPress mit Astro in beiden Modi, SSG und SSR. Diese Unterscheidung ist wichtig: Im SSG-Modus entstehen die Seiten beim Build, im SSR-Modus auf Anfrage, daher hängt die Wahl davon ab, wie oft sich der Inhalt ändert.

Am Sonntag, im Technology-Track, stellte Palmowski die Frage, ob Headless WordPress wirklich sinnvoll ist. In der Beschreibung merkte er an, dass man aus vielen Artikeln und von vielen Firmen den Eindruck gewinnen kann, Headless sei der einzig richtige Weg, und fragte direkt, ob das nicht einfach eine weitere Art ist, Geld zu verdienen (Aufzeichnung). Am selben Tag zeigte Adam Kanigowski eine Fallstudie zu Astro und WordPress als Headless CMS: in welchen Projekten sich das bewährt, wie man sein bevorzugtes JS-Framework (zum Beispiel Vue.js) einbindet und welche Fehler beim Programmieren auftreten (Aufzeichnung).

Unten unser eigenes Schema einer solchen Architektur, keine Folie von der Konferenz:

DECOUPLED HEADLESS WORDPRESS ARCHITECTURE:
+-------------------------------+      REST API / GraphQL      +-------------------------------+
|     WordPress Backend         | ---------------------------> |     Astro                     |
| (wp-admin, editorial workflow,|       JSON Data Payloads     | (SSG at build time or SSR     |
|  custom post types, ACF)      |                              |  on request, component islands)|
+-------------------------------+                              +-------------------------------+
                |                                                              |
                v                                                              v
+-------------------------------+                              +-------------------------------+
| MySQL / MariaDB Database      |                              | CDN or edge hosting           |
| (not exposed to visitors)     |                              | (serves the generated HTML)   |
+-------------------------------+                              +-------------------------------+

#Warum ein Astro-Frontend weniger JavaScript ausliefert als ein typisches SPA

In einer klassischen WordPress-Installation zwingt jede HTTP-Anfrage PHP dazu, die Plugins zu laden, Abfragen an wp_posts und wp_postmeta auszuführen, die Template-Hierarchie zu durchlaufen und das fertige HTML zusammenzusetzen. Ein Seitencache mildert diese Kosten, beseitigt sie aber nicht.

Astro erzeugt im SSG-Modus das HTML während des Builds. Komponenten werden standardmäßig ohne clientseitiges JavaScript gerendert, und Interaktivität wird nur dort aktiviert, wo Sie es mit einer Direktive angeben, zum Beispiel client:idle oder client:visible (Dokumentation der Astro-Direktiven). Das WordPress-Backend kann dann auf einer eigenen Subdomain laufen, und die Besucher erhalten fertiges HTML ohne Kontakt zu PHP und Datenbank. Ob sich das lohnt, hängt vom Projekt ab, und genau danach fragte Palmowski am Sonntag.

#Beispiel für getStaticPaths in Astro mit der WP REST API

---
// src/pages/blog/[slug].astro
export async function getStaticPaths() {
  const response = await fetch("https://cms.example.com/wp-json/wp/v2/posts?_embed&per_page=100");
  const posts = await response.json();

  return posts.map((post) => ({
    params: { slug: post.slug },
    props: { post },
  }));
}

const { post } = Astro.props;
const featuredImage = post._embedded?.['wp:featuredmedia']?.[0]?.source_url;
---

<article class="prose max-w-3xl mx-auto py-12">
  <h1>{post.title.rendered}</h1>
  {featuredImage && <img src={featuredImage} alt={post.title.rendered} loading="eager" />}
  <div set:html={post.content.rendered} />
</article>

#WP-CLI: fortgeschrittene Techniken und sicheres search-replace

Marcin Krzemiński leitete am Samstag einen Workshop zu fortgeschrittenen WP-CLI-Techniken für alle, die die Grundlagen bereits kennen. Laut Beschreibung installierten und nutzten die Teilnehmenden WP-CLI-Erweiterungen, generierten Plugin- und Theme-Code und arbeiteten mit WP-CLI per SSH auf einem entfernten Server. Die Workshops wurden nicht aufgezeichnet.

Teams, die mehrere Umgebungen betreuen, verschieben früher oder später eine Datenbank zwischen Domains. Dieser Abschnitt ist unsere Ergänzung auf Grundlage der Dokumentation zu wp search-replace.

#Wie man serialisierte Daten sicher ersetzt

Die typische Katastrophe bei manuellen SQL-Skripten für search-and-replace ist die Beschädigung serialisierter PHP-Arrays in den Tabellen wp_options und wp_postmeta. Wenn sich die Länge des Textes ändert, die gespeicherte Länge aber nicht (zum Beispiel s:21:"https://staging.local" ersetzt durch s:19:"https://example.com"), kann PHP das Objekt nicht wiederherstellen. Die Folge sind defekte Widgets und verlorene Theme-Einstellungen.

Laut WP-CLI-Dokumentation behandelt der Befehl serialisierte PHP-Daten intelligent und ändert keine Werte von Primärschlüsseln. Standardmäßig nutzt er schnelle SQL-Abfragen und wechselt in Spalten mit serialisierten Daten zu PHP, während das Flag --precise PHP für alle Spalten erzwingt, was langsamer, aber bei komplexen Strukturen zuverlässiger ist:

# Step 1: dry run to preview affected tables and matching rows
wp search-replace "https://staging.example.com" "https://example.com" \
  --all-tables \
  --dry-run \
  --precise

# Step 2: export a backup, then run the replacement
wp db export pre-migration-backup.sql
wp search-replace "https://staging.example.com" "https://example.com" \
  --all-tables \
  --precise \
  --recurse-objects

#Automatisierte Updates von Plugins und Core in Skripten

# Verify file checksums against official WordPress.org releases
wp core verify-checksums
wp plugin verify-checksums --all

# Update every plugin that has an update available
wp plugin update --all

# Flush object cache and regenerate rewrite rules
wp cache flush
wp rewrite flush --hard

#Dependency Injection in WordPress-Plugins

Bartek Jaskulski leitete am Samstag einen Workshop über einen Container für Dependency Injection in WordPress-Plugins (Saal F). Laut Beschreibung bauten die Teilnehmenden ein Beispiel-Plugin live um, und die Session konzentrierte sich auf die Konfiguration von PHP-DI, einem der beliebtesten DI-Container in PHP. Behandelte Themen: das Prinzip der Abhängigkeitsumkehr als Ausgangspunkt, das Vermeiden des Service-Locator-Musters, die Rolle von Interfaces in der objektorientierten Programmierung und das Erstellen zustandsloser Services.

Das Problem, das damit gelöst wird, kennt jeder, der ältere Plugins pflegt: Hunderte Funktionen in einer Datei, globale Variablen (global $wpdb) und Datenbankaufrufe, die mit der Logik verflochten sind. Das folgende Beispiel stammt von uns. Es zeigt eine Klasse, die ihre Abhängigkeiten über den Konstruktor erhält, statt sie selbst zu erzeugen:

<?php
declare(strict_types=1);

namespace WPPoland\Plugin;

interface CacheInterface {
    public function get(string $key): mixed;
    public function set(string $key, mixed $value, int $ttl = 3600): bool;
}

final class ObjectCacheService implements CacheInterface {
    public function get(string $key): mixed {
        return wp_cache_get($key, 'wppoland_group');
    }

    public function set(string $key, mixed $value, int $ttl = 3600): bool {
        return wp_cache_set($key, $value, 'wppoland_group', $ttl);
    }
}

final class CustomerReportManager {
    public function __construct(
        private readonly CacheInterface $cache,
        private readonly \wpdb $db
    ) {}

    public function generateReport(int $customerId): array {
        $cacheKey = "customer_report_{$customerId}";
        $cached = $this->cache->get($cacheKey);

        if ($cached !== false) {
            return $cached;
        }

        $query = $this->db->prepare(
            "SELECT * FROM {$this->db->prefix}customer_orders WHERE customer_id = %d",
            $customerId
        );
        $data = $this->db->get_results($query, ARRAY_A);

        $this->cache->set($cacheKey, $data, 1800);
        return $data;
    }
}

Ein solcher Aufbau erlaubt es, in PHPUnit- oder Pest-Tests eine Attrappe von CacheInterface einzusetzen, ohne laufende WordPress-Datenbank. Ein Container wie PHP-DI setzt diese Objekte automatisch zusammen, sodass das manuelle new aus dem Startcode des Plugins verschwindet.

#Tests, lokale Umgebungen und E-Mail: Sessions für Entwickler

Mehrere Sessions im Technology-Track am Sonntag und Workshops am Samstag befassten sich mit der täglichen Arbeit von Entwicklern.

• Sebastian Kurzynowski trat zweimal auf. Am Samstag leitete er einen Workshop zu TDD mit React: zuerst die Tests, dann Code, der sie erfüllt, und zum Schluss ein Refactoring auf Grundlage dieser Tests, mit dem Schwerpunkt auf der Trennung von Geschäftslogik und visueller Ebene. Am Sonntag sprach er darüber, wie TDD und andere qualitätsorientierte Ansätze Geld sparen und wie man TDD in einem Team einführt, das überwiegend aus Leuten besteht, die gerade erst in der IT anfangen (Aufzeichnung).
• Piotr Niewiadomski zeigte eine schlanke lokale Umgebung für WordPress aus Docker, Composer, dem eingebauten Webserver von PHP und einer SQLite-Datenbank.
• Bartosz Nowak stellte Juniper vor, ein offenes Boilerplate, das nach den Workshops auf dem WordCamp 2022 weiterentwickelt wurde. Die neue Version brachte .sh-Skripte zum Aufsetzen eines Projekts, einen objektorientierten Ansatz im Theme und die Verwaltung von Plugins über composer.json (Repository auf GitHub).
• Kamil Porembiński beantwortete die Frage, warum E-Mails aus WordPress im Spam landen und ob ein Versand-Plugin allein das Problem löst (Aufzeichnung).
• Der Sicherheitsworkshop am Samstag in Saal J richtete sich an Marketer, Blogger und Unternehmer: Passwort- und Zugriffsrichtlinien für WordPress, die Prüfung auf Datenlecks und das Vorgehen nach einem Datenleck.

#WordPress-Performance auf dem WordCamp Gliwice 2023: TTFB, Core Web Vitals und Bilder

Über Performance sprachen mehrere Personen, jede aus einem anderen Blickwinkel.

• Aneta Rutkowska fragte, ob nur das Hosting die TTFB beeinflusst. In der Beschreibung kündigte sie eine Fallstudie zu einer Website an, deren TTFB von über 3 s auf 110 ms sank, eine Auswertung von 65 000 WordPress-Installationen beim Hoster LH.pl und der zehn am häufigsten installierten Plugins sowie einen Vergleich, wie stark Hosting und Plugins die TTFB beeinflussen (Aufzeichnung).
• Krystian Wójcik leitete einen Workshop zu den Empfehlungen für Core Web Vitals: wie man jeden Messwert verbessert, worauf man achten sollte und wann sich die Jagd nach 100/100 nicht lohnt. Wie wir das angehen, beschreiben wir im Leitfaden zu Core Web Vitals.
• Mateusz Gbiorczyk verglich die Formate WebP und AVIF auf Basis seiner Erfahrungen mit einem Plugin zur Bildkonvertierung, das Hunderttausende Websites nutzen (Aufzeichnung).
• Jakub Józwiak zeigte die Einbindung von Algolia in WordPress, also die Auslagerung der Suche in einem großen Datenbestand aus der WordPress-Datenbank.
• Piotr Pantkowski leitete einen Workshop zur Wahl eines Servers für WordPress: die häufigsten Fehler beim Kauf von Hosting und die Prüfung der wichtigsten Funktionen in der Praxis.
• Maciej Kuchnik sprach über schwierige Datenmigrationen zwischen WordPress-Installationen und darüber, wie man sie plant.

#Wie man WP-Cron auf dem Server entlastet

Ein Thema kommt bei jedem Gespräch über TTFB auf, daher ergänzen wir es auf Grundlage des WordPress Plugin Handbook. WP-Cron prüft bei jedem Seitenaufruf die Liste der geplanten Aufgaben und startet die, deren Termin verstrichen ist. Es läuft nicht im Hintergrund wie ein System-Cron, daher wird eine für 14:00 Uhr geplante Aufgabe erst beim ersten Seitenaufruf nach dieser Uhrzeit ausgeführt.

Das Handbuch beschreibt die Übergabe von WP-Cron an den Aufgabenplaner des Systems: zuerst eine Aufgabe im System (unter Linux über crontab -e), dann das Abschalten der Ausführung bei Seitenaufrufen mit der Zeile define( 'DISABLE_WP_CRON', true ); in wp-config.php. Laut Dokumentation ist das Auslösen von WP-Cron bei jedem Seitenaufruf dann nicht mehr nötig und bedeutet nur zusätzliche Last für den Server.

#Gutenberg und Full Site Editing im Programm

Magdalena Paciorek zeigte fertige Gutenberg-Komponenten, mit denen Entwickler den Editor erweitern können: neue Blöcke und Seitenleisten erstellen, an Beispielen aus echten Projekten (Aufzeichnung).

Łukasz Wroński leitete am Sonntag einen Workshop für alle, die Websites mit Page Buildern bauen und mit Full Site Editing anfangen wollen. Der Plan umfasste ein Child-Theme mit Dateistruktur (theme.json, functions.php, CSS- und JS-Dateien), die Übertragung einer einfachen Landingpage von Figma nach WordPress, das Einbinden einer eigenen Schrift sowie neue Stile für Buttons und Listen.

#Zukunft von WordPress, KI und WordPress Playground

Der Track Future&Business stellte Fragen zur Richtung der gesamten Plattform.

• Krzysztof Dyszczyk sprach im Eröffnungsvortrag am Samstag über Trends in der künstlichen Intelligenz und die Herausforderungen, die ihre Verbreitung mit sich bringt.
• Ein Panel zu KI mit Krzysztof Radzikowski, Marta Domasz und Maciej Kuchnik, moderiert von Kasia Aleszczyk, ging der Frage nach, ob man KI nutzen oder um seinen Job fürchten sollte.
• Albert Nogala zerlegte die Frage nach dem Zustand von WordPress in geschäftliche, soziale und technologische Faktoren.
• Michał Strześniewski verglich No-Code- und Low-Code-Werkzeuge mit dem klassischen Ansatz, Websites mit WordPress zu bauen.
• Oskar Sajdak sprach über WordPress in den Clouds AWS und Azure und über die Probleme, die dort auf Entwickler warten.
• Mariusz Jałyński und Dominik Charasim befassten sich mit dem Einfluss von KI auf SEO und mit der Arbeit mit ChatGPT.

Technisch am konkretesten war der Vortrag von Adam Zieliński über WordPress Playground, also WordPress, das im Browser ohne Serverkonfiguration läuft. In der Beschreibung nannte er drei Einsatzbereiche: eine Plugin-Demo auf der Website, das Testen von Code mit verschiedenen WordPress- und PHP-Versionen sowie interaktive Kurse (Aufzeichnung). Laut der Playground-Dokumentation läuft das Projekt vollständig clientseitig in WebAssembly, ohne Backend, und die Umgebung wird über die Query API, die Blueprints API (eine JSON-Datei) oder die JavaScript API gesteuert.

#Wo man die Aufzeichnungen vom WordCamp Gliwice 2023 ansehen kann

Die Aufzeichnungen der Vorträge stehen auf der Veranstaltungsseite bei WordPress.tv. Die Liste umfasst 31 Videos, fast alle am 30. Mai 2023 veröffentlicht. Die Workshops (WP-CLI, Astro, Dependency Injection, TDD mit React, Core Web Vitals, Sicherheit, von Figma zu FSE, Serverwahl) und die Mastermind-Sessions wurden nicht aufgezeichnet, daher weiß man über sie nur, was in den Sessionbeschreibungen steht.

#Zusammenfassung

Das WordCamp Gliwice 2023 brachte an drei Tagen einen Contributor Day, zwei Vortragstage in mehreren Tracks, acht Workshops und ein Mastermind zusammen. Technisch am stärksten waren die Workshops zu Astro, WP-CLI und Dependency Injection sowie die Vorträge zu TTFB und Playground. Gut war, dass das Thema Headless zwei Perspektiven bekam, eine praktische im Workshop und eine skeptische auf der Bühne.

Wenn Ihr Unternehmen eine Migration zu Headless WordPress plant, die Core Web Vitals verbessern muss oder ein erfahrenes Entwicklungsteam sucht, sehen Sie sich unsere Leistungen als WordPress-Entwickler an.