Mentale Modelle für die WordPress-Entwicklung: Der komplette Leitfaden

Ein mentales Modell ist eine vereinfachte Erklärung dafür, wie etwas funktioniert. Es ist eine interne Repräsentation der externen Realität. In der Softwareentwicklung, und speziell in der WordPress-Entwicklung, helfen uns diese Modelle, Komplexität in handhabbare Stücke zu komprimieren. Sie ermöglichen es uns, bessere Websites zu bauen, saubereren Code zu schreiben und klügere Architekturentscheidungen zu treffen, ohne die gesamte Codebasis im Arbeitsgedächtnis halten zu müssen.

WordPress ist über 20 Jahre alt. Es trägt das Erbe von PHP 4, die Revolution der Custom Post Types, die Modernisierung der REST-API und den Paradigmenwechsel des Block-Editors (Gutenberg) in sich. Um sich in diesem weitläufigen Ökosystem effektiv zurechtzufinden, können Sie sich nicht darauf verlassen, Funktionen auswendig zu lernen. Sie benötigen robuste mentale Modelle.

Egal, ob Sie einen Plugin-Konflikt debuggen, Datenbankabfragen für einen hochfrequentierten WooCommerce-Shop optimieren oder zwischen Custom Post Types und Taxonomien für eine komplexe Datenstruktur entscheiden – mentale Modelle dienen als Ihr kognitiver Werkzeugkasten.

Dieser umfassende Leitfaden deckt die essenziellen mentalen Modelle ab, um ein erstklassiger WordPress-Ingenieur zu werden.

#Kern-mentale Modelle von WordPress

#1. Das Hook-System: ereignisgesteuerte Architektur

Im Kern ist WordPress ein ereignisgesteuertes System. Das Hook-System (Actions und Filters) ist der Mechanismus, der es ermöglicht, WordPress zu erweitern, ohne den Core-Code zu verändern.

Das Mentale Modell: Stellen Sie sich das Hook-System als einen Event-Bus oder eine Radioübertragung vor.

• Actions (do_action): Das sind Ereignisse, die stattfinden. “Hey, ich habe gerade einen Beitrag gespeichert!” oder “Ich bin kurz davor, den Footer zu rendern!”. Sie können sich auf diese Ereignisse “einschalten” und Ihren eigenen Code ausführen. Actions tun Dinge.
• Filters (apply_filters): Das sind Stationen zur Datenmodifikation. “Hier ist der Titel. Möchte ihn jemand ändern, bevor ich ihn anzeige?”. Sie fangen die Daten ab, modifizieren sie und müssen sie zurückgeben. Filters ändern Dinge.

Deep Dive: Die Reihenfolge ist entscheidend. Hooks feuern in einer bestimmten Reihenfolge während des Request-Lebenszyklus.

1. plugins_loaded
2. setup_theme
3. init
4. wp_loaded
5. template_redirect

Wenn Sie versuchen, auf den aktuellen Benutzer in plugins_loaded zuzugreifen, werden Sie scheitern, da die Benutzersession noch nicht initialisiert wurde. Ihr mentales Modell muss die Zeitdimension des Request-Lebenszyklus beinhalten.

// FALSCH: Der Versuch, vor dem Senden der Header umzuleiten, impliziert fehlendes Verständnis des Lebenszyklus
add_action('wp_footer', function() {
    if (is_page('restricted')) {
        wp_redirect('/login'); // Fatal Error: Headers already sent
    }
});

// RICHTIG: Früh genug einhaken, um Weiterleitungen zu handhaben
add_action('template_redirect', function() {
    if (is_page('restricted') && !is_user_logged_in()) {
        wp_redirect('/login');
        exit;
    }
});

Wenn Sie schnell sehen möchten, welche Callbacks an einen Hook gehängt sind und mit welchen Prioritäten, nutzen Sie diesen Leitfaden: List all hooked functions in WordPress.

Schlüsselprinzip: Ändern Sie niemals Core-Dateien. Ändern Sie niemals direkt Parent-Theme-Dateien. Verwenden Sie Hooks, um Ihre Logik zur richtigen Zeit und am richtigen Ort einzuschleusen.

#2. Die Template-Hierarchie: der Entscheidungsbaum

WordPress verwendet einen strikten Entscheidungsbaum, um zu bestimmen, welche Template-Datei für eine gegebene URL geladen werden soll. Dies ist kein Zufall; es ist eine vorhersagbare Kaskade von Spezifität.

Das Mentale Modell: Denken Sie an einen Wasserfall der Spezifität. WordPress stellt eine Reihe von Fragen, beginnend bei der spezifischsten bis zur allgemeinsten.

1. Ist dies ein Einzelbeitrag (Single Post)?

   • Gibt es eine single-{post_type}-{slug}.php? (z. B. single-product-blue-shirt.php)
   • Nein? Gibt es eine single-{post_type}.php? (z. B. single-product.php)
   • Nein? Gibt es eine single.php?
   • Nein? singular.php?
   • Nein? index.php.

2. Ist dies ein Kategorie-Archiv?

   • category-{slug}.php
   • category-{id}.php
   • category.php
   • archive.php
   • index.php

Praktische Anwendung: Wenn Sie debuggen, warum eine Seite auf eine bestimmte Weise aussieht, schauen Sie auf die Body-Klassen (z. B. single-format-standard) oder verwenden Sie ein Tool wie “Show Current Template”. Ihr mentales Modell sollte die URL sofort der wahrscheinlichen Datei auf der Festplatte zuordnen.

Fortgeschrittene Einsicht: Sie können diesen Entscheidungsbaum mit dem Filter template_include abfangen. Dies ermöglicht es Ihnen, Anfragen an komplett benutzerdefinierte Templates außerhalb der Standardhierarchie zu leiten, was die Funktionsweise vieler plugin-basierter Landing-Pages ist.

#3. Datenbank-Abstraktion: das objekt-relationale Modell (ORM)

WordPress hat sein eigenes ORM, auf das hauptsächlich über WP_Query und die Klasse $wpdb zugegriffen wird.

Das Mentale Modell: Fassen Sie kein SQL an. Denken Sie an die Datenbank als eine Blackbox, mit der Sie über High-Level-APIs interagieren. Rohes SQL zu schreiben ist eine Maßnahme für den “Notfall”.

• WP_Query: Der Standardweg, um Beiträge abzurufen. Er handhabt Sicherheit, Caching und komplexe Joins automatisch.
• get_posts(): Ein einfacherer Wrapper um WP_Query.
• update_post_meta() / get_post_meta(): Schlüssel-Wert-Speicher für spezifische Objekte.

Die EAV (Entity-Attribute-Value) Falle: WordPress verwendet ein EAV-Modell für Metadaten (wp_postmeta, wp_usermeta).

• Vorteile: Unendliche Flexibilität. Sie können jedem Objekt jedes Feld hinzufügen.
• Nachteile: Schreckliche Performance beim Filtern und Sortieren großer Datensätze.

Performance Mentales Modell:

• Abfrage nach ID = Schnell (Primärschlüssel).
• Abfrage nach Taxonomie = Schnell (Indizierte Tabellen).
• Abfrage nach Meta-Key = Langsam (Full Table Scans oder unoptimierte Joins).
• Abfrage nach Meta-Value = Extrem Langsam.

// SCHLECHT: Meta-Query auf einer hochfrequentierten Seite
$query = new WP_Query([
    'meta_key' => 'favorite_color',
    'meta_value' => 'blue'
]);

// GUT: Taxonomie-Query
$query = new WP_Query([
    'tax_query' => [
        [
            'taxonomy' => 'color',
            'field'    => 'slug',
            'terms'    => 'blue',
        ]
    ]
]);

#4. Der Loop: das Iterator-Muster

Der Loop ist der Motor, der Inhalte verarbeitet. Es ist ein Standard-Iterator-Muster.

Das Mentale Modell: Die globale Zustandsmaschine. Wenn Sie the_post() aufrufen, mutieren Sie den globalen Zustand. Das globale Objekt $post ändert sich zum aktuellen Element im Loop. Dies beeinflusst jede Funktion, die auf den “aktuellen Beitrag” angewiesen ist (wie the_title(), get_the_ID()).

if ( have_posts() ) {
    while ( have_posts() ) {
        the_post(); // <--- Diese Zeile ändert den globalen Zustand!
        
        // ... Inhält anzeigen ...
    }
    wp_reset_postdata(); // <--- KRITISCH: Globalen Zustand wiederherstellen
}

Häufiger Fallstrick: Das Vergessen von wp_reset_postdata() nach einer benutzerdefinierten Abfrage (sekundärer Loop). Dies lässt das globale $post-Objekt auf das letzte Element Ihrer benutzerdefinierten Abfrage zeigen, was die Hauptseitenlogik bricht (z. B. laden Kommentare für den falschen Beitrag, SEO-Plugins greifen die falschen Metadaten ab).

#Fortgeschrittene Architektur-Modelle

#5. Der Block-Editor (Gutenberg): das Komponenten-Zustandsmodell

Moderne WordPress-Entwicklung erfordert einen Wechsel von PHP-gerendertem HTML zu React-basierten Komponenten.

Das Mentale Modell: Serialisierung vs. Hydration.

• Edit-Kontext (React): Der Editor ist eine lebendige React-Anwendung. Der Zustand wird im Speicher verwaltet. Änderungen geschehen sofort.
• Speicher-Kontext (Serialisierung): Wenn Sie auf “Aktualisieren” klicken, wird der Zustand des Blocks in HTML-Kommentare serialisiert: <!-- wp:my-block {"color":"red"} /-->.
• Frontend (Statisches HTML): Der Browser empfängt das statische HTML. Es gibt kein React im Frontend, es sei denn, Sie hydrieren es spezifisch.

Hauptunterschied:

• PHP Shortcodes: Werden bei jedem Laden der Seite “on the fly” ausgeführt. Dynamisch, aber teuer.
• Blöcke: Werden einmal gerendert, wenn der Beitrag gespeichert wird. Statisch und schnell.

Der “Dynamische Block” Hybrid: Manchmal benötigen Sie dynamische Inhalte (wie “Neueste Beiträge”). In diesem Fall speichert der Block null Inhalt, und PHP rendert ihn on the fly. Dies bringt das PHP-Rendering-Modell zurück, verpackt es aber in die Block-UI.

#6. Sicherheit: das Pförtner-Modell

Sicherheit ist kein Feature; es ist eine Denkweise. In WordPress müssen Sie das Pförtner-Modell an drei spezifischen Kontrollpunkten anwenden.

1. Eingang (Das Tor): Validierung.

   • Stoppen Sie schlechte Daten an der Tür. Wenn Sie eine Ganzzahl erwarten, casten Sie sie zu (int). Wenn Sie eine E-Mail erwarten, verwenden Sie is_email().

2. Verarbeitung (Der Tresor): Bereinigung (Sanitization) & Autorisierung.

   • Bereinigung: Säubern Sie die Daten, bevor Sie sie in die Datenbank legen. sanitize_text_field(), sanitize_email().
   • Autorisierung (Capabilities): Hat dieser Benutzer die Schlüssel zu diesem Raum? current_user_can('edit_posts'). Nehmen Sie niemals an, nur weil ein Benutzer eingeloggt ist, sei er ein Admin.
   • Absicht (Nonces): Wollte der Benutzer dies wirklich tun? Nonces schützen vor CSRF (Cross-Site Request Forgery).

3. Ausgang (Das Fenster): Maskierung (Escaping).

   • Behandeln Sie Ihre Datenbank als potenziell verunreinigt (selbst wenn Sie die Eingabe bereinigt haben). Maskieren Sie immer bei der Ausgabe.
   • esc_html(), esc_attr(), esc_url(), wp_kses().

Die “Späte Maskierung” Regel: Maskieren Sie so spät wie möglich, idealerweise direkt innerhalb der echo-Anweisung.

#7. Performance: das Flaschenhals-Modell

Optimierung ist die Kunst, das engste Rohr zu finden.

Das Mentale Modell: Der Kritische Pfad. Was hindert den Benutzer daran, die Seite jetzt gerade zu sehen?

1. TTFB (Time to First Byte): Server-Verarbeitungszeit.

   • Flaschenhälse: PHP-Ausführung, Datenbankabfragen.
   • Lösung: Object Caching (Redis), Page Caching (Varnish/WP Rocket), PHP 8.x, Optimierte Datenbank.

2. FCP (First Contentful Paint): Renderzeit.

   • Flaschenhälse: Blockierendes CSS/JS, riesige Bilder, Webfonts.
   • Lösung: JS aufschieben (defer), kritisches CSS inlinen, Bilder optimieren (WebP/AVIF).

Das Transient / Object Cache Modell: Berechnen Sie nicht dasselbe zweimal.

• Transients: In der Datenbank gespeichert (oder im Object Cache, falls vorhanden). Gut für API-Antworten (z. B. Instagram-Feed).
• Object Cache (Redis/Memcached): Speicherbasierte Ablage. Essenziell für komplexe Abfragen auf hochfrequentierten Seiten.

// Teure Operation
$data = get_transient('my_expensive_data');

if ( false === $data ) {
    $data = calculate_expensive_thing();
    set_transient('my_expensive_data', $data, 12 * HOUR_IN_SECONDS);
}

return $data;

Vertiefen Sie die Caching-Architektur und die Beseitigung von Flaschenhälsen: Fortgeschrittenes WordPress-Caching 2026.

#8. Die REST-API: das entkoppelte Datenmodell

Die REST-API verwandelt WordPress von einem Website-Builder in eine Content Application Platform.

Das Mentale Modell: Headless Content Source. WordPress wird zu einer Datenbank mit einer JSON-Schnittstelle. Das Frontend kann alles sein: eine Next.js-App, eine mobile App oder ein intelligenter Kühlschrank.

• Endpunkte: URLs, die JSON zurückgeben (/wp-json/wp/v2/posts).
• Routen: Die Logik, die eine URL einer Funktion zuordnet.
• Controller: Die Klassen, die die Logik von Anfrage -> Verarbeitung -> Antwort handhaben.

Wichtige Erkenntnis: Wenn Sie für die REST-API bauen, verlieren Sie den Kontext der Standard-”Template-Hierarchie” und des “Loops”. Sie müssen explizit definieren, welche Daten offengelegt werden. Sicherheit (Authentifizierung) wird zustandslos (JWT, Application Passwords) statt Cookie-basiert. Die passende API-Architektur wählen? Lesen Sie: WordPress REST API vs. GraphQL 2026.

#Wo gehört was hin

#Custom Post Types vs. Taxonomien vs. Meta

Die erste Frage, die ich stelle: wird jemals jemand nach diesem Feld filtern?

Wenn ja, ist es fast sicher eine Taxonomie. Taxonomie-Abfragen treffen indizierte Join-Tabellen. Meta-Abfragen treffen wp_postmeta, was bei einer Site mit 200k Zeilen einen Table Scan und einen JOIN auf einer nicht indizierten meta_value-Spalte bedeutet. Ich habe einen Mittelständler aus Hamburg gesehen, der von 8 s auf 200 ms TTFB ging, nachdem “Stadt” und “Immobilientyp” von Meta in Taxonomien gewandert waren. Der Hoster (Mittwald) hatte nichts damit zu tun.

Ein einfacher Test:

• Substantiv mit eigener URL und Bearbeitungsmaske: Post Type. Immobilien, Veranstaltungen, Kurse.
• Wort, nach dem Leute filtern: Taxonomie. Stadt, Farbe, Baujahr, Marke.
• Zahl, die auf einer einzelnen Zeile lebt und nie in einer WHERE-Klausel auftaucht: Meta. Preis, Kilometerstand, Lat/Lng für einen einzelnen Map-Pin.

Die Falle: ACF lässt Meta kostenlos wirken. Ist es nicht. Jeder Meta-Key, gegen den Sie abfragen, ist eine zukünftige Performance-Regression. Caspar Hübinger hat das auf dem WordPress Frankfurt Meetup mehrfach betont, und Heise.de hat es 2022 in einer Performance-Analyse für Shop-Systeme bestätigt.

#Plugin vs. Theme

Wo sollte der Code hin?

Das Mentale Modell: Inhalt vs. Präsentation.

• Theme: Steuert, wie Dinge aussehen. Wenn ich das Theme wechsle, ändert sich der visuelle Stil, aber meine Daten sollten bleiben.
• Plugin: Steuert, wie Dinge funktionieren. Wenn ich das Theme wechsle, sollten meine Custom Post Types, Shortcodes und Logik weiterhin verfügbar sein (auch wenn sie hässlich aussehen).

Goldene Regel: Wenn der Benutzer seine Daten (Inhalt, Funktionalität) verliert, wenn er das Theme wechselt, haben Sie den Code an die falsche Stelle gesetzt. Erstellen Sie ein “Site Functionality Plugin” für Custom Post Types und Kernlogik. Thomas Maier predigt dieses Muster seit Jahren auf den deutschen WordCamps, und es deckt sich mit den BSI-Mindeststandards für strukturelle Trennung von Anwendungslogik und Darstellung.

#Multisite: das Netzwerk-Modell

Multisite fügt dem mentalen Modell eine neue Ebene hinzu.

Das Mentale Modell: Mehrfamilienhaus vs. Einfamilienhäuser.

• Einzelinstallation: Ein Haus. Sie kontrollieren alles.
• Multisite: Ein Mehrfamilienhaus.
  • Super Admin: Der Hausverwalter. Kontrolliert die Struktur, verfügbare Plugins (Strom/Wasser) und erstellt neue Seiten.
  • Site Admin: Der Mieter. Kann seine Wohnung dekorieren (Theme-Optionen) und erlaubte Geräte (Plugins) aktivieren, aber keine Wände einreißen (Themes/Plugins installieren).

Datentrennung: Jede Seite hat ihre eigenen Tabellen (wp_2_posts, wp_3_posts), aber sie teilen sich die wp_users Tabelle. Das bedeutet, ein Benutzer existiert im Netzwerk, muss aber einer Seite hinzugefügt werden, um dort eine Rolle zu haben.

#WPCS-Praktiken: Sicherheit, Daten, REST und Abfragen

• Validierung, Sanitization, Escaping:

check_admin_referer( 'my_action', 'my_nonce' );
if ( ! current_user_can( 'edit_post', $post_id ) ) { return; }
$raw  = $_POST['title'] ?? '';
$title = sanitize_text_field( wp_unslash( $raw ) );
update_post_meta( $post_id, 'title', $title );
echo '<h2>' . esc_html( $title ) . '</h2>';

• Abfragen und Performance:

$q = new WP_Query( array(
  'post_type' => 'product',
  'posts_per_page' => 10,
  'no_found_rows' => true,
  'update_post_meta_cache' => false,
  'update_post_term_cache' => false,
) );

• Sicheres SQL:

global $wpdb;
$id  = 123;
$row = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM {$wpdb->posts} WHERE ID = %d", $id ) );

• REST-API Berechtigungen:

register_rest_route( 'my/v1', '/items', array(
  'methods'  => 'POST',
  'callback' => 'my_items_post',
  'permission_callback' => function () { return current_user_can( 'edit_posts' ); },
) );

• Gutenberg: Block-Registrierung und Serialisierung:

wp.blocks.registerBlockType('my/block', {
  attributes: { rating: { type: 'number', default: 0 } },
  edit: (props) => wp.element.createElement('div', null, props.attributes.rating),
  save: (props) => wp.element.createElement('div', null, props.attributes.rating),
});

#Die Debugging-Reihenfolge: Theme, Plugin, Core, Hosting

Wenn eine WordPress-Seite auf eine Weise kaputt geht, die nicht offensichtlich selbst verschuldet ist, lautet die Frage nie “was ist falsch”, sondern “wo schaue ich zuerst hin”. Die Reihenfolge zählt, weil sie die Kosten eines Fehlversuchs umkehrt.

Wechseln Sie zu einem Default-Theme. Twenty Twenty-Four, kein Child. Neunzig Prozent der “die Seite ist kaputt”-Tickets lösen sich hier auf, und die verbleibenden zehn Prozent haben jetzt einen viel kleineren Suchraum. Wenn der Bug den Theme-Wechsel überlebt, deaktivieren Sie Plugins in Hälften. Nicht eines nach dem anderen. Hälften. Bei 40 Plugins findet das den Übeltäter in sechs Toggles statt in vierzig.

Erst danach schauen Sie auf Core oder Hosting. Ich habe deutsche Senior-Entwickler gesehen, die einen halben Tag damit verbracht haben, WordPress-Core für etwas verantwortlich zu machen, was sich als Yoast und Rank Math herausstellte, die beide Schema für denselben Beitrag registrierten. Zwei aktive SEO-Plugins gleichzeitig sind der häufigste “Core-Bug”, der kein Core-Bug ist.

Ein paar Fehler-Muster, die ich in der DACH-Region wiederholt sehe:

Ein Junior-Entwickler liest “ich muss alte URLs umleiten” und installiert Redirection. Die Seite hat bereits 3000 Redirects in der DB. Was gebraucht wurde, waren vier Zeilen template_redirect und ein Regex, in der functions.php eines Site-Functionality-Plugins. Auf Raidboxes oder IONOS hätte ein Eintrag direkt im Hoster-Panel gereicht.

Ein Generalist deaktiviert wp-cron, weil er gelesen hat, dass es die Seite verlangsamt. Er vergisst, einen echten System-Cron-Job einzurichten, der wp-cron.php anspricht. Zwei Wochen später werden geplante Beiträge nicht mehr veröffentlicht, Transients laufen nie ab, WooCommerce Abandoned-Cart-Mails verstummen, und das Team weiß nicht warum, obwohl Mittwald oder ähnliche deutsche Hoster Cron-Jobs im Panel direkt anbieten.

Eine Agentur fügt Redis hinzu, um “die Performance zu fixen”, ohne jemals Query Monitor geöffnet zu haben. Redis cached, was bereits schnell war. Das eigentliche Problem ist eine meta_query auf wp_postmeta, die 47 Mal pro Request von einem fehlkonfigurierten Related-Posts-Widget läuft. Das Cachen der langsamen Abfrage bedeutet nur, dass der Cache-Miss langsam ist. Profilen Sie, bevor Sie cachen.

Das mentale Modell unter all dem: WordPress ist standardmäßig schnell. Wenn es langsam ist, ist etwas Spezifisches kaputt, und ein generisches Heilmittel wird es nicht finden.

#Empfohlene Artikel

• Fortgeschrittenes WordPress-Caching 2026
• Migration und Multisite: fortgeschrittenes Management
• Medienverwaltung in WordPress: moderner Workflow
• Headless vs. klassisch: Architektur-Guide

#Was Erfahrung wirklich kauft

Der Unterschied zwischen einem fünfjährigen WordPress-Entwickler und einem fünfzehnjährigen liegt nicht in mehr auswendig gelernten Funktionen. Es ist eine kürzere Liste von Fragen, die gestellt werden, bevor Code angefasst wird.

Wenn etwas kaputt geht, lautet die erfahrene Antwort “Theme, Plugin, Core, Hosting, in dieser Reihenfolge”, bevor der Editor überhaupt offen ist. Wenn eine Seite langsam ist, lautet sie “Query Monitor öffnen, nach Zeit sortieren, nach meta_query oder Autoload-Bloat suchen”, bevor irgendjemand das Wort Redis sagt. Wenn ein Kunde aus dem Mittelstand ein neues Feld will, lautet sie “wird jemand danach filtern”, bevor irgendjemand ACF anfasst.

Das Hooks-System, die Template-Hierarchie, der Loop, das Pförtner-Modell für Sicherheit nach DSGVO Art. 32, die EAV-Steuer auf Meta-Abfragen, die Serialisierungslücke zwischen Gutenberg und dem Frontend. Nichts davon ist clever. Es ist einfach die tatsächliche Form von WordPress, und Sie kämpfen dagegen oder Sie nutzen es. Zwei Zeilen in functions.php schlagen ein Plugin an den meisten Tagen. Eine Taxonomie schlägt einen Meta-Key auf jeder Seite, die über 10k Beiträge wächst. template_redirect schlägt wp_footer für alles, was Header involviert.

Das Erkennungsmerkmal eines Junior-Entwicklers ist, jedes Problem durch Hinzufügen von etwas zu lösen: ein Plugin, eine Cache-Schicht, einen Wrapper. Das Erkennungsmerkmal eines Seniors ist, etwas zu entfernen oder es dorthin zu verschieben, wo die Plattform es ohnehin haben wollte. Lesen Sie Core. Lesen Sie, was WP_Query tatsächlich in wp-includes/class-wp-query.php tut. Sobald Sie den Loop sich im Quellcode entrollen sehen, sind Sie auf dem Frontend nicht mehr überrascht.

#Quellen und weiterführende Lektüre

• Hooks-Dokumentation
• Template-Hierarchie
• The Loop
• REST-API
• Block-Editor (Gutenberg)
• WordPress Coding Standards
• Sicherheit: Validierung, Sanitization, Escaping
• Multisite: Netzwerk erstellen