Support » Allgemeine Fragen » Verpasste Planung: wegen externen wp-cron Aufruf?

  • Gelöst pezi

    (@pezi)


    Hallo!

    Vorgeschichte:
    Auf einer unserer Sites wurde vor längerem dies angewendet: https://wpwissen.com/wordpress-echten-cronjob-verwenden/
    meinesite.xy/wp-cron.php wird seither von einem externen Cronjob-Dienst angestoßen. (Meiner Meinung nach sollte dies keinen Unterschied machen, ob WP Cron seine intervallgesteuerte Arbeit macht, oder ein externer Dienst dies per „Zeitschaltuhr“)

    Es ging ja auch alles vmtl. damit zusammenhängende auf der Site: wp_version_check, wp_update_themes, usw. funzt. Ebenso die „eignen Ereignisse“ (zB. Feeds Abruf) sind ok.

    Problem:
    Heute sollte ein geplanter Beitrag erscheinen – tat er aber nicht …
    Also wieder mittels WP Crontrol nachgesehen und einen (leider nicht mehr zu sehenden) Eintrag manuell angestoßen, der darauf schließen ließ, dass er geplante Beiträge checkt und ggf. veröffentlicht: Kein Erfolg.

    Also:
    Bis auf die Veröffentlichung geplanter Beiträge funktionieren alle Cronjobs auch nach DISABLE_WP_CRON mittels externen Anstoßen.
    Kurze Frage einer langen Einleitung: Warum ist das so?

    Zusatzfrage: Wo findet man eine Liste aller Cron-Ereignisse? (Will einfach nur den Namen jenes verschwundenen Eintrages wieder finden, der die geplanten Beiträge checkt, veröffentlicht)

    Danke für etwaige Infos!

    PS: Wenn ich länger nicht antworte, liegt das daran, das seit einigen Tagen bei Antworten auf abonnierte Threads keine Mails mehr kommen.

Ansicht von 11 Antworten - 1 bis 11 (von insgesamt 11)
  • Thread-Ersteller pezi

    (@pezi)

    UPDATE: Das gesuchte Ereignis fand ich hier und es heißt publish_future_post und ist nur in der Liste, wenn ein Beitrag den Status Planung hat.

    Und was noch auffällt:
    Jeder externe Aufruf der wp-cron wird von jedem externen Dienst schon nach einem Versuch abgestellt. (Selbst wenn man einstellt, das erst nach 5 gescheiterten Versuchen deaktiviert werden darf – hier scheint also was gehörig schief zu laufen)
    Und dies passiert auch, wenn man es per Cronjob vom Hoster aus macht. Letzterer sucht auch nach einer Erklärung …

    Hallo,
    kennst du das Plugin WP Crontrol? – Mit WP Crontrol kannst du sehen, was im WP-Cron-System passiert und du kannst entsprechend eingreifen. Wir haben das auch auf einer Webseite im Einsatz, bei der wir vor Urzeiten mal Probleme ähnlicher Art hatten.
    Viele Grüße
    Hans-Gerd

    Meiner Meinung nach sollte dies keinen Unterschied machen, ob WP Cron seine intervallgesteuerte Arbeit macht, oder ein externer Dienst dies per „Zeitschaltuhr“

    Die meisten Webhoster verzichten bei preiswertem Shared Hosting darauf, ihren Benutzern/-innen die Einrichtung von Cron-Jobs zu ermöglichen, weil das den Server unnötig belasten und damit entweder die Performance stören würde oder (in Folge) eine Reduzierung der Kunden pro Server zur Folge hätte. Die Core-Entwickler wollten aber dem durchschnittlichen Benutzer nicht die Einrichtung von Cron-Jobs bei Drittanbietern zumuten, weshalb als Standard ein Pseudo-Cron verwendet wird: bei jedem Seitenaufruf wird nachgeschaut, ob bereits anstehende Aufträge wie die Veröffentlichung eines Beitrags abgelaufen sind (!), um sie dann nachträglich auszuführen. Nachteil ist, dass die Ausführung nicht (wie bei Cron-Jobs üblich) zu einem festgelegten Zeitpunkt ausgeführt wird, sondern eben erst nach dem nächsten Website-Besuch. Legst du den Veröffentlichungstermin eines Beitrags auf den 1. Oktober, der nächste Besucher kommt aber erst am 3. November, wird der Beitrag auch erst am 3. November veröffentlicht. Mit define( 'DISBALE_WP_CRON', true) deaktivierst du den Pseudo-Cron dauerhaft.

    Installierst du nun auf deinem (oder einem externen Server) einen Cron-Job, sollte das Problem grundsätzlich behoben sein. Nun schreibst du aber, dass „Jeder externe Aufruf der wp-cron […] von jedem externen Dienst schon nach einem Versuch abgestellt [wird]“. Hier wäre interessant, was ein Aufruf der Datei zurückgibt. Mit curl --head https://example.com kannst du in einem Terminal den Header des HTML-Dokuments abrufen und siehst anhand des Rückgabewerts, ob die Anfrage sauber durchläuft:

    ❯ curl --head https://example.com
    HTTP/2 200
    server: nginx/1.14.2
    date: Thu, 22 Jul 2021 07:32:08 GMT
    content-type: text/html; charset=UTF-8
    …

    In diesem Fall wurde ein Code 200 (Alles OK) zurückgegeben. Ein Code 404 würde auf eine unvollständige WordPress-Installation hinweisen, 403 auf Probleme mit Dateiberechtigungen, 500 auf Programmierfehler in einer geänderten Datei usw.

    Für die Frage „Welche Cron-Jobs stehen an und sollen in Kürze ausgeführt werden“ ist das von Hans-Gerd bereits genannte Plugin WP Crontrol bestens geeignet.

    Thread-Ersteller pezi

    (@pezi)

    @hage

    kennst du das Plugin WP Crontrol?

    ja, daraus stammen ja einige der Infos im Eröffnungspost (s.: „Also wieder mittels WP Crontrol nachgesehen …“)

    @pixolin Alles aus dem ersten Absatz ist mir geläufig.
    Und wir können Cronjobs beim Hoster anlegen, haben auch aber auch einen externen Dienst.

    kannst du in einem Terminal den Header des HTML-Dokuments

    Kann ich nicht, aber unser Hoster hat das 2x gecheckt:
    1. als ich (wie bisher) ‚DISBALE_WP_CRON‘ noch auf ‚true‘ ließ: es kam kein Fehler, eh ein 200er. Und alles (außer publish_future_post) wird erledigt; WP Crontrol zeigt alles ok.
    2. nach Reaktivierung des WP Pseudocron: Status 403 und alle Ereignisse werden in WP Crontrol rot markiert.

    Fazit:
    Per externen Cron geht bloß die Veröffentlichung geplanter Beiträge nicht
    Per internen WP Cron geht (scheinbar?) nichts mehr richtig …

    So haben wir am WE einiges mehr zu tun, als die Updates auf 5.8 …

    Moderator Bego Mario Garde

    (@pixolin)

    Alles aus dem ersten Absatz ist mir geläufig.

    Dir vielleicht, aber anderen die mitlesen vielleicht nicht. Da wir versuchen, möglichst vielen Anwender/-innen zu helfen, hab ich mir die Mühe gemacht, das nochmak zu erklären. Da ich weiß, dass Profis wie du sich bestens auskennen, hätte ich das vielleicht noch dazu schreiben sollen. Hab ich hiermit nachgeholt. 🙂

    Thread-Ersteller pezi

    (@pezi)

    Die Sache ist mir „geläufig„, mehr nicht. (Und das bissl weiß ich nur von hier)

    möglichst vielen Anwender/-innen zu helfen

    auch bekannt, Danke im Namen aller!
    Aber ich glaube, diese Erklärungen muss man gerne machen.
    Denn ich hätte da immer im Hinterkopf: „99 % schlagen mit der gleichen Frage auf, statt hier nach den 99x geposteten Erklärungen zu suchen … für was also?“ (oder sie reden nachher neunmalklug daher, das es ihnen „eh geläufig“ ist …)

    PS: Danke für meine Status-Beförderung 😉

    PS2: Jetzt weiß ich „Profi“ in der Sache noch immer nicht weiter

    PS3: Wann kommen wieder Mail-Verständigungen bei abonnierten Beiträgen?

    Hallo,

    PS3: Wann kommen wieder Mail-Verständigungen bei abonnierten Beiträgen?

    Teste das doch mal bitte bei dir: Wenn du auf einen Beitrag erstmals antwortest, dann sollte sich der Status rechts in der sidebar auf „Abonnement beenden“ ändern. Bevor du eine Antwort geschrieben hast, steht da „Abonnieren“.
    Sonst vielleicht auch noch mal im Profil unter „Edit Notification Settings“ ganz unten die Einstellungen prüfen:
    Settings
    Receive notifications by email?
    Receive notifications by Slack direct message?

    Viele Grüße
    Hans-Gerd

    Thread-Ersteller pezi

    (@pezi)

    Der Status stimmt wie immer, auch dessen Änderung nach der ersten Antwort ist „Abonnement beenden“ da.

    Im Profil > Settings habe ich nur
    Receive notifications by email?, was natürlich angehakt ist.
    Habe es nun mal deaktiviert, gespeichert und wieder aktiviert. Mal sehen …

    Thread-Ersteller pezi

    (@pezi)

    Nachtrag zum Thema Cronjob Fehler selbst:

    Unser Hoster hat die Sache diese Nacht über nochmal intensiver untersucht.
    Anhand der dort testweise angelegten Cronjobs kam heraus, dass auch(*) deren interne Serveradresse gesperrt wird, weil jener Server, wo die Site liegt, denkt, dies käme aus einem per GeoIP gesperrten Land … Warum das so ist, wird noch ermittelt.
    Also habe ich mal testweise alle Geosperren auskommentiert und sofort laufen alle Ereignisse fehlerfrei durch.

    *) Auch, weil dies ganz genauso beim externen Cronjob Dienstleister so war.

    Um wieder von diesem, eigentlichen Host-Problemen auf WP selbst zu kommen:
    Noch ist uns allen unklar, warum der interne WP Pseudocron weiterhin (auch nach Deaktivierung der Geosperren) noch mehr Fehler wirft …

    Thread-Ersteller pezi

    (@pezi)

    Einen habe ich noch – die Teillösung:

    1.) lt. Hoster wurde die oben erwähnte GeoIP Sperrung durch eine falsche IP/Länder Zuordnung, welche in einer externen DB ist, ausgelöst.
    2.) Man soll den Parameter ?doing_wp_cron an den externen Aufruf der wp-cron anhängen

    Wie auch immer, die Sache ist teilweise gelöst.
    Sollte ich wieder mal auf internen WP Pseudo-Cron umstellen, versuchen wir es ggf. wieder zuerst mithilfe des Hosters, bzw. eröffne ich evtl. einen Thread hier.

    Danke für die Infos.

Ansicht von 11 Antworten - 1 bis 11 (von insgesamt 11)