Eigene WordPress-Plugins statt 40 Erweiterungen

Die typische Übernahme beginnt mit einem Screenshot der Plugin-Liste. Zweiunddreißig aktiv, acht inaktiv, drei „muessen wir noch testen“. SEO, Slider, Pop-up, Mega-Menü, zwei Formularbauer, ein Page-Builder, ein Caching-Plugin, das ein anderes Caching-Plugin bekämpft, Cookie-Tool, Chat-Widget, Social-Share, Backup, Migration, „Coming Soon“, ein gelbes Warn-Icon weil die PHP-Version nicht mehr passt.

Dann die Frage: Könnt ihr das schnell hübsch machen? Die ehrliche Antwort: Zuerst müssen wir zählen, was hier überhaupt noch WordPress ist. Oft ist es ein Stapel fremder Codebasen, die sich zur Laufzeit begrüßen. Wir sitzen in Gampaha, sprechen Deutsch, liefern Festpreis. Und wir bauen eigene Plugins. Das ist kein Marketing-Satz. Es ist eine technische Option, die wir nutzen, wenn sie billiger und sicherer ist als noch ein Marktplatz-Download.

Was folgt, ist kein Ranking-Versprechen und keine Plugin-Religion. Es ist die Entscheidungslogik, mit der wir Instanzen retten — oder bewusst durch hartes HTML und PHP ersetzen.

Was ein Plugin wirklich ist

Ein Plugin ist fremder PHP-Code in Ihrem Admin, mit Rechten auf Datenbank, Dateisystem und oft auf das Frontend. Es lädt, sobald WordPress lädt, außer es ist sauber geschrieben und hängt nur an gezielten Hooks. Viele sind das nicht. Viele hängen CSS und JavaScript auf jeder URL ein, inklusive Impressum.

Der Marktplatz ist bequem. Bewertungen, Screenshots, „100.000 aktive Installationen“. Das sagt nichts über die Qualität Ihres konkreten Stacks. Es sagt, dass viele Leute denselben Shortcut genommen haben. Shortcuts stapeln sich. Irgendwann ist die Seite das Shortcut-Archiv.

Core, Theme, Plugin — drei Haftungsschichten

WordPress-Core wird von vielen Augen gelesen. Themes und Plugins nicht in gleichem Maß. Ein Custom Theme, das nur Templates und etwas CSS enthält, ist überschaubar. Ein Plugin, das Bestellungen anlegt, Nutzerrollen ändert oder Zahlungen anfasst, ist Produktivcode. Den sollten Sie wie Produktivcode behandeln: Versionierung, Changelog, jemand der ihn im Ernstfall liest.

Wir versionieren eigene Plugins in Git. Marktplatz-Plugins versioniert der Autor — oder niemand mehr, seit 2019. Das ist der Unterschied, der in Audits zählt.

Marktplatz oder eigener Code

Nicht jedes Problem verdient ein Custom Plugin. Ein Kontaktformular mit Dateiupload und Double-Opt-in muss nicht neu erfunden werden, wenn ein schlankes, gepflegtes Plugin das abdeckt und keine Tracker mitbringt. Ein Slider für drei Bilder schon eher: Das ist HTML und CSS. Dafür ein 2-MB-Plugin zu laden, ist Nachlässigkeit.

Die Tabelle ist eine Orientierung, kein Orakel. Im Briefing zählen wir vorhandene Plugins, werfen die ohne Zweck raus und schreiben auf, was bleibt. Was bleibt, bekommt einen Grund. Ohne Grund fliegt es. Das klingt hart. Es ist günstiger als ein Compromised Admin im dritten Jahr.

Vierzig Plugins bedeuten vierzig Update-Kalender, vierzig Autoren, vierzig Stellen, an denen PHP-Notices entstehen können. Das ist kein Ökosystem. Das ist ein Terminkalender, den niemand besitzt.

Warum vierzig Plugins Sites umbringen

Nicht jedes Plugin ist bösartig. Die Summe ist das Problem. Autoload in der Datenbank wächst. Transients bleiben liegen. Crons stapeln sich. Zwei Plugins schreiben dieselbe Option. Ein drittes hängt jQuery.migrate. Das Frontend lädt Schriften dreimal. Der First Contentful Paint wandert in den Keller. Redakteure warten auf den Editor. Irgendwer installiert „just for testing“ ein Backup-Plugin, das das Uploads-Verzeichnis nach einem US-Bucket schiebt.

Sicherheit skaliert schlecht mit der Anzahl der Maintainer. Eine Lücke in einem obskuren Share-Button reicht. Angreifer scannen nach bekannten Plugin-Slugs, nicht nach Ihrer Marke. Je bekannter das Plugin, desto interessanter das Ziel — außer der Autor patched schnell. Viele tun das. Manche nicht. Manche verkaufen das Plugin, die Käufer pflegen das Repo nicht.

Editor, Frontend, Cron — drei Schauplätze

Im Admin merken Redakteure die Last zuerst: langsame Mediathek, Block-Editor, der spuckt, merkwürdige Metaboxen. Im Frontend merken Besucher die Last: Layout-Shift, Cookie-Layer plus Chat plus Video-Embeds ohne Consent. Im Hintergrund merken Sie es, wenn das Hosting CPU-Limits zieht oder die Datensicherung 8 GB wiegt, weil Revisionen und Logs nie rotiert wurden.

Wir messen das, bevor wir „mal schnell das Theme tauschen“. Theme-Tausch bei Plugin-Zoo verschiebt das Problem in ein anderes Kleid. Wer Tempo will, liest auch den Artikel zur langsamen WordPress-Site unter WordPress langsam — und räumt zuerst auf.

Der Page-Builder als heimliches Betriebssystem

Builder speichern Layouts als Shortcodes oder JSON in der Datenbank. Die Inhalte gehören dann dem Builder, nicht Ihnen. Ein Ausstieg ist eine Migration, kein Häkchen. Wir setzen Gutenberg-Blöcke oder Theme-Templates, wo es reicht. Builder nur, wenn das Redaktionsteam das ausdrücklich braucht und die Konsequenzen kennt. Kennen muss es vor dem Vertrag, nicht nach dem Relaunch.

Sicherheit, die nicht auf dem Plugin-Marktplatz endet

Eigenes Plugin heißt nicht automatisch sicher. Es heißt: weniger unbekannte Oberfläche, Code den wir lesen, Rechte die wir selbst setzen. Wir schreiben gegen WordPress-APIs, nicht gegen Copy-Paste aus einem Forum von 2014. Nonces, Capabilities, prepared Statements, Escaping im Output, keine Secrets in der Codebasis.

Marktplatz-Plugins prüfen wir vor der Aktivierung: letzte Aktualisierung, PHP-Kompatibilität, Support-Forum (nicht die Sterne, die Threads), ob das Plugin remote phone-home macht, ob es Fonts oder Tracker lädt, ob es Dateien nach wp-content schreibt, die der Webserver ausführen darf.

Admin-Zugänge härten wir unabhängig vom Plugin-Set: wenig Administratoren, 2FA wo tragbar, XML-RPC zu wenn unnötig, Prefix und Dateirechte nach Hosting-Möglichkeit. Kein „Security-Plugin“ als Ersatz für Updates. Security-Plugins, die 15 Scanner-Cronjobs starten, sind oft Teil der Last, die sie heilen sollen.

Daten und Drittland

Formulare, die an US-SaaS gehen, Newsletter-Plugins mit Default-Tracking, Chat-Widgets vor Einwilligung: Das ist Datenschutz, nicht Geschmack. Wir sitzen in Sri Lanka. Kontaktanfragen zur Bearbeitung verlassen die EU. Das steht in der Datenschutzerklärung, nicht in einer Fußnote. Für Ihre WordPress-Site empfehlen wir Hosting in der EU und Plugins, die nicht nebenbei Profile nach Übersee schieben. Wer das ignoriert, hat später den schlechteren Stand — unabhängig davon, ob der Code elegant ist.

Updates: der unglamouröse Teil

Ein Custom Plugin, das wir schreiben, bekommt einen Update-Pfad. Wir sagen, welche WordPress- und PHP-Versionen wir testen. Wir sagen, was passiert, wenn Core eine API ändert. Marktplatz-Plugins bekommen Updates vom Autor. Ihre Pflicht ist, sie einzuspielen — auf Staging, nicht live am Freitagnachmittag vor Feiertagen.

Major-Updates von WooCommerce oder Core sind Projekte, keine Klicks. Changelog lesen, Extensions prüfen, Backup, Staging, dann Produktion. Wer das nie macht, kauft irgendwann eine Neuinstallation. Das ist teurer als zwölf ruhige Update-Stunden im Jahr.

Verlassene Plugins fliegen. „Tut noch“ ist kein Argument, wenn der letzte Tag 2018 ist. Wir ersetzen oder schreiben den Bedarf nach. Fünfzig Zeilen eigenes Plugin gegen ein totes 3-MB-Paket — das ist oft die bessere Rechnung.

Wann wir ein eigenes Plugin schreiben

Wenn die Logik Ihr Geschäft ist. Staffelpreise, die kein Connector kennt. Ein Export, den die Buchhaltung in genau diesem CSV braucht. Ein Mitgliederbereich mit Rollen, die nicht „Subscriber“ heißen. Eine Schnittstelle zu einem System, das nur Ihre Branche nutzt. Ein Gutenberg-Block, der Ihre Leistungsmodule abbildet, ohne Page-Builder.

Wir schreiben das Plugin so, dass es deaktivierbar bleibt. Logik nicht ins Theme verstecken, wo sie beim Theme-Wechsel stirbt. Keine Core-Hacks. Keine „quick mu-plugins“, die niemand dokumentiert. Readme auf Deutsch, Häkchen im Admin nur wo nötig, Defaults die nicht telefonieren.

Was wir nicht als Plugin verkaufen

Kein Allzweck-Schweizer-Messer „Hesadu Super Suite“. Kein Plugin, das Ihre Site an unsere Server bindet, außer Sie beauftragen ausdrücklich eine Anbindung. Kein NDA-Bruch durch Demo-Daten echter Kunden. Keine Fake-Testimonials im Plugin-Directory. Wir sind ein Studio, kein Marktplatz-Vendor mit Wachstumsstory.

Und: Wir schreiben kein Plugin, wenn HTML reicht. Eine Tabelle auf einer Unterseite ist kein Plugin. Ein Jahresbericht als PDF-Link ist kein Plugin. Disziplin spart Geld. Das gilt auch, wenn wir den Code gerne schreiben würden.

WooCommerce: Core reicht selten, der Zoo schadet schnell

WooCommerce ist für viele DACH-Shops der pragmatische Kern. Versandklassen, Steuern, einfache Coupons, ein Katalog. Sobald B2B, Nettopreise, Kundensonderkonditionen, Stücklisten oder Warenwirtschaft ins Spiel kommen, rutscht der Marktplatz in Extension-Ketten. Jede Extension hängt an Woo-Hooks. Zwei Extensions, die denselben Checkout-Hook umbauen, erzeugen den Fehler, den niemand reproduzieren kann — außer am Freitag um 16:40, wenn Bestellungen reinkommen.

Eigene WooCommerce-Erweiterungen schreiben wir gegen die dokumentierten APIs: Preise, Fees, Order-Status, E-Mails, REST. Tests für den Pfad, der Geld bewegt. Logging ohne unnötige Personenbezüge. Keine Kreditkartendaten in der WordPress-Datenbank. Zahlungsprovider nach Ihrer Bank und Ihrem Steuerberater, nicht nach unserem Demo-Account.

Mehr zum Shop-Kontext steht unter Online-Shops. WordPress als CMS-Rahmen: WordPress-Leistung. Wer nur Broschüre plus Kontakt braucht, sollte WooCommerce nicht „für später“ installieren. Später ist ein anderes Projekt. Leere Shop-Seiten im Menü schaden Vertrauen und erzeugen Crawl-Müll.

Checkout ist kein Plugin-Friedhof

Jedes zusätzliche Feld, jedes Upsell-Popup, jeder verlassene-Warenkorb-Dienst lädt Script und juristische Fragen. Button-Beschriftung, Widerruf, Preise mit Grundpreis: Das ist Pflichtstrecke, kein Addon-Markt. Wir bauen die Strecke lieber schlank und korrekt als „conversion-optimiert“ mit drei US-SaaS-Pixeln vor Einwilligung.

Eigenes Plugin, Festpreis, kein Mystery-Scope

Custom Code schätzen wir nach Verhalten, nicht nach Dateianzahl. Was soll das Plugin tun, für wen, welche Fehlerfälle, welche Rolle darf es sehen, was passiert ohne WooCommerce, was passiert beim Deaktivieren. Daraus wird ein Festpreis oder eine Spanne. Open End „wir schauen mal“ gibt es nicht. Open End ist, wie Plugin-Zoos entstehen: nebenbei, ohne Auftrag, ohne Owner.

1. Ist-Zustand: Plugin-Liste, PHP-Version, Woo-Ja/Nein, Hosting, wer Admin ist. Screenshot reicht zum Start, Zugang auf Staging zum Arbeiten.
2. Zielverhalten in Sätzen, die ein Redakteur versteht. Keine Architektur-Folien ohne Beispiel. Ein Beispielauftrag, ein Beispielprodukt, ein Beispiel-Export.
3. Entscheidung: bestehendes Plugin härten, ersetzen, oder eigenes schreiben. Manchmal: WordPress verlassen, wenn das CMS die Last nicht mehr trägt.
4. Umsetzung auf Staging, Testdaten, kurze deutsche Doku, Übergabe. Updates für das eigene Plugin im Betreuungsvertrag oder als Einzelabruf — schriftlich, nicht als stillschweigende Erwartung.

Anzahlung, Staging, Launch. Rückfragen in der Regel innerhalb von 24 Stunden an Werktagen, Überlappung mit dem deutschen Vormittag. NDA vor Zugang zur Produktion, wenn Sie das brauchen. Wir zeigen keine Logos aus solchen Zugängen. Vertraulichkeit vor Showreel.

Wann WordPress das falsche Haus ist

Wenn Redaktion selten ist und die Angriffsfläche stört: hartes PHP. Wenn die Oberfläche ein Konfigurator mit Session-State ist: eher React und eine API, WordPress höchstens als Headless-Inhaltsspeicher — und selbst das nur, wenn Redakteure das wirklich brauchen. Headless „weil modern“ ist ein zweites System plus Auth plus Preview. Das muss ein Problem lösen, nicht ein Portfolio.

Wir beraten gegen unsere eigene Plugin-Rechnung, wenn ein Plugin unnötig ist. Das ist unbequem für den Umsatz einer einzelnen Position. Es ist ehrlich gegenüber dem Betrieb der nächsten drei Jahre. Wir behaupten nicht, das klügste Studio am Markt zu sein. Wir behaupten, den Stack zu lesen, bevor wir ihn vergrößern.

PHP-Kenntnis im Team — bei uns, bei Ihrer IT — entscheidet mit. Ein Custom Plugin, das niemand nach uns anfassen kann, ist eine neue Abhängigkeit. Deshalb Dokumentation, klarer Code, keine Magie. Strict Types wo es im WP-Kontext trägt. Hooks statt Monkey-Patches.

Betrieb: Hosting, PHP-Version, Backups

Eigene Plugins retten kein Billig-Hosting mit veralteter PHP-Version und ohne SSH. EU-Hoster mit Staging, automatischen Backups, die jemand testweise restored, PHP 8.x. Object Cache, wo die Seite ihn braucht. Nicht zwölf Caching-Plugins.

Backups ohne Restore-Übung sind Talisman. Einmal im Jahr eine Wiederherstellung auf Staging. Das gilt für Custom Code wie für Woo-Bestellungen. Wer nur Dateien sichert, aber die Datenbank nicht, sichert die Fassade.

Monitoring: Uptime und Fehlerlog, nicht fünfzehn Marketing-Tags. Wenn wir betreuen, schreiben wir, was wir sehen und was wir nicht sehen. Keine Scheinsicherheit.

Was Auftraggeber liefern müssen

Zugänge auf Staging, nicht gleich Super-Admin auf Production, wenn vermeidbar. Eine Person, die fachlich ja oder nein sagen darf. Testdaten, die anonymisiert sind. Keine echten Kundenlisten in der Mail an Sri Lanka, wenn eine reduzierte Menge reicht.

Wenn die Logik in Excel lebt, schicken Sie die Excel. Wir übersetzen sie in Regeln. Wenn die Logik nur in einem Kopf lebt, brauchen wir denselben Kopf in einem Call. Zeitzone ist lösbar. Unbenannte Regeln sind es nicht.

Sprache der Oberfläche: Deutsch, Sie-Form, Fehlermeldungen die ein Mensch versteht. Kein „Error 0x“. Kein englisches Admin in einer DE-Site, außer Ihr Team arbeitet so und will das ausdrücklich.

Kostenrahmen, ohne Märchen

Ein kleines Custom Plugin — ein Feld, ein Export, ein Block — liegt oft im niedrigen vierstelligen Bereich, manchmal darunter, wenn der Scope winzig und die Instanz sauber ist. Eine WooCommerce-Preislogik mit Rollen, Tests und E-Mails liegt höher. Eine ERP-Anbindung ist ein Projekt, kein Plugin-Slot auf der Preisseite.

Aufräumen eines Zoos kann teurer sein als drei eigene, schlanke Plugins plus Theme-Blöcke. Wir schätzen das nach Sichtung. Wir garantieren keine Google-Position, weil ein Plugin weniger die Core Web Vitals hebt. Schneller ja, oft. Rankings sind Wettbewerb und Inhalt, nicht ein Häkchen „SEO Pack Pro“.

Marktplatz-Lizenzen, die jährlich anfallen, rechnen wir durch. Manche sind fair. Manche finanzieren ein Produkt, das Ihre Site als Werbeträger nutzt. Dann schreiben wir lieber 200 Zeilen selbst.

Nach der Übergabe

Sie bekommen das Plugin, nicht ein Abo an uns als unsichtbare Abhängigkeit — außer Wartung ist beauftragt. Quellcode, den Sie nutzen dürfen, im Rahmen der GPL, sobald er in WordPress hängt. Das ist die Lizenzlogik des CMS, kein Trick. Anpassungen danach: neuer Auftrag oder Betreuungsvertrag.

Wenn Ihr Team selbst weiterentwickelt, sagen Sie das vorher. Dann schreiben wir so, dass ein zweiter Entwickler nicht fluchen muss. Wenn niemand intern PHP kann, planen wir Updates bei uns. Beides funktioniert. Halb so, halb so ohne Absprache erzeugt den nächsten Zoo.

Kompromittierte Instanzen: erst einfrieren, Backup, Malware-Muster, User prüfen, Salts, Plugins forensisch, dann härten. Das ist Incident, nicht Relaunch. Wir tun so etwas nach Aufwand. Wir tun nicht so, als wäre es ein Theme-Tausch.

Wie wir eine Plugin-Liste tatsächlich lesen

Wir sortieren nicht nach Sternen. Wir sortieren nach Last, Recht und Ersatzbarkeit. Zuerst: Was lädt im Frontend auf einer leeren Unterseite? Was hängt im Admin? Was schreibt in wp_options autoload? Was legt Cronjobs an? Was telefoniert nach Hause?

Dann die Ersatzfrage: Kann das Theme das? Kann ein Block das? Kann eine Zeile in functions.php das — und sollte sie trotzdem ein Mini-Plugin sein, damit das Theme austauschbar bleibt? functions.php als Müllhalde ist nur ein Plugin ohne Namen. Namenlose Dinge werden nicht aktualisiert.

Must-Use-Plugins nutzen wir sparsam. Sie umgehen den normalen Deaktivierungshebel. Das ist praktisch für eine harte Sicherheitseinstellung. Es ist gefährlich, wenn dort Geschäftslogik klebt, die niemand mehr findet. Was in mu-plugins liegt, steht in der Doku in einem Satz, den ein Nachfolger versteht.

Konflikte, die wie „WordPress ist langsam“ aussehen

Zwei Optimierungs-Plugins, die HTML umschreiben. Ein CDN-Plugin plus ein Cache-Plugin plus Server-Cache. Ein Slider, der jQuery.migrate erzwingt, während das Theme ohne jQuery auskommt. Ein Formular-Plugin, das reCAPTCHA von Google lädt, bevor Consent da ist. Das Frontend wirkt dann „irgendwie kaputt“. Der Reflex, ein weiteres Performance-Plugin zu installieren, macht es voller, nicht klarer.

Wir deaktivieren auf Staging in Gruppen. Nicht live. Wir notieren, was verschwindet: Fonts, Script-Handles, Admin-Notices. Danach bleibt eine kurze Liste mit Begründung. Die Begründung ist der Vertrag mit Ihrem zukünftigen Ich, das in 18 Monaten fragt, warum dieses eine Plugin noch da ist.

Blöcke statt Universal-Plugins

Ein Leistungsraster, ein Team-Grid, ein FAQ-Akkordeon: das sind Blöcke oder Template-Parts. Als Plugin nur, wenn mehrere Sites denselben Block teilen sollen. Innerhalb einer Site gehört das ins Theme. Wiederverwendung über Kunden hinweg machen wir nicht mit Ihren Daten. NDA bleibt NDA. Library-Code ohne Inhalte ist etwas anderes als ein Showreel.

Private Plugins, die nur Ihre Instanz kennt, hosten wir nicht heimlich auf unseren Servern als Abhängigkeit, außer Sie beauftragen Wartung. Auslieferung als Zip plus Git. Sie sollen die Site umziehen können, ohne uns als CDN für PHP zu brauchen. Das gilt auch, wenn wir den Code geschrieben haben: Besitz folgt dem Auftrag, nicht einer stillen Cloud-Bindung.

Composer und private Packagist-Setups nutzen wir, wenn Ihr Team so arbeitet. Die meisten WordPress-Instanzen im Mittelstand tun das nicht. Dann bleibt ein klarer Plugin-Ordner besser als eine Pipeline, die niemand anfasst. Tooling ohne Owner ist der Zoo in einer anderen Gestalt.

Wenn ein Marktplatz-Plugin 80 Prozent kann und 20 Prozent falsch: oft ist forken plus pflegen teurer als 100 Prozent selbst, in klein. Forks ohne Maintainer sind verlassene Plugins mit extra Scham. Wir forken nur, wenn Upstream tot ist und der Scope winzig bleibt — oder wir schreiben neu. Neu schreiben ist unspektakulär. Unspektakulär ist in WordPress oft die einzige nachhaltige Haltung.

Kurz der praktische Filter

Braucht es das Plugin, wenn JavaScript aus ist? Braucht es das Plugin auf der Datenschutzseite? Lädt es Code auf URLs, die es nicht betrifft? Wann wurde es zuletzt aktualisiert? Wer haftet, wenn es Bestellungen verdoppelt? Wenn die Antworten wackeln, gehört es auf die Streichliste oder in ein Lastenheft für eigenen Code.

Wir können den eigenen Code bauen. Wir können auch nein sagen und WordPress durch eine schlanke PHP-Site ersetzen, wenn Redaktion kein Argument mehr ist. Die Entscheidung treffen Sie. Wir legen die Kosten und die Risiken daneben. Ohne Superlativ, ohne Platz-1-Garantie, mit Impressum in Sri Lanka und Rechnung in Euro.

Staging zuerst: eigenes Plugin nie am Freitag live

Custom Code, der Bestellungen, Preise oder Rollen anfasst, geht zuerst auf eine Kopie. Testdaten, die anonymisiert sind. Ein Redakteur klickt den Weg, den ein Kunde klicken würde. Wir sitzen in Gampaha; die Überlappung mit dem deutschen Vormittag reicht für diesen Durchgang. Production ist der zweite Schritt, nicht der erste aus Begeisterung.

Rollback heißt: die vorherige Plugin-Version liegt bereit, nicht „wir schauen irgendwo im Backup“. Wer das für Pedanterie hält, hat noch nie einen Checkout in den Feierabend geschickt. Unter WordPress ist Staging Teil der Arbeit, kein Extra für Ängstliche.

Shop-Logik testen wir gegen ein Beispielprodukt, das Sie benennen. Ohne Beispiel ist jedes Plugin ein Essay. Essays kaufen wir nicht. Verhalten kaufen wir. Mehr zum Kaufprozess steht unter Online-Shop, falls WooCommerce im Spiel ist.

Was Redakteure im Admin sehen dürfen

Ein eigenes Plugin, das zwölf Menüs in die linke Leiste hängt, ist gescheitert, auch wenn der PHP-Teil elegant ist. Capabilities, deutsche Labels, Hinweise in einem Satz. Felder, die nur Administratoren brauchen, bleiben Administratoren. Sonst entsteht der nächste Zoo: jemand klickt ein Häkchen, das Tracking anschaltet, „weil es da stand“.

Wir testen den Admin mit der Rolle, die Ihr Team wirklich hat. Nicht mit unserem Super-Admin. Der Unterschied ist peinlich und nützlich. Peinlich in der Schulung, nützlich im Betrieb der nächsten zwei Jahre. Ein Button ohne Label, den nur wir verstehen, ist kein Feature. Er ist die nächste Support-Mail aus Deutschland, die um 9 Uhr MEZ ankommt, während in Gampaha gerade der Vormittag beginnt — und die wir lieber gar nicht erst auslösen.

Wenn Ihre Instanz bereits keucht: Plugin-Liste schicken, Ziel in drei Sätzen, Hosting nennen. Kontakt reicht. Wer den Rahmen WordPress grundsätzlich klären will, startet bei den WordPress-Leistungen. Shop-Fälle zusätzlich unter Online-Shop, harte Alternative unter PHP und HTML, Tempo-Diagnose unter WordPress langsam.

Dazu eine Einschätzung holen Leistungen