Zeitversetzes Bloggen - trotzdem Trackback etc.

[robert]

Wenn ich einen zeitversetzen (also späteres Datum) Beitrag schreibe und speichere, so wird er ja eben zu dem späteren Datum automatisch veröffentlicht.

Was aber nicht passt ist, dass an alle möglichen Pingserver sofort ein Ping geschickt sowie auch etwaige Trackbacks durchgefürht werden.

Insbesondere zweiteres ergibt keinen Sinn, da ein Klick in dem anderen Beitrag auf den Trackback nur auf eine leere Seite führt.

Es wäre IMHO (Gegenmeinungen herzlich Willkommen) sinnvoller, dass erst beim veröffentlichen des Eintrags zum gewählten Zeitpunkts die Pings und Trackbacks versendet werden.

MfG
Robert

[garvinhicking]

Das wäre in der Tat schön, ist aber technisch leider nicht zu realisieren.

Das Problem ist ja dass PHP abrufgesteuert ist. Entweder müsste man also minütliche Cronjobs (oder stündliche) einrichten, damits ständig nach neuen Artikel geprobed werden könnte. So Cronjobs können aber die wenigsten Benutzer einrichten.

Die zweite Möglichkeit wäre immer bei Aufruf eines Besuchers nach neuen Artikeln zu gucken. Das würdebedeuten wenn man 3 Stunden keinen Besucher hätte, würde das Trackback 3 Stunden zu spät geschickt. Ausserdem würde das die Performance für jeden Besuch erniedrigen, und der unglückliche User bei dem der Trackback ausgeführt wirdwundert sich warum er eine Minute auf seine Seite warten muss.

Wir haben das auf der Entwicklermailingliste schon öfter durchgekaut und sind leider zu keiner technisch ausführbaren Lösung gekommen...

VieleGrüße,
Garvin

[robert]

Danke für die einleuchtende Erläuterung!
Schade, aber was nicht geht geht nicht...

MfG
Robert

[robert]

Vielleicht denke ich jetzt zu simpel oder ihr habt das auch schon "durchgekaut" - aber ich probiere es mal.

Soferne ein Beitrag in der Zukunft liegt bekommt er bei der "Veröffentlichung" durch den Admin ein "Flag". Das bedeutet, dass er bei keine Pings und keine Trackbacks aussendet.

Der Admin kann in der Adminoberfläche jederzeit den Befehl "Flags checken" (nur so mal als Arbeitstitel) auslösen. Dann wird geschaut ob die "geflaggten" Beiträge nunmehr in der Vergangenheit liegen. Wenn ja schicken sie nunmehr einen Ping und Trackbacks aus, das Flag wird gelöscht. Wenn sie noch in der Zukunft liegen passiert nichts.

Ich hoffe, ich habe mich verständlich ausgedrückt.

Ich denke es ist besser ein Ping und insbesondere ein Trackback erscheint dann etwas verspätet, als wenn Pings und Tracks auf einen Artikel verweisen, den man noch gar nicht ansehen kann - das verwirrt wohl viel mehr und macht außerdem keinen guten Eindruck.

Aber man könnte das ja optional anbieten... - wenn es machbar und sinnvoll ist...

MfG
Robert

[garvinhicking]

Ich fürchte bei soviel manueller Interaktion ist es für einen Autoren viel einfacher den Artikel als "Draft" zu lassen und das der Autor den Artikel dann manuell veröffentlicht.

Ich fürchte halt, dass kein Admin einen solchen Link wirklich nutzen würde, da wäre ja der ganze schöne Automatismus im...Hinterteil

Viele Grüße,
GArvin

[robert]

Wir könnten jetzt hin und her diskutieren

Ich denke, es ist einfach statt an jedes einzelne ev. zukünftige (oder nicht mehr zukünftige) Posting zu denken, hin und wieder auf den Aktuellknopf zu drücken - ev. könnte ja die Adminstartseite anzeigen, dass man x Flags hat, die nunmehr zukünftig sind und auf den Button hinweisen.

Aber es war nur eine Idee. Was immer ihr Coder damit macht

MfG
Robert

[garvinhicking]

Sorry, ich wollte nicht so destruktiv klingen. Die Idee ist schon nett, für mich fühlt es sich aber eher als ein Workaround an als eine bessere Lösung. Und codemäßig würde das zu mehr bloat führen, da habe ich etwas Angst vor.

Aber ich lasse mir das nochmal durch den Kopf gehen

Grüße,
Garvin

[robert]

Hallo Garvin,
das ist das Problem mit rein schriftlicher Kommunikation. Die Untertöne kann man nicht lesen.
Ich habe deine Bemerkung überhaupt nicht destruktiv empfunden. Mir ist auch klar, dass nicht jede meiner Ideen gleich mal umgesetzt wird

Daher meinte ich es auch so - nimm es als mögliche Idee. Wenn ihr es sinnvoll umsetzen könnte, würde es mich freuen. Wenn nicht und ihr an anderen - ebenso wichtigen - Dingen bei s9y arbeitet ist das für mich genauso positiv.

So und jetzt schluß und auf zu anderweitigen Ideen mit s9y - dem besten Blog aller Zeiten

MfG
Robert

[Tscherno]

Hallo,

ich würde gerne die Cron-Ping-Diskussion nochmals in Gang bringen...

Hintergrund: Ich nutze das RSS-Aggregator-Plugin um meine Einträge über Stumbleupon.com zu erzeugen. Das klappt nach einem manuellen Editieren der Onyx-Lib (Umlaute durch Entities ersetzen - Der Feed wird übrigens validiert - scheint also ein Fehler in der Lib zu sein) auch wunderbar. Nun hätte ich aber gerne auch Pings gesendet. Das wird ja manuell über den Iframe beim Bearbeiten bzw. beim Posten durch aufrufen des entsprechenden Scripts gesteuert. Wird irgendwo in der DB festgehalten ob bereits für einen Eintrag gepingt wurde? Wahrscheinlich nicht, sonst müsste man nicht nochmal als Entwurf speichern...

Wäre es nicht eine Idee als Plugin folgendes zu implementieren:
- Plugin hat eigene DB-Tabelle: Eintrags-ID, Ping-Empfänger
- Plugin wird per Cron aufgerufen (Wie RSS-Aggregator)
- Bei jedem Cron-Durchlauf wird für alle Posts für die noch kein Eintrag in der Datenbanktabelle exisitert ein Ping gesendet
- War der Ping erfolgreich wird ein Eintrag erstellt

Cron sollte übrigens heutzutage auch kein Problem mehr sein. Gibt schon eine Services die kostenlos zeitgesteuert Webseiten aufrufen. Ansonsten könnte man sich noch eine Mechanik wie z.B. diverse Foren überlegen, die bei jedem "normalen" Besuch der Seite untersuchen ob ein Cron ansteht und diesen dann durchführen (iframe oder innerhalb des Scripts).

Mich würde euere Meinung dazu interessieren.

[garvinhicking]

Tscherno,

soweit ist das korrekt, ja. Die Pings werde nur beim switchen von draft->publish, oder beim neuerstellen eines eintrages gespeichert.

Somit müsste also das zu bauende Plugin bei neuen Artikeln die Erstellung eines Pings unterdrücken, wenn das Datum noch nicht erreicht wurde - und dann würde ich den Eintrag in der PLugin-eigenen Tabelle vornehmen, der dann vom crontab plugin vorgenommen wird.

So ein Plugin wäre also sicherlich etwas nettes. Wenn dafür noch neue Hooks in den Core übernommen werden müssen, kann ich die gerne einbauen.

Wenn Du das Plugin angehen solltest, würde ich mich über eine kurze Nachricht sehr freuen so dass wir es ins Repository aufnehmen könnten, wen Du magst.

Viele Grüße,
Garvin

[Tscherno]

In die Richtung zielte die Überlegung ja. Ein erstes Problem hab ich glaub ich auch schon. Wenn ich das richtig sehe ist die Funktionialität für die Pings in einem Plugin (serendipity_event_weblogping). Wie ist der Standard bei Plugins bzgl. sowas? Sollte man auf das vorhandene Plugin zurückgreifen, die Funktionalität kopieren oder das ganze in eine Library auslagern?

[garvinhicking]

Es gibt hier zwei Dinge die man trennen muss: XML-RPC Pings und Trackbacks.

Pings werden vom weblogping plugin durchgeführt. Trackbacks werden vom s9y core vorgenommen, aber plugins wie serendipity_event_trackback (additional_plugins) können da seit serendipity 0.9 auch etwas eingreifen.

Jedenfalls wäre es schön, ähnliche Funktionalität in bestehende Plugins zu integrieren - insofern wäre es toll, das bestehende Ping- und Trackbackplugin anzupassen so dass diese zeitgesteuertes track/pingbacking übernehmen könnten, genau.

Viele Grüße,
Garvin

[Guest]

Mir ist gerade noch ein anderer Ansatz eingefallen. Leider kenne ich die Internas von Serendipity noch nicht gut genug um zu beurteilen ob es klappt:

Es gibt doch Events bzw. Plugin-Hooks. Wäre es nicht denkbar ein Plugin oder Core-Erweiterung zu bauen, die über Cron aufgerufen wird und ein "Cron" Event aufruft? Daran könnten sich doch dann alle möglichen Plugins hängen... Die Ping/Trackback-Funktionen müssten natürlich trotzdem angepasst werden, aber IMO wäre es sowieso sauberer wenn sich diese "merken" würden was sie schon gesendet haben.

[Tscherno]

Sorry Login vergessen. Wir können gerne auch im Englischen Developer-Forum darüber weiter disktuieren, wenn Du möchtest.

[garvinhicking]

Jein, prinzipiell gibt es ja schon einen CRON-Hooks, nämlich frontend_configure. Dieser wird auf jeder Seite aufgerufen.

Das Problem ist einfach, man kann keinen einfachen "CRON"-Mechanismus in PHP abbilden, weil PHP-Scripts ja ihren Aufrufzeitpunkt nicht bestimmen können. Es kann ja theoretisch sein, dass Dein Blog nur alle 2 Stunden einen Besucher bekommt - dann würde der Cronjob nicht stündlich ausgeführt werden können.

Daher ist es wichtig, dass das Plugin einfach einen externen Event anbietet (wie das popfetcher plugin), so dass man per cronjob eine URL aufrufen kann wie:

http://yourblog/serendipity/plugin/cron_trackback

Dann kann das Trackback-Plugin auf den external_plugin hook lauschen, und wenn ein cron_trackback aufruf reinkommt, seine Aktionen ausführen (nachdem es geprüft hat, wie spät es wirklich ist und ob der Zeitpunkt des letzten Aufrufs ungefähr der gewünschten Zeitspanne entspricht).

Viele Grüße,
Garvin