Hallo,
über Tante Google habe ich gerade den folgenden Beitrag gefunden. Erfahrungen damit habe ich glücklicherweise damit selbst noch nicht.
Nachtrag: Das scheint wohl auch mit dem Caching zusammenzuhängen: siehe hier: https://www.publishingblog.ch/wordpress-erscheinen-geplante-beitraege-garantiert/ und hier: https://www.project-medlan.de/?p=1483
Viele Grüße
Hans-Gerd
Auf Linux-Webservern kann ein so genannter Cron-Dienst eingerichtet werden, der zu bestimmten Zeiten (z.B. „täglich um 13:30, 17:30 und 21:30“) irgendwelche Aufgaben abarbeitet (z.B. „prüfe, ob Aktualisierungen vorliegen“).
Leider bieten nur wenige Webhoster ihren Kunden die Nutzung dieser Cron-Dienste an, weil sie den Server zusätzlich belasten. Damit WordPress trotzdem auf allen Webservern zeitgesteuerte Aufgaben (z.B. die Veröffentlichung eines Beitrags zu einem bestimmten Termin) erledigen kann, verwendet WordPress eine „Pseudo-Cron“ genannte Funktion. Dabei wird bei jedem Abruf von Webseiten geprüft, ob eine Aufgabe in der Vergangenheit liegt, die noch nicht abgearbeitet ist.
„Veröffentliche um 18:00 Uhr“ wird also erst abgearbeitet, nachdem 1.) 18:00 Uhr bereits vorbei ist und 2.) jemand die Webseite aufruft. (Der erste, der die Webseite dann aufruft, sieht den für geplanten Beitrag noch nicht. Erst bei einem erneuten Seitenabruf sollte sich der Status von „geplant“ in „veröffentlicht“ geändert haben.)
„Verpasste Planung“ ist ein Hinweis des in WordPress 5.2 eingeführten Site Health Check, dass eine Aufgabe anstand, aber in der Zwischenzeit niemand die Webseiten besucht hat – sowas kann bei weniger frequentierten Websites vorkommen. Sofern dein Webserver Cron-Dienste unterstützt, könntest du den WordPress-internen Cron mit der Zeile define('DISABLE_WP_CRON', true); in der wp-config.php abschalten und einen eigenen Abruf der WordPress-Datei wp-cron.php einrichten. Wie das genau geht, wird hier gut nachvollziehbar beschrieben: https://kinsta.com/knowledgebase/disable-wp-cron/
Wenn du mit einer leicht verzögerten Veröffentlichung wie in den letzten Jahren leben kannst, kannst du den Hinweis auch einfach ignorieren.
Ich habe mir gerade nochmal die von Hans-Gerd verlinkten Beiträge angeschaut: Scheinbar gibt es den rot ausgegebenen Fehlerhinweis schon etwas länger als den Site Health Check. Aber ansonsten gehen die Antworten eigentlich in die gleiche Richtung, dass vermutlich ein fehlender Aufruf von Webseiten die Ursache ist.
Mmm, ich veröffentlich eigentlich immer um dieselbe Zeit, eine Woche lang wurden Beiträge verpasst, dann „normalisierte“ sich das die letzten 4 Wochen wieder ohne dass ich irgendetwas geändert hätte. Der Beitrag am Sonntag, ging ohne Probleme von allein online, der heute wieder nicht. Am mangelnden Aufruf der Seite kann das eigentlich nicht liegen, die sind eigentlich seit Jahren konstant.
Thread-Starter
Bastbra
(@comicschau)
Bei mir eben auch, das hat jahrelang geklappt. Ich war vorher auf der Seite, sicher 5-mal und habe mich gefragt, warum der Beitrag nicht kommt. Dann hab ich im Admin-Bereich geschaut und da stand dann die Fehlermeldung. Das ist das erste Mal nach über 1.800 Beiträgen, dass sowas mir je passiert ist. Und WPRocket löscht den Cache ja sowieso bei Veröffentlichung eines neuen Beitrags…
Grüße,
Bastbra
Also bei mir war es das spackende Plugin BackWPup ,
siehe auch hier: https://wordpress.org/support/topic/inspyde_phone-home_checkin/
Plugin deaktiviert und wieder aktiviert und dann ging es wieder. Mal sehen wie lange …
@kuechenlatein
… das spackende Plugin BackWPup …
Der Duden liefert zu „spackend“ keinen Treffer, verweist aber auf das Substantiv „Spacken“ als Schimpfwort für „dummer Mensch“. Wie auch immer, die Bezeichung scheint für ein recht populäres Plugin, dass dir auch noch kostenlos zur Verfügung gestellt wird, recht unangebracht. Da wir diesen Umgangston hier nicht möchten, erscheinen deine Beiträge bis auf weiteres erst nach Freigabe durch eine/n ModeratorIn.
Thread-Starter
Bastbra
(@comicschau)
Würde das als „verbuggt“ interpretieren, ist so eine „Sperre“ nicht ein wenig zu viel? Oder ist @kuechenlatein schon öfter negativ aufgefallen? Auch wenn „verbuggt“ auch nicht das Netteste für ein Plugin ist, würde da nicht eine Verwarnung reichen?
Ich will mich da aber auch eigentlich gar nicht einmischen, mir wurde nur eine Benachrichtigung geschickt und ich wollte mal reingucken. Wenn gleich ich dieses Plugin nicht kenne bzw. kenne, aber noch nie genutzt habe und es nicht bewerten kann. 😀
Das ist keine Sperre, sondern ein Hinweis, dass wir uns in bestimmten Fällen vorbehalten, Beiträge vor Veröffentlichung zu prüfen, was zu Verzögerungen führen kann. Wenn sich Benutzer in weiteren Beiträgen konstruktiv einbringen, wird die Kennzeichnung genauso schnell wieder entfernt.
Es tut mir leid, ich wollte niemanden beleidigen. Im norddeutschen Slang bedeutet das Wort als Verb soviel wie „herumzicken“ oder im Sinne von Schwierigkeiten bereiten. Und Schwierigkeiten bereitete das Plugin. Es liegt mir fern, die Entwickler als dumme Menschen zu bezeichnen, denn ich habe ja sofort eine Antwort bekommen.
@kuechenlatein Danke für deine Erläuterung, die ich gerne zum Anlass nehme, die Moderation wieder aufzuheben.
Ich bin mir nicht sicher, ob das Problem mit dem Zeitplan wirklich am „herumzickenden“ Plugin liegt, oder ob das Backup zu einem Timeout geführt und dadurch den Zeitplan (Schedule) durcheinander gebracht hat. Ich bekomme beim Backup-Plugin UpdraftPlus inzwischen auch häufiger Hinweise auf Probleme mit WP-Cron, auf die ich mir aber bisher keinen Reim machen kann. Ich vermute eher einen Bug im Core.
Ich werde das weiter beobachten. Ich habe „aktiv“ an meinen Plugins nichts gändert – außer updates natürlich. Das Problem tritt genau seit 28.07.2019 auf und ab da nicht nachvollziehbar häufiger. Das geplante Backup ließ ich mit EasyCron laufen und mit der Fehlermeldung inspyde_phone-home_checkin konnte ich nichts anfangen, da die Sicherung in die Dropbox mit EasyCron pünktlich in der Dropbox gelandet war.
Für die Lösung den wp cron zu deaktivieren und die Planung anders anzustoßen, bin ich leider nicht in der Lage
… und mit der Fehlermeldung inspyde_phone-home_checkin konnte ich nichts anfangen …
Vielleicht erinnerst du dich an ET, den Außerirdischen, der auch immer nach Hause telefonieren wollte? Die Entwickler von BackWPup haben dafür sogar eine eigene PHP-Klasse „PhoneHome_CronController“ angelegt, mit der die Anrufe zuhause gesteuert werden.
Das Plugin sammelt telemetrische Daten und sendet sie, wenn du zugestimmt hast, zur statistischen Auswertung an den Entwickler. Das passiert zweiwöchig und wird über den Zeitplan von WordPress („Schedule“) durchgeführt.
(Fun-Fact: ich habe keine Option gefunden, mit der du als Benutzer die Zustimmung widerrufen kannst. Vielleicht findet da jemand anders ein Häkchen – oder hat die Sache einen Haken?)
Der Hinweis, das Plugin WP-Control zu installieren und den Eintrag von BackWPup zu löschen ist in etwa vergleichbar mit der Drucker-Queue in einem Großraumbüro, wo der Auftrag von Herrn Müller mal wieder alle MitarbeiterInnen blockiert und deshalb abgebrochen wird, damit weitergearbeitet werden kann. 🙂
Klar erinnere ich mich an ET. Danke für die ausführliche Erklärung. Seit Juli 2013 habe ich mein Blog unter WP und wohl sichere seit 04.08.August 2013 mit dem Plugin. Nie Probleme mit geplanten Beiträgen, bis zum 28.07.2019. Mir stellt sich immer die Frage, warum. Ich ändere wie gesagt nie etwas. Wenn du mit UpdraftPlus auch Probleme vermutest, dann sichere ich eben manuell mit nach Hause telefonieren
Die Sicherungen mit UpdraftPlus werden ausgeführt, obwohl ich eine E-Mail erhalte, es gäbe wohl zu wenig Besucher auf der Website um den Pseudo-Cron auszuführen.
Ich habe jetzt aber auf meinem Homeserver einen Cron-Job eingerichtet, der alle drei Stunden https://example.com/wp-cron.php?doing_wp_cron abruft. In der wp-config.php habe ich außerdem define('DISABLE_WP_CRON', true); eingetragen, wie in diesem Tutorial vorgeschlagen: https://kinsta.com/de/wissensdatenbank/wp-cron-deaktivieren/
Vielleicht hilft das.
