Die meisten unerklärlichen 404er haben eine Ursache: WordPress prüft Rewrite-Regeln der Reihe nach und hält bei der ersten passenden an, und nirgends im Adminbereich steht diese Reihenfolge. Dieses Plugin zeigt die Reihenfolge, erklärt jeden Konflikt mit Gewinnerin, Verliererin und einem Beispielpfad und sagt, welchen Slug Sie ändern müssen. Die zweite Hälfte bringt die Arbeit vom Staging in den Livebetrieb: ein signierter Konfigurationsexport und eine gezielte Inhaltsübernahme, statt eine ganze Datenbank über die Bestellungen zu kopieren, die seit dieser Kopie eingegangen sind.
WordPress prüft einen Request gegen eine Liste von Rewrite-Regeln, der Reihe nach, und hält bei der ersten passenden an. Dieser eine Satz steckt hinter den meisten unerklärlichen 404ern: Eine früher registrierte Regel schluckt eine URL, die eine spätere bedienen sollte, und die zweite Regel hört still auf zu arbeiten. Plugins registrieren laufend neue Regeln, und nirgends im Adminbereich steht die Reihenfolge — wer die Ursache eines 404ers sucht, hat also nichts zum Nachsehen.
Der Reiter Rules zeigt genau diese Liste in Trefferreihenfolge und stellt Konflikte nach oben. Die Erkennung ist konkret statt theoretisch: Das Plugin baut URLs, die die unterlegene Regel bedienen sollte, und prüft, ob eine frühere Regel sie zuerst nimmt. Das Ergebnis benennt vier Dinge — welche Regel gewinnt, welche verliert, einen Beispielpfad und meist einen Rewrite-Slug, den Sie ändern sollten. Die Herkunft jeder Regel wird aus den Query-Vars abgeleitet, die sie setzt, und die Oberfläche kennzeichnet das als Vermutung statt es als Tatsache auszugeben.
Der Weiterleitungsmanager nimmt 301, 302, 307 und 308 und sieht standardmäßig nur Requests, die WordPress nicht selbst bedienen konnte, damit eine tatsächlich vorhandene Seite nie überdeckt wird. Reguläre Ausdrücke werden vor dem Speichern kompiliert und gestoppt; wer auf einer Probe mehr als 50 Millisekunden braucht, wird abgelehnt — denn das eigentliche Problem ist nicht das Muster, sondern die Eingabe: Dieses Muster läuft bei jedem Request, und jede Besucherin kann eine lange URL schicken. Ziele auf fremden Domains werden ebenfalls abgelehnt, solange Sie den Host nicht bewusst erlauben, weil ein Weiterleitungsmanager, der jedes Ziel akzeptiert, ein Open Redirect ist.
Die zweite Hälfte bewegt Arbeit zwischen zwei Websites. Üblich ist, die ganze Staging-Datenbank über die Live-Datenbank zu kopieren — was jede Bestellung vernichtet, die seit dieser Kopie eingegangen ist. Hier ist die Übernahme gezielt: eine signierte Konfigurationsdatei für Elementor, ACF, Rank Math, Yoast, WooCommerce und WordPress selbst, und ein Abgleich für Seiten, Beiträge, Elementor-Vorlagen, ACF-Feldgruppen, Menüs und den Produktkatalog. Der Probelauf ist die Voreinstellung, jeder Import wird zuerst in der Vorschau gezeigt und die letzten fünf lassen sich zurücknehmen, und das Protokoll sagt, was übersprungen wurde und warum.
Weil hier zwei Live-Websites einander schreiben dürfen, ist die Sicherheit der Übertragung das Produkt und keine Randnotiz. Jeder Request zwischen ihnen wird mit HMAC-SHA256 signiert, über Methode, Route, Query-String, Zeitstempel, eine einmalige Nonce und einen Hash des Rumpfs; jedes weggelassene Feld eröffnet einen konkreten Angriff. Eine Signatur sagt aber nur, wer etwas geschrieben hat, nicht dass der Inhalt unbedenklich ist — eine legitime Website, die selbst übernommen wurde, signiert mit gültigem Schlüssel alles. Deshalb liegen zwei Verbotslisten außerhalb der Reichweite jedes Filters: eine, die active_plugins, siteurl und die Auth-Schlüssel nie durchlässt, und eine, die Bestellungen, Rückerstattungen, Abonnements, Gutscheine, Kundinnen, Benutzerkonten, Sitzungen und Zahlungstoken nie abgleicht.
Vorher
Eine Seite liefert 404, und nichts im Adminbereich sagt, welche Regel die URL zuerst genommen hat.
Nachher
Die Regeln in Trefferreihenfolge, mit Gewinnerin, Verliererin, einem Beispielpfad und dem zu ändernden Slug.
Vorher
Der einzige Weg, Staging-Einstellungen live zu bekommen, ist die ganze Datenbank zu kopieren — und damit jede zwischenzeitliche Bestellung zu löschen.
Nachher
Es geht nur, was Sie angehakt haben, mit Vorschau und Probelauf. Bestellungen, Kundinnen, Benutzerkonten und Zahlungstoken sind im Code ausgeschlossen.
Vorher
Ein Weiterleitungsmanager, der jedes Ziel und jedes Muster annimmt, ist zugleich ein Open Redirect und ein Weg, die Website auszubremsen.
Nachher
Muster werden vor dem Speichern kompiliert und gestoppt, und fremde Ziele werden abgelehnt, solange Sie den Host nicht bewusst erlauben.
Die erste Stelle zum Nachsehen. Was unter Conflicts steht, sind URLs auf Ihrer Website, die ohne erkennbaren Grund 404 liefern.
Jeder Konflikt sagt, welche Regel gewinnt, welche nie läuft und welchen Rewrite-Slug Sie ändern sollten. Danach flushen und erneut nachsehen — einmal alle dreißig Sekunden.
Erzeugen Sie das gemeinsame Geheimnis auf einer Seite und fügen Sie es auf der anderen ein, drücken Sie Test, lassen Sie Compare laufen und danach einen Probelauf, bevor etwas übernommen wird. Jeder Lauf wird protokolliert.
Websites, deren Inhaltstypen und Taxonomien aus mehreren Plugins stammen · Websites, auf denen nach einer Plugin-Aktivierung URLs 404 liefern · Shops, die Katalog und Seiten zuerst im Staging bauen · Teams, die Elementor- und ACF-Einstellungen zweimal von Hand eingeben · Agenturen, die eine Kundenwebsite samt Staging-Kopie betreuen · alle, die nach einer Änderung der Permalinkstruktur nicht sehen, welche Regel jetzt welche überdeckt · Teams, die die Live-Datenbank nicht mit einer Staging-Kopie überschreiben dürfen.
Beide Hälften stecken im Plugin selbst. Kein Composer zur Laufzeit, kein Cloud-Dienst und kein jQuery.
Die Liste wird aus der gespeicherten Routing-Tabelle gelesen statt neu erzeugt — denn die gespeicherte ist es, die beim Abgleich tatsächlich benutzt wird, und genau darauf kommt es an, wenn jemand einen 404er sucht. Die Herkunft jeder Regel wird aus den gesetzten Query-Vars abgeleitet und als Vermutung ausgewiesen.
Das Plugin baut URLs, die die unterlegene Regel bedienen sollte, und prüft, welche Regel sie zuerst nimmt. Jeder Befund trägt eine Schwere: Hoch heißt, ein Inhaltstyp oder eine Taxonomie ist gar nicht mehr erreichbar. Der Scan ist quadratisch und deshalb begrenzt, voreingestellt auf 400 Regeln.
Nötig nach dem Registrieren eines neuen Inhaltstyps oder einer Änderung der Permalinkstruktur. Auf einer großen Website dauert es Sekunden, und der Knopf lädt zum mehrfachen Klicken ein, also ist er einmal alle dreißig Sekunden erlaubt. Die .htaccess bleibt unberührt; ein Plugin, das ungefragt eine Server-Konfiguration schreibt, legt Websites lahm.
301, 302, 307 und 308, mit $1-Gruppen im Ziel, wenn die Quelle ein regulärer Ausdruck ist. Standardmäßig läuft er nur für Requests, die WordPress nicht selbst bedienen konnte, damit eine tatsächlich vorhandene Seite nie verdeckt wird. Der Test-Knopf sagt, ob eine Weiterleitung trifft und wohin genau sie schickt.
Jedes Muster wird kompiliert und gegen lange Probeeingaben laufen gelassen; wer an die Backtracking-Grenze von PCRE stößt oder mehr als 50 Millisekunden braucht, wird mit Erklärung abgelehnt, statt die Website bei jedem Request zu bremsen. Das Plugin besitzt Delimiter und Modifikatoren, damit ein Muster keine eigenen mitbringt, und die $1-Ersetzung ist ein schlichtes str_replace statt preg_replace, damit eine gefangene Gruppe mit Regex-Syntax das Ergebnis nicht beeinflusst.
Sonst darf jede Person, die eine Weiterleitung anlegen kann, Ihre Besucherinnen mit Ihrer Domain im Link auf die eigene Seite schicken. Externe Ziele werden abgelehnt, solange der Host nicht über den Filter hd_ras_allowed_redirect_hosts erlaubt ist, und protokollrelative Ziele werden eigens geprüft, weil sie der übliche Weg an einer solchen Prüfung vorbei sind.
Sieben Gruppen: Site-Grundlagen, Elementor, ACF, Rank Math, Yoast, WooCommerce-Anzeigeeinstellungen und dieses Plugin selbst. Es erkennt, welche davon auf dieser Website vorhanden sind, und bietet den Rest nicht an. Ein Import prüft die Signatur, bevor er die Datei parst — etwas Ungeprüftes zu parsen ist selbst eine Angriffsfläche.
Sie werden mit AES-256-GCM verschlüsselt, und jeder Zweck bekommt seinen eigenen, über HKDF abgeleiteten Schlüssel. Soll die Datei auf einer Website geöffnet werden, die nie mit dieser gekoppelt war, setzen Sie eine Passphrase: Der Schlüssel entsteht über PBKDF2-SHA256 mit 310.000 Runden, und zwölf Zeichen sind das Minimum — Raten geschieht offline und so oft die Angreiferin mag.
Die Vorschau sagt genau, was sich ändern würde, und Übernehmen bleibt gesperrt, bis Sie eine geholt haben. Ändert sich die Datei zwischen Vorschau und Bestätigung, merkt das Plugin es und verlangt eine neue Vorschau. Die letzten fünf Importe lassen sich zurücknehmen, und die Rücknahme geht durch dieselbe Erlaubnisliste.
Vergleichen Sie diese Website mit einer gekoppelten und holen Sie nur, was abweicht: Seiten, Beiträge, Elementor-Vorlagen, ACF-Feldgruppen, Menüs und den Produktkatalog. Der Vergleich läuft über ein Manifest und einen Fingerabdruck, sodass der Abgleich einer unveränderten Website eine kleine Antwort kostet statt einer vollen Übertragung. Der Probelauf ist die Voreinstellung.
Die erste lässt active_plugins, template, siteurl, home, users_can_register, die Auth-Schlüssel und Salts sowie die Identität dieses Plugins nie aus einer Konfigurationsdatei schreiben. Die zweite gleicht Bestellungen, Rückerstattungen, Abonnements, Gutscheine, Kundinnen, Benutzerkonten, Sitzungen, Zahlungstoken und jeden Beitrag mit einem Status ab wc- nie ab. Auch die Taxonomie product_visibility bleibt draußen, weil WooCommerce dort den Lagerstatus führt.
HMAC-SHA256 über Schema-Version, Methode, Route, Zeitstempel, Nonce und einen Hash des Rumpfs. Zeitstempel außerhalb eines Fensters von fünf Minuten werden abgelehnt, Nonces sind einmalig und werden atomar belegt, sodass zwei gleichzeitige Kopien eines wiedereingespielten Requests nicht beide durchkommen, und Signaturen werden in konstanter Zeit verglichen. Die Nonce wird erst nach erfolgreicher Prüfung verbraucht, sonst könnte jede Person durch Raten die Nonces einer legitimen Absenderin aufbrauchen.
Jede Adresse, zu der das Plugin verbindet, wird vorher geprüft: Loopback, private Bereiche und Cloud-Metadaten-Endpunkte werden abgelehnt. Hostnamen werden vor der Entscheidung aufgelöst — evil.example.com kann auf 127.0.0.1 zeigen — und die Verbindung wird auf genau die geprüfte Adresse festgelegt, damit der Name dazwischen nicht umgebogen wird.
Jeder Abgleich und jeder Import wird mit einer Lauf-Kennung und dem Ergebnis je Objekt festgehalten. Was bewusst übersprungen wurde, steht mit Grund darin — ein Beitrag ohne Slug, ein Typ auf der Verbotsliste, ein Objekt, das auf beiden Seiten schon gleich war. Ein Protokoll, das nur die Erfolge zeigt, verbirgt genau das, was zu sehen wäre.
Alle in docs/hooks.md, jeder mit Beispiel. Die vier, die Verhalten öffnen — hd_ras_allow_private_url, hd_ras_update_hosts, hd_ras_allowed_redirect_hosts und hd_ras_option_groups — sind dort mit ihrem Preis markiert, damit niemand einen davon einschaltet, ohne den Tausch zu kennen.
Eine vollständige fa_IR-Übersetzung liegt bei, und der Adminbereich lädt admin-rtl.css, wenn is_rtl() gilt. Muster, URLs und Schlüssel sind mit dir="ltr" ausgezeichnet, damit sie auf einer rechtsläufigen Seite nicht verdreht werden. Die Reiter tragen WAI-ARIA-Semantik und lassen sich mit den Pfeiltasten wechseln. Kein jQuery — reines ES6, nur auf der eigenen Seite des Plugins.
| Funktion | Beschreibung | Enthalten |
|---|---|---|
| Regeln in Trefferreihenfolge | Aus der gespeicherten Routing-Tabelle gelesen, nicht neu erzeugt | |
| Vermutete Herkunft je Regel | Aus den gesetzten Query-Vars, in der Oberfläche als Vermutung gekennzeichnet | |
| Konflikterkennung über gebaute URLs | Die URLs, die die unterlegene Regel bedienen sollte, werden gebaut und geprüft | |
| Eine Schwere je Konflikt | Hoch heißt, ein Inhaltstyp oder eine Taxonomie ist gar nicht mehr erreichbar | |
| Ein Beispielpfad je Konflikt | Dazu der zu ändernde Rewrite-Slug; Beispiel-URLs sind als konstruiert gekennzeichnet | |
| Der Konfliktscan ist begrenzt | 400 Regeln voreingestellt, über hd_ras_conflict_scan_limit | |
| Flush mit erzwungenem Abstand | Einmal alle dreißig Sekunden, und die .htaccess bleibt unberührt | |
| 301, 302, 307 und 308 | Mit optionaler Beachtung der Groß- und Kleinschreibung | |
| $1-Gruppen im Ziel | Schlichtes str_replace, höchster Index zuerst, bewusst kein preg_replace | |
| Muster vor dem Speichern geprüft | 50 Millisekunden Budget auf einer Probe und 2000 Zeichen Länge | |
| Delimiter und Flags gehören dem Plugin | Ein Muster kann keine eigenen mitbringen | |
| Schleifen abgelehnt, Ketten gemeldet | Eine Kette ist manchmal Absicht, eine Schleife nie | |
| Ein Test-Knopf, bevor Sie vertrauen | Sagt, ob es trifft und wohin genau es schickt | |
| Nur Requests, die WordPress nicht bedienen konnte | Voreinstellung, damit eine tatsächlich vorhandene Seite nie überdeckt wird | |
| Fremde Ziele werden abgelehnt | Sofern der Host nicht bewusst über hd_ras_allowed_redirect_hosts erlaubt ist | |
| Sieben Einstellungsgruppen | Site-Grundlagen, Elementor, ACF, Rank Math, Yoast, WooCommerce und dieses Plugin selbst | |
| AES-256-GCM auf geheimnisverdächtigen Werten | Mit eigenem Schlüssel je Zweck, über HKDF abgeleitet | |
| Passphrasen-Schlüssel über PBKDF2 | SHA-256, 310.000 Runden, mindestens zwölf Zeichen | |
| Signatur geprüft, bevor die Datei geparst wird | Etwas Ungeprüftes zu parsen ist selbst eine Angriffsfläche | |
| Erlaubnisliste erneut vor jedem Schreiben | Eine Signatur sagt, wer die Datei schrieb — nicht, dass ihr Inhalt sicher ist | |
| Vorschau und Rücknahme der letzten fünf Importe | Ändert sich die Datei dazwischen, ist eine neue Vorschau nötig | |
| Sechs Inhaltsgruppen | Seiten, Beiträge, Elementor-Vorlagen, ACF-Feldgruppen, Menüs und Produktkatalog | |
| Zuordnung über Inhaltstyp und Slug | Nie über eine numerische ID; ein Beitrag ohne Slug wird übersprungen | |
| Ein Fingerabdruck entscheidet, was abweicht | Lagerbestand und Verkaufszahl liegen bewusst außerhalb | |
| Probelauf als Voreinstellung | Er berichtet, ohne etwas zu schreiben | |
| Vergleich über ein Manifest | Vier Zahlen: nur dort, abweichend, gleich, nur hier | |
| HMAC-SHA256 auf jedem Request | Methode, Route, Zeitstempel, Nonce und Rumpf-Hash, in einem Fenster von fünf Minuten | |
| Einmalige Nonces, atomar belegt | Und erst nach erfolgreicher Signaturprüfung verbraucht | |
| Rechte je Kopplung | Eine nur lesende Kopplung kann hier nichts schreiben | |
| Prüfung ausgehender Adressen | Loopback, private Bereiche und Cloud-Metadaten abgelehnt, vor der Entscheidung aufgelöst und auf diese Adresse festgelegt | |
| Geheimnisse sind reine Schreibfelder | Privater Schlüssel und Site-Geheimnis liegen in einer eigenen Option, außerhalb dessen, was der Export durchläuft |
| Punkt | Minimum |
|---|---|
| WordPress | 6.2 oder neuer, getestet bis 6.8 |
| PHP | 8.0 bis 8.3 |
| OpenSSL | Nötig, um sensible Werte in einer Konfigurationsdatei zu verschlüsseln. Zum Signieren nutzt das Plugin es, wo vorhanden, und beglaubigt Dateien sonst mit dem gemeinsamen Geheimnis; die Oberfläche sagt, was gerade gilt. Der Abgleichkanal braucht beides nicht. |
| Eine zweite Website | Nur für den Abgleich: zwei Websites mit der Pro-Stufe, dasselbe gemeinsame Geheimnis an beiden Enden und REST-Zugriff dazwischen. Regelprüfer und Weiterleitungsmanager laufen auch auf einer einzelnen Website. |
| Berechtigung | manage_options zum Öffnen der Seite und für jeden Schreibvorgang, änderbar über hd_ras_manage_capability |
Für eine, auf der mehrere Plugins laufen und jedes eigene Inhaltstypen, Taxonomien oder Rewrite-Regeln registriert — dort taucht der unerklärliche 404er auf, und niemand weiß, welche Regel die URL genommen hat. Das zweite Publikum ist ein Team, das im Staging arbeitet und das Ergebnis live bringen muss, ohne die Live-Datenbank mit einer älteren Kopie zu überschreiben. Einer Website mit zehn Seiten und ohne eigene Inhaltstypen hat es wenig zu sagen.
Der Regelprüfer arbeitet nur, wenn Sie seine Seite öffnen; auf gewöhnlichen Requests misst er nichts. Der Weiterleitungsmanager läuft auf template_redirect und standardmäßig nur für Requests, die WordPress nicht selbst bedienen konnte, ein Request auf eine echte Seite erreicht ihn also nie, und die Liste der aktiven Weiterleitungen wird zwischengespeichert. Teure Muster dürfen gar nicht erst gespeichert werden, genau dafür ist diese Prüfung da. Ein abgeschaltetes Modul wird überhaupt nicht geladen.
Weil er aus dem Muster der unterlegenen Regel selbst stammt: Das Plugin baut die URLs, die diese Regel bedienen sollte, und probiert sie gegen die vollständige Liste; nimmt eine weiter oben stehende Regel sie zuerst, ist der Konflikt echt und Sie sehen den Beispielpfad. Zwei Dinge werden ebenfalls nicht verschwiegen: Die Herkunft jeder Regel ist eine Ableitung aus ihren Query-Vars und ist so gekennzeichnet, und die Beispiel-URLs sind konstruiert, kein beobachteter Verkehr. Die Liste kommt außerdem aus der zuletzt berechneten Routing-Tabelle — wirkt sie veraltet, ist genau das der Punkt: flushen und vergleichen.
Zwei häufige Gründe. Der eine ist Backtracking: Muster werden vor dem Speichern gegen lange Eingaben getestet, und wer mehr als 50 Millisekunden braucht oder an die Backtracking-Grenze von PCRE stößt, wird abgelehnt. Meist sind verschachtelte Quantoren schuld; (.+)+ war nicht gemeint, (.+) schon. Der andere Grund sind mitgeschriebene Delimiter: Schreiben Sie ^/old/(.*)$, nicht eine in ~ gefasste Fassung mit Flags dahinter. Die Strenge gibt es, weil dieses Muster bei jedem Request läuft und jede Besucherin eine acht Kilobyte lange URL schicken kann.
Weil ein Weiterleitungsmanager, der jedes Ziel annimmt, ein Open Redirect ist: Wer eine Weiterleitung anlegen kann, schickt Ihre Besucherinnen auf die eigene Seite, mit Ihrer Domain im Link. Ist es Absicht, ergänzen Sie den Host über den Filter hd_ras_allowed_redirect_hosts — damit steht die Entscheidung im Code und nicht in einem Textfeld.
Nein. Bestellungen, Rückerstattungen, Abonnements, Gutscheine, Kundinnen, Benutzerkonten, Sitzungen und Zahlungstoken sind im Code ausgeschlossen, und keine Einstellung und kein Filter erreicht diese Liste. Die Begründung: Eine Staging-Website ist eine Kopie aus einem vergangenen Moment, und alles Transaktionale, das seither live passiert ist, existiert nur dort; die Staging-Fassung darüber zu schreiben führt beide Seiten nicht zusammen, sondern vernichtet eine. Aus demselben Grund liegen Lagerbestand und Verkaufszahl außerhalb des Vergleichs-Fingerabdrucks und werden nie übertragen.
Genau das löst eine Signatur nicht: Sie sagt nur, wer die Datei oder den Request geschrieben hat. Deshalb gibt es zwei getrennte Verbotslisten, geprüft nach der Verifikation und erneut vor jedem Schreiben, und kein Filter erreicht eine davon — die eine stoppt active_plugins, siteurl, home, users_can_register und die Auth-Schlüssel, die andere transaktionale Daten. Der praktische Rat steht in der Anleitung: Halten Sie die Kopplung mit dem Staging auf der Live-Seite nur lesend, dann kann das Staging vergleichen, aber nichts schreiben.
Bis zu fünf Minuten Abweichung werden geduldet, darüber hinaus werden Requests abgelehnt, und die Meldung sagt das auch. Das Fenster ist bewusst schmal, denn ein weites macht einen mitgeschnittenen Request wiedereinspielbar. Sehen Sie diesen Fehler, prüfen Sie NTP auf einem der beiden Server.
Zum Verschlüsseln sensibler Werte in einem Konfigurationsexport ja. Zum Signieren einer Datei nutzt das Plugin OpenSSL, wo es vorhanden ist, und beglaubigt die Datei sonst mit dem gemeinsamen Geheimnis; die Oberfläche sagt, was gerade gilt, statt still schwächer zu arbeiten. Der Abgleichkanal zwischen zwei Websites braucht weder das eine noch das andere, er ist HMAC.
Beide Hälften, beide aktiv: Regeln in Trefferreihenfolge, Konflikterkennung mit Beispielpfad, ein sicheres Flush und der vollständige Weiterleitungsmanager mit Musterprüfung, Schleifen- und Kettenerkennung und Test-Knopf — dazu die Übertragungshälfte: signierter Konfigurationsexport und -import, Verschlüsselung sensibler Werte und der gezielte Inhaltsabgleich mit dem Staging. Der Abgleich braucht dasselbe Paket an beiden Enden.
Nein. Das Plugin bringt einen eigenen kleinen Autoloader mit und hat zur Laufzeit keine Abhängigkeiten. Der einzige ausgehende Aufruf, den es selbst beginnt, ist die Lizenzprüfung und Aktualisierung der Pro-Stufe gegen hatamidev.com; der Updater akzeptiert nur ein https-Paket auf hatamidev.com und folgt keinen Weiterleitungen, denn ein einziger Open Redirect im Shop würde sonst genügen, um ein beliebiges ZIP über das Plugin-Verzeichnis zu entpacken. Die Lizenz hat zudem vierzehn Tage Karenz, damit ein kurzer Ausfall auf unserer Seite die Website einer Kundin nicht anhält.
Es wird nichts gelöscht, solange Sie „Alle Daten beim Entfernen des Plugins löschen“ nicht eingeschaltet haben; das ist standardmäßig aus. Die einzige Ausnahme sind die Wiedereinspiel-Marker, einmalige Werte ohne Bedeutung für irgendjemanden. Das Deaktivieren räumt geplante Ereignisse ab und baut die Routing-Tabelle ohne die Regeln dieses Plugins neu, rührt gespeicherte Daten aber nie an.
Fehlerbehebung im Plugin, Hilfe bei Installation und beim Koppeln zweier Websites sowie Hilfe beim Lesen der Konflikte und bei der Entscheidung, welcher Slug geändert wird. Die Permalinkstruktur einer Website neu zu entwerfen, das Plugin zu reparieren, das die konfliktträchtige Regel registriert hat, und vollständige Website-Umzüge liegen außerhalb des Supports und werden separat vereinbart.