Anmelden

Gezielte WordPress-Inhaltssynchronisierung

Die gezielte Inhaltssynchronisierung veröffentlicht die Auswirkungen von WordPress-Änderungen, ohne die gesamte Website erneut zu crawlen. Sie ist mit einem aktiven Professional- oder Agency-Abonnement verfügbar, ebenso wie die inkrementelle Veröffentlichung, und wird über eine gespeicherte Zeitplanregel und den externen Warteschlangen-Runner von @smart-cloud/publisher-exporter ausgeführt.

Was eine Regel erfasst​

Jede Regel wählt einen oder mehrere öffentliche, abfragbare Inhaltstypen mit stabilen Permalinks. WordPress protokolliert dabei unter anderem folgende öffentliche Übergänge:

  • Veröffentlichungen und Aktualisierungen veröffentlichter Inhalte,
  • Taxonomie- und Sticky-Statusänderungen,
  • Zurückziehen, Verschieben in den Papierkorb und endgültiges Löschen,
  • Permalink-, Autor- und Veröffentlichungsdatumsänderungen, die öffentliche Oberflächen betreffen.

Die Regel kann Archive für Inhaltstypen und Taxonomien, die konfigurierte Beitragsseite, optionale Autoren- und Datumsarchive, Seitennummerierung und Auswirkungen auf die Sitemap berücksichtigen. Verwenden Sie Explicit listing routes für Query-Loop-Seiten oder andere Auflistungen, deren Abfragen WordPress nicht zuverlässig ableiten kann. Routen müssen relativ zur Website angegeben werden, eine pro Zeile, etwa / oder /insights/.

Darum kann das Veröffentlichen oder Ändern eines Beitrags mehrere statische Dateien berühren: der Beitrag selbst ist nur ein Teil einer Listing-/Archiv-/Paginierungs-/Sitemap-Kette.

Baseline zuerst​

Ein erfolgreicher normaler Voll- oder inkrementeller Publish muss eine verifizierte Baseline etablieren, bevor gezielte Jobs deployen können. Die Baseline bindet den aktuellen WordPress-Release, Source/Target, Rewrite, Scope und vertrauenswürdiges Crawl Manifest.

Starten Sie einen weiteren normalen Publish, wenn der Admin New baseline required meldet. Typische Ursachen sind Theme-/Plugin-Release, Permalink- oder Sitemapänderungen, Rewrite-Änderungen oder Content-Sync-Scope-Anpassungen. Bei veralteter Baseline stoppt Content Sync bewusst, statt implizit auf Vollcrawl auszuweichen.

Verhalten bei Zeitplanung und Wiederholungen​

WordPress Scheduler startet publisher-exporter queue-runner nicht selbst. Starten Sie ihn über Cron, systemd timer, Windows Task Scheduler oder CI. Ein Minuten-Tick ist empfohlen; die Regel bestimmt, wie häufig Bedarf geprüft wird.

Der Runner verarbeitet einen abgeschlossenen Journalbereich. Währenddessen eintreffende Änderungen werden als Folgeauftrag übernommen. Gleichartige Anforderungen werden zusammengeführt; bei Fehlern gelten begrenzte Wartezeiten zwischen Wiederholungen, während der Prüfpunkt erhalten bleibt. Der Cursor wird erst nach Bereitstellung, CloudFront-Invalidierung und abschließender Prüfung fortgeschrieben.

Wird ein Wiederholungsauftrag aus der Auftragsliste verworfen, löscht Static Publisher den lokalen Plan und Prüfpunkt, bestätigt jedoch den Journalbereich nicht. Ein späterer Zeitplanlauf kann daher denselben Bereich erneut übernehmen.

Sichere Updates und Löschungen​

Für veröffentlichte Inhalte rendert der Runner die neue öffentliche URL und betroffenen Navigationsflächen. Für Unpublish/Trash/Delete oder Permalink-Änderungen wird die letzte exakte öffentliche URL vor dem Übergang verwendet. WordPress-Trash-Aliase, die auf __trashed enden, werden als Löschziel abgelehnt.

Entfernte Löschungen sind manifestbasiert: Die Inhaltssynchronisierung kann nur Pfade zum Löschen markieren, die im vertrauenswürdigen Crawl-Manifest vorhanden sind. Sie erstellt keine vollständige Präfixliste des S3-Ziels und verhindert damit das unbeabsichtigte Löschen fremder oder nicht zugehöriger Objekte. Eine umfassende Bereinigung bleibt Aufgabe eines normalen vollständigen oder inkrementellen Abgleichs.

WordPress Multisite​

Multisite-Subsites einschließen ist standardmäßig aus. Ist diese Option aus, wird nur die Site erfasst, der Runtime gehört.

Aktivieren Sie sie nur wenn:

  • WordPress im Multisite-Netzwerk läuft,
  • SmartCloud Static Publisher netzwerkaktiv ist,
  • die einbezogenen Subsites denselben Origin mit pfadbasierten URLs und gemeinsamen statischen Namespace nutzen.

Nach der Aktivierung verfolgt die Regel passende Inhaltstypen im gesamten Netzwerk und versieht jedes Ereignis mit einer Website-ID. Anschließend ist eine neue reguläre Veröffentlichung erforderlich. Eigenständig gehostete oder domainbasierte Unterwebsites benötigen separate Publisher-Ziele und werden nicht automatisch als Pfad der Hauptwebsite behandelt.

Operative Prüfungen​

Die Scheduler Settings zeigen beobachtete und bestätigte Sequenzen, Lag, Baseline-Bereitschaft, Nachlauf, Retry-Versuche und den letzten Lauf. Für einen gesunden Abschluss sollten beobachtet und bestätigt, Lag=0 und keine offenen Content-Sync Jobs vorliegen.