Ich habe einige kleines Problem mit den Analytics:
Die Zusammenfassungen „Wie viele Downloads pro Tag“ usw. werden bei neuen Folgen erst viel zu spät erstellt. Bspw. sind bereits 48 oder mehr Stunden seit der Veröffentlichung der Folge vergangen, bis die Spalte „1T“ finalisiert wird. Bis dahin werden die Downloads dort aber gezählt und ausgegraut dargestellt. Das Gleiche passiert auch für die folgenden Tage.
So wie ich es verstehe, laufen zur Erstellung der Downloadstatistiken im Podlove Publisher regelmäßig die Jobs
Download-Absichten bereinigen (Partiell), sowie
Zusammenfassung der Downloads (partiell)
Unter Podlove Werkzeuge kann ich sehen, dass sie stündlich angestoßen werden.
In der Spalte „finished“ steht ungefähr bei der Hälfte der jobs „never“ und bei den anderen ein sinnvolles Enddatum. Duration ist so < 2 Sekunden bei allen.
Unten drunter steht:
Worker Activity: 43 seconds ago
Runner Activity: vor 49 Minuten
und ein Klick auf WP-Cron-Diagnostics zeigt zwei grüne Haken „yes good“.
Ich kann die Jobs auch manuell anstoßen. Wenn ich das tue laufen sie komplett durch, alle Statistiken sind dann aktuell und verarbeitet, so wie ich es möchte. Außerdem fällt auf, dass die Downloads erst dann wirklich bereinigt sind, d.h. sie sind mal locker 20 % niedriger als die Anzeige vor dem manuellen Durchlauf der zwei Jobs.
Das lässt mich denken, dass auch „Download-Absichten bereinigen (Partiell)“ eigentlich nichts tut, sondern die dieser Job erst wirklich erledigt wird, wenn ich ihn manuell anstoße.
Ich nehme an, dass du keine speziellen Dinge unternommen hast im Bezug auf die Crons?
D.h. die laufen „einfach so mit“ wenn jemand deine Seite aufruft. Das kann auf mehrere Arten zu Problemen führen:
Deine Seite wird zu selten aufgerufen, sodass die Jobs nicht fertig werden
Du hast zu viele Downloads, dass die Jobs nicht sinnvoll fertig werden. (stichwort maximum execution time)
Ich würde mal vermuten, dass bei dir das erste Problem der Fall ist. Wenn ich das korrekt sehe, dann hostet du deinen Podcast bei Netcup. Nach deren Webseite kannst du Cronjobs anlegen in allen Paketen. Wenn du jetzt die wp-cron.php jede Minute mit einem Cronjob aufrufst, sollten deine Probleme verschwinden.
Du musst dann noch eine Einstellung in deiner wp-config vornehmen, aber das kannst du hier ganz gut nachlesen: https://wpmashup.com/wordpress-cronjob-einrichten
Das Fehlerbild mit den nicht vorhandenen und extrem ungenauen Statistiken kenne ich von einem der Podcasts, die ich bei mir hoste. Da hab ich es auf diese Weise gelöst.
Danke für die Antwort. Das ist schonmal sehr interessant. Ich habe jetzt auf die garantierte minütliche Ausführung von wp-cron.php umgestellt. Das scheint ja in keinem Fall schlecht zu sein.
Ich glaube aber, das ist nicht das Problem. Ich muss jetzt erst mal länger beobachten, weil ich im Rahmen der Tests auch wieder den „Alles von Grund auf neu“-Button geklickt habe. Aber das Protokoll der Jobs sieht weiterhin komisch aus:
Warum ist „Download-Absichten bereinigen“ „never finished“?
Würde der alte Cron-Mechanismus durch einen Podcast Download nicht auch ausgelöst werden? Ich habe das Problem auch bei 200+ Downloads am Tag. Diese Liste enthielt jedenfalls auch vorher genau stündlich die zwei Einträge für die „partielle Ausführung“ dieser Jobs, nur eben manchmal „never finished“.
Wo ich gerade dabei war, habe ich noch die max execution time von php Scripten überprüft, aber die steht bei satten 180 Sekunden und 512 MB RAM sind erlaubt. Ist das zu wenig?
Wie gesagt: Wenn ich die Jobs manuell anstoße laufen sie schnell und zuverlässig durch, daher denke ich, dass da kein Problem besteht. Irgendwie tut diese partielle Ausführung nicht alles was sie soll.
Letzter Punkt: Hier in der Doku von Podlove habe ich auch einen Eintrag dazu gefunden, der genau das beschreibt, was du auch beschreibst.
Das lässt mich vermuten, dass die Ausführung mit einem Fehler abbricht. Du kannst versuchen, Fehler-Logging anzuschalten und schauen, ob im Log etwas relevantes erscheint.
Das kann knapp sein, allerdings läuft der Komplettprozess ja durch bei dir.
Im Komplettdurchlauf sind die Zahlen auf jeden Fall „korrekter“, und sollten dann auch reproduzierbar stabil bleiben. Der partielle Prozess dedupliziert nur mit Blick auf kleine Zeitscheiben enthält daher mehr Duplikate.
OK, danke. Habe die logs gesammelt und schaue jetzt auf 23 MB von überwiegend dieser Warnung:
PHP Warning: Undefined array key "" in /wp-content/plugins/podlove-podcasting-plugin-for-wordpress/lib/modules/transcripts/renderer.php on line 105
Ganz selten ist dazwischen auch:
PHP Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /wp-content/plugins/podlove-podcasting-plugin-for-wordpress/lib/podcast_post_type.php on line 153
Direkt nach dem Aktivieren der logs kamen diese 2
PHP Deprecated: html_entity_decode(): Passing null to parameter #1 ($string) of type string is deprecated in /wp-includes/widgets.php on line 1630
PHP Deprecated: Creation of dynamic property Podlove\Settings\Analytics::$table is deprecated in /wp-content/plugins/podlove-podcasting-plugin-for-wordpress/lib/settings/analytics.php on line 109
im laufenden Betrieb dann aber nie wieder.
Ob da jetzt was relevant ist, kann ich leider auch nicht einschätzen. Kenne diesen Code gar nicht.
Das ist der einzige Treffer für eine Suche nach „analytics“.
