it-swarm.com.de

zeitstempel und geplante Unregelmäßigkeiten nach dem Versand

Update: Ich habe das Problem bestätigt (geplante Posts basieren auf der UTC-Zeit) und benötige jetzt nur noch Ratschläge und Hintergrundinformationen, um die beste Lösung zu finden. Fragen:
1) wie WP die UTC-Zeit bestimmt, bevor der lokale Zeitzonenversatz berechnet wird (dh verwendet es die Server-OS-Zeit oder eine andere Quelle - kann finde ich nicht im Codex/googeln)
.. das würde mir helfen zu antworten ..

2) ist die Umstellung der Serverzeit von UTC auf lokales PST die einzige/beste Methode, um geplante Posts mit derselben Zeitzone wie die WP-Zeit zu versehen? und
2a) Gibt es mögliche negative Auswirkungen auf die Umstellung der Serverzeit von UTC auf lokal?
3) Wie ändere ich die Serverzeit am besten genau - wenn ich eine Uhr stelle, muss sie nicht genau richtig sein, aber Ich würde mir Sorgen machen, die Uhrzeit auf einem Server manuell einzustellen.

Hallo zusammen-

Problem: Erstens hat WP damit begonnen, geplante Posts nicht zu veröffentlichen. Dies scheint ein weit verbreitetes Problem zu sein, und ich habe es mithilfe des Plugins "Missed Schedule" behoben. Dies ist wahrscheinlich, aber nicht unbedingt, irrelevanter Hintergrund.

Kurz nach dem Umzug auf einen neuen Server hat WP frühzeitig mit der Veröffentlichung geplanter Posts begonnen, was für mich nur auf falsch konfigurierte Zeit-/Datumseinstellungen irgendwo in unserem Stapel hinweisen kann.

Stack: LNMP, eine Nginx-Box, eine DB/Memcache/PHP-Box (obwohl ich es nicht gebaut habe und nicht bauen konnte)

Soweit ich weiß, gibt es 4 Stellen in unserem Stack, an denen die Zeit festgelegt wird: in den allgemeinen WordPress-Einstellungen (auf PST gesetzt, zeigt aber auch die UTC-Serverzeit korrekt an) für PHP5 in der Datei php.ini (auf zentral gesetzt) Zeit, in der sich der neue Server befindet, aber ich habe auf PST aktualisiert und php-fpm neu gestartet, sobald ich festgestellt habe, dass PHP5 eine Zeitzoneneinstellung hat, die die Diskrepanz um 2 Stunden verringert Angenommen, es ist in Ordnung, weil WP es als solches erkennt und trotzdem seine "eigene" Zeit einstellen kann.

Momentan beobachte ich jedoch etwas, was nicht möglich sein sollte. Ein Beitrag sollte um 9:30 Uhr (UTC) veröffentlicht werden. Er wurde jedoch um 1:30 Uhr (UTC) veröffentlicht. Dies führte dazu, dass der relative Zeitstempel "Veröffentlicht vor X" auf dem Post ab 8 Stunden rückwärts gezählt wurde und dann um 9:30 Uhr pst. Wieder hochgezählt wurde. Für mich bedeutet dies, dass der Post Scheduler (anscheinend) auf die (korrekt konfigurierte) lokale WP Zeit (wie das Frontend) achten sollte, stattdessen aber die UTC-Zeit (Server) verwendet.

Lösungsmöglichkeiten:
EIN. Stellen Sie das Betriebssystem beider Boxen sowie PHP und alle WP Blogs so ein, dass nur UTC-Zeit verwendet wird, und weisen Sie alle Editorials an, in UTC zu leben.
B. Setzen Sie das Betriebssystem beider Boxen auf PST zurück, damit es mit PHP und WP übereinstimmt. Es scheint so, als wäre dies wahrscheinlich die Lösung (seit der Veröffentlichung des Posts auf Server/UTC-Zeit) , aber ich bin ein * nix n00b und möchte nur sicherstellen, dass ich es verwenden soll 'date -s' und versuche einfach, so genau wie möglich zu sein oder wenn es klüger wäre, einfach ein Host-Support-Ticket zu hinterlassen, das sie auffordert, die Zeiten beider Server mit PST zu synchronisieren? (oder wenn es einen besseren Weg gibt, genau zu sein)

Was ich nicht bekomme:
EIN. Warum ignoriert der Post Scheduler die "WP-Zeit", um zu berechnen, wann veröffentlicht werden soll? (Update: Ich denke, die Antwort ist hier: http://codex.wordpress.org/Function_Reference/wp_schedule_event - es analysiert die Zeit direkt über den Unix-Zeitstempel, anstatt über wp?)
B. Warum müssen WP Einstellungen die UTC-Zeit von der Ortszeit trennen, wenn nicht alle Funktionen die Zeit aus derselben Quelle berechnen?

Warum ist dies ein Problem:
Wir haben 15 Sites mit primären Site-Benutzern in verschiedenen Zeitzonen. Im Idealfall könnten sie WP "Ortszeit" pro Blog festlegen und alle Post-Scheduling-Funktionen von dieser angegebenen Zeit abhängig machen. Wenn die Planung auf der Serverzeit basiert, scheint dies unmöglich zu sein.

Für den Anfang versuchen Sie Core Control Plugin, um zu sehen, ob geplante Aufgaben richtig zugewiesen sind. Geplante Posts werden als publish_future_post> check_and_publish_future_post() mit der ID des Posts als Argument angezeigt.

2
Rarst