Ich habe ein WordPress-Plugin gebaut, das niemand bestellt hat
Ich habe während eines jahrelangen Kundenprojekts eine Recruitee-Integration für Bricks Builder gebaut. Jetzt, wo die Zusammenarbeit vorbei ist, ist es Open Source. Hier ist die Geschichte.
Kemal Esensoy·aktualisiert am February 23, 2026
Kennt ihr das, wenn man etwas Individuelles für einen Kunden baut, alles über ein Jahr hinweg bestens läuft, und das Projekt dann einfach ein natürliches Ende findet?
Genau das ist hier passiert.
Ich hatte über ein Jahr einen Kunden. Gute Zusammenarbeit, alles lief super. Teil des Projekts war ein Custom WordPress-Plugin, das die Bricks Builder Website mit Recruitee - der Recruiting-Plattform des Kunden - verbunden hat. Das Plugin lief die ganze Zeit einwandfrei. Dann haben wir aufgehört zusammenzuarbeiten. Normaler Agenturalltag, nichts Dramatisches.
Jetzt liegt dieses Plugin also in einem Repo rum und macht nichts. Und ich dachte mir - vielleicht hat da draußen jemand genau das gleiche Problem, das ich gelöst habe. Unwahrscheinlich? Wahrscheinlich. Aber hier sind wir.
Das Problem
Die Anforderung des Kunden klang erstmal simpel: Zeig die Stellenangebote von Recruitee auf der WordPress-Website, die mit Bricks Builder gebaut ist.
"Bette einfach das Recruitee-Widget ein," würdet ihr vielleicht sagen. Klar. Nur:
- Recruitees Embed ist ein iframe. Google indexiert keine iframe-Inhalte. Kein SEO. Kein organischer Traffic auf die Stellenseiten. Für ein Unternehmen, das Talente über die Suche gewinnen will, ist das ein Dealbreaker.
- Die Stellenseiten müssen aussehen wie der Rest der Website. Nicht wie ein Fremdkörper, der draufgeklatscht wurde.
- Bewerbungen müssen automatisch zurück zu Recruitee gehen. Das HR-Team lebt in Recruitee. Die wollen nicht in WordPress nach Bewerbungen suchen.
Die eigentliche Aufgabe war also: Mach die Jobs zu nativem WordPress-Content, halte sie mit Recruitee synchron, und mach den Bewerbungsprozess nahtlos - und das alles SEO-freundlich und indexierbar.
Kein Problem, oder?
Was ich gebaut habe
Das Plugin macht zwei Dinge, und die macht es gut:
Schritt 1: Jobs von Recruitee ziehen
Ein Cron-Job (konfigurierbar - stündlich, täglich, wie auch immer) ruft die Recruitee API ab, zieht alle veröffentlichten Stellenangebote und synchronisiert sie als Custom job Post Type in WordPress. Jeder Job bekommt:
- Titel, Beschreibung, Anforderungen
- Standortdaten (Stadt, Bundesland, Land)
- Remote-Status
- Abteilung/Position als Taxonomy
- Die Recruitee Job-ID als ACF Custom Field
Neue Jobs werden erstellt. Aktualisierte Jobs werden aktualisiert. Geschlossene Jobs werden entfernt. Vollautomatisch.
Die Synchronisation cached auch die Abteilungen von Recruitee und mappt sie auf WordPress-Taxonomien - Filterung im Frontend gibt's also gratis dazu.
Schritt 2: Bewerbungen an Recruitee pushen
Das war der knifflige Teil.
Ich habe ein Bricks Builder Template für die Job-Detailseite erstellt, mit einem eingebauten Bewerbungsformular. Wenn jemand das Formular ausfüllt - Name, E-Mail, Telefon, Anschreiben, Lebenslauf-Upload - fängt das Plugin die Bricks-Formularübermittlung ab und pusht sie als neuen Kandidaten an die Recruitee API.
Der Datei-Upload war besonders spaßig rauszufinden. PDFs und Dokumente aus einem Bricks-Formular-Upload nehmen, per URL zugänglich machen, und dann diese URL an Recruitees Attachment-Endpunkt pushen... sagen wir mal so, die Recruitee API-Dokumentation war zu dem Thema nicht gerade ausführlich.
Aber es funktioniert. Der Kandidat taucht in Recruitee auf, mit angehängtem Lebenslauf, verknüpft mit dem richtigen Job. HR sieht es sofort in ihrer Pipeline.
Die Architektur
Für alle, die sich für die Code-Struktur interessieren:
src/
├── API/RecruiteeAPI.php # Gesamte Recruitee API-Kommunikation
├── Admin/AdminSettings.php # WordPress Einstellungsseite
├── Application/CandidateApplication.php # Bewerbungslogik
├── Cron/CronManager.php # Geplante Sync-Verwaltung
├── Integration/BricksFormIntegration.php # Bricks Form Hook
├── Logging/ActionLogger.php # Action-Logging-System
└── Sync/JobSynchronizer.php # Job-Sync-Engine
PSR-4 Autoloading via Composer. Saubere Trennung der Zuständigkeiten. Die API-Schicht behandelt Retries (bis zu 3 Versuche mit Backoff). Es gibt ein eingebautes Logging-System, damit man im WordPress Admin genau sehen kann, was bei Syncs und Bewerbungen passiert.
Das Admin-Panel lässt alles konfigurieren:
- Recruitee API-Key, Company-ID, Subdomain
- Cron-Frequenz
- Formularfeld-Mappings (damit es mit eurem spezifischen Bricks-Formular funktioniert)
- Erfolgs-Weiterleitungs-URL
Keine hartcodierten Werte. Alles konfigurierbar.
Das AI-Cleanup
Jetzt mal ehrlich: als ich das für den Kunden gebaut habe, war vieles hardcoded. API-Keys im Code, Feld-IDs fest verdrahtet - das Übliche, wenn man schnell für einen bestimmten Anwendungsfall baut.
Als ich mich entschieden habe, es als Open Source zu veröffentlichen, habe ich Claude die hardcodierten Werte aufräumen lassen, ordentliche Kommentare zur Funktionalität hinzufügen lassen und alles über das Admin-Einstellungs-Panel konfigurierbar gemacht.
Ist es perfekt? Nein. Ist es über ein Jahr bei einem echten Kunden im Produktiveinsatz getestet? Ja.
Warum Open Source?
Einfach: Ich werde das nicht als kommerzielles Produkt pflegen. Wir arbeiten nicht mehr mit dem Kunden zusammen, und ich habe kein weiteres Recruitee + Bricks Projekt in Aussicht.
Aber irgendwo da draußen rauft sich wahrscheinlich ein Entwickler oder eine Agentur die Haare, weil sie genau das versuchen. Recruitee-Jobs in Bricks zu bekommen, ohne iframes. Bewerbungen automatisch zurück zu Recruitee zu leiten. Alles SEO-freundlich zu halten.
Falls das auf euch zutrifft - hier, bitte. MIT-Lizenz. Macht damit, was ihr wollt.
So nutzt ihr es
- In euer WordPress-Plugin-Verzeichnis legen
composer installausführen- Plugin aktivieren
- Im Admin-Menü auf Bricks Recruitee gehen
- Recruitee API-Key, Company-ID und Subdomain eingeben
- Die enthaltenen ACF-Felder und das Bricks-Template importieren (JSON-Dateien im Repo enthalten)
- Formularfeld-Mappings konfigurieren
- "Sync Jobs Now" klicken oder den Cron aktivieren
Das war's. Eure Recruitee-Jobs sind jetzt native WordPress-Beiträge mit vollem SEO-Saft.
Das Repo
Ihr findet es auf GitHub: Wunderlandmedia/bricks-recruitee
MIT-Lizenz. Nehmt es, forkt es, verbessert es. Falls ihr es tatsächlich nutzt, würde ich mich freuen davon zu hören. Aber kein Druck - es ist ein Long Shot, und das weiß ich.
Manchmal baut man Dinge, die nur einem Kunden helfen. Und manchmal, wenn man Glück hat, helfen sie noch einem mehr.
Über den Autor
Kemal Esensoy
Kemal Esensoy, Gründer von Wunderlandmedia, begann seine Karriere als freiberuflicher Webentwickler und Designer. Er führte Web-Design-Kurse mit über 3.000 Studenten durch. Heute leitet er eine preisgekrönte Full-Stack-Agentur, die sich auf Webentwicklung, SEO und digitales Marketing spezialisiert hat.