Drupal Entwickler finden: Die Nadel im Heuhaufen?

Drupal ist mächtig. Es ist das System für komplexe Enterprise-Lösungen, Regierungsseiten und hochfrequentierte Portale. Aber genau diese Macht kommt mit einer steilen Lernkurve. Einen Entwickler zu finden, der “ein bisschen PHP kann”, reicht für Drupal oft nicht aus.

Wenn du vor der Herausforderung stehst, einen Experten für dein Projekt zu suchen, hilft dir dieser Guide, die Spreu vom Weizen zu trennen.

Warum ist Drupal so speziell?

Anders als bei WordPress, wo man oft mit gekauften Themes und Plugins “zusammenklickt”, erfordert Drupal tiefes technisches Verständnis.

Ein echter Drupal-Experte beherrscht:

• Modernes PHP & OOP: Drupal basiert auf Symfony. Objektorientierung ist Pflicht.
• Tooling: Composer für das Dependency Management und Drush für die Kommandozeile sind Standard.
• Configuration Management: Wer Änderungen direkt auf dem Live-Server macht (“in der Datenbank klickt”), hat Drupal nicht verstanden. Änderungen gehören in Code (YAML-Dateien) und werden deployt.
• Caching & Performance: Drupal hat ein komplexes Caching-System (Cache Tags, Contexts). Wer das nicht versteht, baut langsame Seiten.

Freelancer vs. Agentur

Die ewige Frage. Beide haben ihre Berechtigung.

Der Freelancer

• Vorteile: Direkter Draht zum Experten (kein Stille-Post-Spiel über Projektmanager), oft kosteneffizienter, hohe Spezialisierung.
• Nachteile: Begrenzte Kapazität, Ausfallrisiko bei Krankheit.
• Ideal für: Integration in bestehende Teams, spezifische Modul-Entwicklung, Migrationen, Performance-Optimierung oder Wartung.

Die Agentur

• Vorteile: Skalierbarkeit, Full-Service (Design + Dev + SEO), Ausfallsicherheit.
• Nachteile: Höhere Stundensätze, oft längere Kommunikationswege, Overhead.
• Ideal für: Komplette Relaunches, große Projekte die Design und Strategie benötigen.

Warnsignale (Red Flags)

Sei vorsichtig, wenn ein Bewerber:

1. FTP benutzt: Wer heute noch Dateien per FTP hochlädt statt Git und CI/CD Pipelines zu nutzen, ist in der Zeit stehen geblieben.
2. Core hackt: “Ich habe da schnell was im Core-Modul geändert” ist ein absolutes No-Go. Updates werden dadurch unmöglich.
3. Kein Composer nutzt: Ein Drupal-Projekt ohne composer.json ist heute kaum noch wartbar.
4. Alles “custom” baut: Ein guter Drupal-Dev prüft erst, ob es ein Contrib-Modul gibt oder ob man es mit Core-Mitteln (Views, Layout Builder) lösen kann, bevor er Code schreibt.

Der “Fiese” Experten-Test: Fragen für Lead Developer

Willst du sichergehen, dass du einen echten Senior vor dir hast? Stell diese Fragen. Wenn der Kandidat ins Schwitzen kommt oder ausweicht: Vorsicht.

1. “Erkläre mir den Unterschied zwischen Cache Tags und Cache Contexts.”

• Die richtige Antwort: Cache Tags invalidieren Content (z.B. “node:5” ändert sich -> alle Caches mit diesem Tag werden gelöscht). Cache Contexts variieren Content (z.B. “user.roles” -> Admin sieht etwas anderes als Gast).
• Red Flag: “Ich lösche einfach den Cache, wenn was nicht geht.”

2. “Wie verhinderst du, dass Dependency Injection im Constructor zu riesigen Klassen führt?”

• Die richtige Antwort: Durch Nutzung von Services, Traits oder das Auslagern von Logik in kleinere, spezialisierte Services (Single Responsibility Principle).
• Red Flag: “Ich nutze meistens \Drupal::service(), das geht schneller.” (Das ist ein Anti-Pattern in Klassen!)

3. “Wir müssen 10.000 Nodes laden und verarbeiten. Wie machst du das performant?”

• Die richtige Antwort: Niemals Node::loadMultiple() für alle auf einmal nutzen (Memory Limit!). Stattdessen: EntityQuery nutzen, nur IDs laden, und dann in Chunks (Häppchen) verarbeiten oder – noch besser – die Queue API und Batch API nutzen.
• Red Flag: “Ich mache eine foreach Schleife und lade die Nodes.”

4. “Was passiert, wenn ich im Live-System einen View ändere und dann drush cim ausführe?”

• Die richtige Antwort: Die Änderung auf dem Live-System wird gnadenlos überschrieben. Configuration Management (drush cim) setzt den Zustand des Codes durch. Änderungen gehören IMMER erst in den Code (Export im Dev), dann Deploy.
• Red Flag: “Dann merge ich das irgendwie…” oder Unverständnis darüber, dass Code > Datenbank-Config ist.

5. “In einem Twig-Template: Wann nutzt du {{ content.field_name }} und wann {{ node.field_name.value }}?”

• Die richtige Antwort: Immer {{ content.field_name }} (Render Array)! Das durchläuft das Theming-System, Field-Formatter und Cache-Bubbling. {{ node.field_name.value }} gibt den Rohwert aus – ohne Caching-Metadaten und ohne Sicherheits-Filterung.
• Red Flag: “Ich nehme immer .value, das ist einfacher zu stylen.” (Sicherheitsrisiko & Cache-Probleme!)

6. “Ein Kunde will, dass der Node-Titel HTML enthalten kann (z.B. <i>). Wie setzt du das um?”

• Die richtige Antwort: Niemals einfach “Raw HTML” erlauben (XSS Gefahr!). Man nutzt ein Text-Format mit eingeschränktem HTML-Filter oder ein spezielles Modul, das Sanitization sicherstellt.
• Red Flag: “Ich gebe den Titel im Template mit |raw aus.” (Todsünde! Öffnet Tür und Tor für XSS-Attacken.)

7. “Wann würdest du eine Custom Entity erstellen statt einen Content Type (Node) zu nutzen?”

• Die richtige Antwort: Wenn die Daten kein “Content” im redaktionellen Sinne sind (keine URL, kein SEO, keine Revisionen nötig), sondern eher interne Datenstrukturen oder Business-Objekte, die sehr performant sein müssen.
• Red Flag: “Ich mache alles mit Nodes.” oder “Custom Entities sind zu kompliziert.”

8. “Ein Contrib-Modul hat einen Bug. Wie fixen wir das?”

• Die richtige Antwort: Issue auf Drupal.org suchen/erstellen, Patch erstellen, und diesen via composer.json (cweagans/composer-patches) einbinden. Niemals direkt im vendor oder modules/contrib Ordner ändern.
• Red Flag: “Ich ändere die Datei auf dem Server und mache mir eine Notiz.”

9. “Was sind Lazy Builders und wann brauchst du sie?”

• Die richtige Antwort: Für hoch-dynamische Inhalte (z.B. “Hallo User X”) in einer sonst stark gecachten Seite. Lazy Builders (oder BigPipe) rendern diesen Teil erst ganz zum Schluss, damit der Rest der Seite aus dem Cache kommen kann.
• Red Flag: “Ich schalte das Caching für diesen Block einfach aus.” (Zerstört oft die Performance der ganzen Seite.)

10. “Du bekommst eine LogicException: The controller result claims to be providing relevant cacheability metadata, but leaked metadata was detected. Was ist passiert?”

• Die richtige Antwort: Das ist der Endgegner. Es bedeutet “Early Rendering”. Du hast wahrscheinlich render() oder den Renderer-Service aufgerufen, bevor Drupal bereit war, die Cache-Metadaten (Tags/Contexts) einzusammeln (“bubbling”). Dadurch würden diese Metadaten verloren gehen und die Seite falsch gecacht werden.
• Lösung: Gib das Render Array zurück, statt es selbst zu rendern! Wenn du zwingend einen String brauchst (z.B. für eine JSON Response), musst du executeInRenderContext nutzen, um die Metadaten manuell einzufangen und an die Response anzuhängen.
• Red Flag: “Ich google den Fehler und kopiere den ersten StackOverflow-Fix.” (Ohne zu verstehen, dass man gerade das Caching-System aushebelt.)

Wo findet man sie?

• Drupal.org: Schau dir Profile an. Haben sie Commit-Credits? Pflegen sie Module? Hier ist zum Beispiel mein Profil auf Drupal.org.
• Drupal User Groups: Lokale Meetups (oder digitale) sind Goldgruben für Kontakte.
• Spezialisierte Netzwerke: LinkedIn ist gut, aber oft voller Recruiter-Spam. Persönliche Empfehlungen aus dem Netzwerk sind oft am wertvollsten.

Fazit

Die Suche nach einem Drupal-Entwickler ist eine Investition. Ein erfahrener Entwickler mag pro Stunde mehr kosten, löst Probleme aber oft in einem Bruchteil der Zeit und baut Lösungen, die auch in 3 Jahren noch stabil laufen. Achte auf Modernität im Workflow (Git, Composer, Drush) und ein Verständnis für die Drupal-Architektur.

Viel Erfolg bei der Suche!

Noch unsicher? Wenn du Unterstützung bei deinem Drupal-Projekt brauchst oder eine zweite Meinung suchst, ruf mich einfach an: 040 37420859. Ich helfe gerne weiter.