Anmelden

Warteschlange und Betrieb für statische WordPress-Veröffentlichungen

Static Publisher ist auf Aufträge in einer Warteschlange und deren externe Ausführung ausgelegt.

Laufzeitdateien​

Das Plugin schreibt Status nach wp-content/uploads/smartcloud-static-publisher/runtime, darunter:

  • config.json
  • queue.json
  • current-run.json
  • last-run.json
  • export.lock

Für die gezielte Inhaltssynchronisierung werden außerdem Baseline, Cursor, Prüfpunkt, Kandidatenmanifest, Auswirkungsplan, Bereitstellungsdifferenz und Invalidierungsstatus im Laufzeitverzeichnis geführt. Diese Dateien bilden den Betriebszustand ab und sind keine kurzlebigen Zwischenspeicher, solange ein Synchronisierungsauftrag in der Warteschlange liegt, aktiv ist oder auf eine Wiederholung wartet.

Logs liegen im konfigurierten Log-Verzeichnis; abgeschlossene Jobs archivieren Artefakte unter archive/<timestamp-command-jobId-status>/.

Queue-Befehle​

Die Verwaltungsoberfläche kann diese Befehle in die Warteschlange stellen:

  • publish
  • crawl
  • deploy
  • invalidate
  • retry-timeouts
  • url für einen Lauf über einen einzelnen Pfad

content-sync Jobs werden durch Professional- oder Agency-Schedulerregeln erstellt. Es ist kein freies Manuell-URL-Kommando: Der Job beansprucht einen unveränderbaren Journal-Bereich und nutzt den gespeicherten Scope. Inkrem. Publishing und gezielter Sync brauchen denselben aktiven Abonnementlevel.

Temporäre AWS-Credentials können zu publish, deploy und invalidate Jobs gegeben werden. Sie werden nur in den Kindprozess injiziert und im Admin-Status ausgeblendet.

Zeitplanmodell​

Zeitplanregeln werden zu Beginn jedes Laufs von publisher-exporter queue-runner ausgewertet.

Wichtige Implikationen:

  • das Plugin startet den Runner nicht selbst,
  • Produktivumgebungen sollten Cron, systemd timer, CI oder externen Scheduler verwenden,
  • ein 1-Minuten-Runner-Tick ist empfohlener Startwert,
  • gleichartige Jobs werden innerhalb des aktuellen Intervall-Buckets dedupliziert.
  • wiederkehrender Content-Sync Bedarf wird zusammengeführt; Änderungen während eines beanspruchten Bereichs werden als Folgearbeit behandelt.

Vor Aktivierung eines Content-Sync-Schedules führen Sie einen erfolgreichen normalen Voll- oder inkrementellen Publish durch. Dieser Lauf etabliert die vertraute Manifest-Basis und die verifizierte Baseline. Theme-, Plugin-, Permalink-, Sitemap-, Rewrite-, Scope- oder Target-Änderungen markieren die Baseline bewusst als veraltet und erfordern einen weiteren normalen Publish. Die Scheduler-Einstellung zeigt diesen Zustand direkt.

Typisches Linux-Cron Muster:

* * * * * /usr/bin/flock -n /tmp/static-publisher.cron.lock \
  publisher-exporter queue-runner \
  --runtime-dir /var/www/site/wp-content/uploads/smartcloud-static-publisher/runtime \
  --max-jobs 1 >> /var/www/site/wp-content/uploads/smartcloud-static-publisher/logs/queue-runner-cron.log 2>&1

Deployment-Profile​

Static Publisher behandelt oberste Ziele als Basistarget. Zusatzziele leben in deploymentProfiles und werden bei deploy oder invalidate gewählt.

Das ermöglicht:

  • einmal crawlen,
  • Deployment auf Basistarget,
  • dieselben Artefakte für Staging, Produktion oder kunden-spezifische Ziele wiederverwenden,
  • zwischen Promotion-Schritten auf erneutes Crawling zu verzichten.

Wenn ein Profil targetOrigin ändert, ist im Rewrite-Modus besser ein absolutes Verhalten zu wählen, damit das bereits gecrawlte Artefakt sicher umgehängt werden kann.

Protokolle und Wiederholungsablauf​

  • Root-Logfiles sind aktueller Arbeitsset,
  • abgeschlossene, fehlgeschlagene und gestoppte Jobs archivieren GZIP-Logs und job.json,
  • retry-timeouts nutzt bei Bedarf die neueste archivierte vollständige crawl oder publish Ausführung,
  • alte Archive sollten über publisher-exporter prune-logs in einem Retentionsjob bereinigt werden.

Wiederholungen der Inhaltssynchronisierung behalten denselben beanspruchten Bereich und Prüfpunkt. Die begrenzte Wartezeitstrategie verhindert, dass ein fehlerhaftes Ziel dauerhaft überlastet wird. Wird eine vorgemerkte Wiederholung in der WordPress-Oberfläche verworfen, werden lokale Pläne entfernt; der Journal-Cursor bleibt jedoch unverändert. Ein späterer Zeitplanlauf kann denselben Bereich erneut übernehmen. Die gezielte Inhaltssynchronisierung beschreibt die Sicherheitsregeln für Löschungen und Baselines.

Ausführung außerhalb des Hosts​

Wenn der WordPress Host kein Node, Playwright oder Cron ausführen kann, verarbeite die Queue auf einem anderen Host mit Zugriff auf das gleiche Runtime-Verzeichnis, oder laden Sie einen gequeueden Job-Config und spiele ihn lokal/CI erneut aus.