Neues Microblog Plugin für die Sidebar

[garvinhicking]

Hi!

So, hab's gerade getestet.

Meine Anmerkungen:

1. Noch heißt das plugin serendipity_plugin_microblog, das müsste zum updaten dann ja alles mitsamt Classname in serendipity_plugin_twitter überführt werden. Das ChangeLog könnte dann auch überführt werden, die Versionsnummer sollte dann 1.0 oder so werden (also höher als 0.7). Die alten Sprachkonsten könnten dann weiterverwendet werden und auch *_TWITTER_* heißen

2. Die Twitter-API Klasse braucht PHP5. Bitte stelle im Plugin sicher, dass die Klasse nur geladen wird wenn PHP5 auch wirklich zur Verfügung steht. Ohne PHP5 sollte das Plugin dann auf JS defaulten. Serendipity läuft noch auf vielen PHP4-Hosts. Es ist okay, wenn dort die PHP-Klasse nicht als Option zur Verfügung steht sondern nur JavaScript. Die Requirements für das Plugin würde ich dann wieder auf PHP4 setzen. Im Plugin selbst müsste das try/catch/throw/protected dementsprechend auch in die PHP5-Klassendatei ausgelagert und angesprochen werden.

3. json_encode steht leider für PHP4 nicht zur Verfügung. Da das JS-Fallback aber mit PHP4 klappen muss, müsste man hier eine eigene json_encode funktion im Userspace emulieren. Auf http://de2.php.net/json_encode gibt es dazu Beispielcode der klappen müsste.

4. Die check_table funktion nutzt derzeit MySQL Syntax. Bitte benutze für die grobe Struktur die Vorlage aus dem alten Twitter-Plugin (longtext, etc.) Das ALTER TABLE müsste man auf kompatibles SQL für sqlite und pgsql umstellen, sprich nicht auf SHOW FIELDS setzen sondern das ALTER einfach ausführen. Wnn die Tabelle die Spalten schon hat, ist die Fehlermeldung ja eh ignorierbar. Um zu prüfen ob check_talbe das ALTER TABLE ausführen soll,w ürde ich wie folgt vorgehen:

Code: Select all

function check_table() {
    $ver = $this->get_config('dbversion', 0);
    if ($ver > 0) return true;
    
    .... DB erstellung (Fehlermeldung ignorieren wenn Tabelle besteht) ...
    
    .... ALTER TABLE ...
    $this->set_config('dbversion', 1);
    return true;
}

5. Bitte die ` backticks in allen SQL-Abfragen rausnehmen, damit es in pgsql und sqlite keine probleme gibt

6. Bitte die Konfigoptionsnamen soweit an die Namen des alten Plugins anpassen (showformat statt presenter, Werte "javascript" und "PHP", backup statt backup_entries). Sonst wundern sich die Leute bei nem Backup warum ihre alten Optionen nicht mehr gültig sind.

7. Ist es möglich die Zeitoptionen auf strftime statt date umzustellen? strftime unterstützt lokalisierte Datumsnahmen wie "Freitag", denn dass haben früher viele User genutzt. Auch muss man daran denken dass früher Leute ein % in die Option eingetragen haben, das wäre jetzt mit date() nicht mehr parsebar.

8. Es gibt einen Typ in "Backup your entrieds". GGf. könnte man hier die Originaltexte nehmen, so dass auch das "experimentelle" in der Backup-Option weiterhin Bestand hat.

9. Der Rest scheint super zu funktionieren. Sowohl PHP als auch JS (IE8, FF3, Safari) klappen. Cool. Und das Parsen klappt auch, das ist ja mal ne geniale Verbesserung auch.

Bis hierhin schonmal tausend Dank für Deine Beständigkeit. Wenn Du den Rest auch noch anpassen könntest wäre das spitze.

Viele Grüße,
Garvin

[Dr. Love]

1. Noch heißt das plugin serendipity_plugin_microblog, das müsste zum updaten dann ja alles mitsamt Classname in serendipity_plugin_twitter überführt werden. Das ChangeLog könnte dann auch überführt werden, die Versionsnummer sollte dann 1.0 oder so werden (also höher als 0.7). Die alten Sprachkonsten könnten dann weiterverwendet werden und auch *_TWITTER_* heißen

Hmm, ja, stimmt. Aber erst mal weiter überlegen.

2. Die Twitter-API Klasse braucht PHP5. Bitte stelle im Plugin sicher, dass die Klasse nur geladen wird wenn PHP5 auch wirklich zur Verfügung steht. Ohne PHP5 sollte das Plugin dann auf JS defaulten. Serendipity läuft noch auf vielen PHP4-Hosts. Es ist okay, wenn dort die PHP-Klasse nicht als Option zur Verfügung steht sondern nur JavaScript. Die Requirements für das Plugin würde ich dann wieder auf PHP4 setzen. Im Plugin selbst müsste das try/catch/throw/protected dementsprechend auch in die PHP5-Klassendatei ausgelagert und angesprochen werden.

3. json_encode steht leider für PHP4 nicht zur Verfügung. Da das JS-Fallback aber mit PHP4 klappen muss, müsste man hier eine eigene json_encode funktion im Userspace emulieren. Auf http://de2.php.net/json_encode gibt es dazu Beispielcode der klappen müsste.

Irgendwie weigere ich mich, extra Code zu bauen und Zeit zu investieren, um die Leute mit PHP4 zu berücksichtigen. Ein Kernfeature meiner Version des PlugIns ist nun eben, dass ich auf PHP5 setze, was Fehlerbehandlung. etc angeht. Das ist son Prinzipding: Wer sich mit PHP4 der Weiterernwicklung enjtziehen will, kann IMHO halt nicht von der Weiterentwicklung profitieren und wer PHP4 einsetzen muss, sollte mal schleunigst über einen Wechsel des Hosters nachdenken. Und bisherige Twitter PlugIn funktioniert ja weiterhin...

Stürzt das aktuell ab, wenn jemand PHP4 hat oder lässt es sich wegen der Versionsangaben einfach nicht installieren? Ich schau mir das noch mal an und gucke, wieviel Arbeit und Umstellung das wäre und ob man auf sinnvolle Sachen verzichten müsste (erst mal ein PHP4 auftreiben). Sollte das im Vorbeigehen zu lösen sein, kann ich PHP4 insofern berücksichtigen, dass zumindest das JavaScript funktioniert. Sollte PHP4 aber größere Umstellungen erfordern (etwa, damit der Parser nicht stehen bleibt), werde ich das aber nicht tun. Ich hab weder Lust noch Zeit mich mit dem Ewiggestrigen zu befassen und das Neue sollte keinesfalls darunter leiden.

4. Die check_table funktion nutzt derzeit MySQL Syntax. Bitte benutze für die grobe Struktur die Vorlage aus dem alten Twitter-Plugin (longtext, etc.) Das ALTER TABLE müsste man auf kompatibles SQL für sqlite und pgsql umstellen, sprich nicht auf SHOW FIELDS setzen sondern das ALTER einfach ausführen. Wnn die Tabelle die Spalten schon hat, ist die Fehlermeldung ja eh ignorierbar. Um zu prüfen ob check_talbe das ALTER TABLE ausführen soll,w ürde ich wie folgt vorgehen:

Code: Select all

function check_table() {
    $ver = $this->get_config('dbversion', 0);
    if ($ver > 0) return true;
    
    .... DB erstellung (Fehlermeldung ignorieren wenn Tabelle besteht) ...
    
    .... ALTER TABLE ...
    $this->set_config('dbversion', 1);
    return true;
}

5. Bitte die ` backticks in allen SQL-Abfragen rausnehmen, damit es in pgsql und sqlite keine probleme gibt

Guter Hinweis, wird gemacht.

6. Bitte die Konfigoptionsnamen soweit an die Namen des alten Plugins anpassen (showformat statt presenter, Werte "javascript" und "PHP", backup statt backup_entries). Sonst wundern sich die Leute bei nem Backup warum ihre alten Optionen nicht mehr gültig sind.

7. Ist es möglich die Zeitoptionen auf strftime statt date umzustellen? strftime unterstützt lokalisierte Datumsnahmen wie "Freitag", denn dass haben früher viele User genutzt. Auch muss man daran denken dass früher Leute ein % in die Option eingetragen haben, das wäre jetzt mit date() nicht mehr parsebar.

Es hatte seinen Grund, warum ich das PlugIn vollständig neu und unabhängig konzipiert habe. Punkt 6 ist OK, Punkt 7 finde ich lästig. Normalerweise benötigt man die lokalisierten Wochentagsnamen nicht, weil sich das PlugIn selber darum kümmert. Möchte man die trotzdem haben, muss man mit set_locale arbeiten, was laut den Kommentaren im PHP Handbuch nicht so sehr verlässlich sein soll. Das wichtigste Problem ist hier aber, dass das JavaScript das dann nicht kann und immer englische Strings ausgibt. Dass der Datumsstring jetzt anders ist, ist natürlich lästig, das sehe ich ein. Ich schau mir das also noch mal an.

8. Es gibt einen Typ in "Backup your entrieds". GGf. könnte man hier die Originaltexte nehmen, so dass auch das "experimentelle" in der Backup-Option weiterhin Bestand hat.

Wie gesagt: Dass das PlugIn nicht Twitter sondern Microblog heißt, war schon Absicht. Ich fixe den Typo in der Sprachdatei und füge das "Experimentell" da wieder ein.

9. Der Rest scheint super zu funktionieren. Sowohl PHP als auch JS (IE8, FF3, Safari) klappen. Cool. Und das Parsen klappt auch, das ist ja mal ne geniale Verbesserung auch.

Schön, dass das alles klappt, hab auch lange dran gesessen.

[garvinhicking]

Hi!

Irgendwie weigere ich mich, extra Code zu bauen und Zeit zu investieren

Okay, um die PHP4-Kompatibilität würde ich mich dann im nachhinein kümmern.

Stürzt das aktuell ab, wenn jemand PHP4 hat oder lässt es sich wegen der Versionsangaben einfach nicht installieren?

Es lässt sich in dem Fall nicht neu installieren, aber ich glaube dass ein Upgrade des bestehenden Plugins dann fehlschlagen würde. Sprich, wenn ein Plugin einmal installiert wurde, geht der Installer davon aus dass Folgeversionen auch kompatibel sind. Aber das habe ich niht exakt nachgeschlagen.

Ich schau mir das noch mal an und gucke, wieviel Arbeit und Umstellung das wäre und ob man auf sinnvolle Sachen verzichten müsste (erst mal ein PHP4 auftreiben). Sollte das im Vorbeigehen zu lösen sein, kann ich PHP4 insofern berücksichtigen, dass zumindest das JavaScript funktioniert. Sollte PHP4 aber größere Umstellungen erfordern (etwa, damit der Parser nicht stehen bleibt), werde ich das aber nicht tun. Ich hab weder Lust noch Zeit mich mit dem Ewiggestrigen zu befassen und das Neue sollte keinesfalls darunter leiden.

PHP4-Support für den PHP-Tweetparser ist auch nicht nötig, das seh ich auch ein. Aber dass der JS-Fallback nicht klappt ist eigentlich nicht nötig, man muss es den Leuten ja nicht übermäßig schwer machen

Es hatte seinen Grund, warum ich das PlugIn vollständig neu und unabhängig konzipiert habe. Punkt 6 ist OK, Punkt 7 finde ich lästig. Normalerweise benötigt man die lokalisierten Wochentagsnamen nicht, weil sich das PlugIn selber darum kümmert. Möchte man die trotzdem haben, muss man mit set_locale arbeiten, was laut den Kommentaren im PHP Handbuch nicht so sehr verlässlich sein soll. Das wichtigste Problem ist hier aber, dass das JavaScript das dann nicht kann und immer englische Strings ausgibt. Dass der Datumsstring jetzt anders ist, ist natürlich lästig, das sehe ich ein. Ich schau mir das also noch mal an.

Inwiefern kümmert sichdas Plugin selbst darum? Wenn ich z.b. bie jedem Tweet die Ausgabe "Samstag, 1. April 2008" haben will, wie würde ich das machen?

Serendipity selbst setzt das locale ja bereits, daher nutzt s9y auch überall strftime. Hm, ich hab den alten Code gerade jetzt nicht zur Hand, ich glaube da wurde das Datumsformat generell nur in PHP angewendet, oder?

Könnte man nicht das PHP-geparste Datum an den json_encode String durchreichen, und dann das Datum garnicht über JS parsen sondern direkt im Klartext von PHP aus durchreichen?

Wie gesagt: Dass das PlugIn nicht Twitter sondern Microblog heißt, war schon Absicht. Ich fixe den Typo in der Sprachdatei und füge das "Experimentell" da wieder ein.

Super, danke!

Viele Grüße,
Garvin

[Dr. Love]

PHP4-Support für den PHP-Tweetparser ist auch nicht nötig, das seh ich auch ein. Aber dass der JS-Fallback nicht klappt ist eigentlich nicht nötig, man muss es den Leuten ja nicht übermäßig schwer machen

Wie gesagt, wenn da zu viel umgestellt werden müsste, scheiß ich drauf. Btw. setzt das alte Twitter-Plugin doch auch PHP5 voraus.

Inwiefern kümmert sichdas Plugin selbst darum? Wenn ich z.b. bie jedem Tweet die Ausgabe "Samstag, 1. April 2008" haben will, wie würde ich das machen?

Das nicht, aber "Geschrieben am Freitag um 13:25 Uhr" (wenn das älter als vorgestern und jünger als eine Woche ist) macht das PlugIn selber, auch im JavaScript.

Serendipity selbst setzt das locale ja bereits, daher nutzt s9y auch überall strftime. Hm, ich hab den alten Code gerade jetzt nicht zur Hand, ich glaube da wurde das Datumsformat generell nur in PHP angewendet, oder?

Könnte man nicht das PHP-geparste Datum an den json_encode String durchreichen, und dann das Datum garnicht über JS parsen sondern direkt im Klartext von PHP aus durchreichen?

Gutgutgut, ich stelle das auf strftime um, hast ja Recht. Das geparste Datum via JSON durchreichen wird nicht klappen, weil das PlugIn die Einträge ja gar nicht zu sehen bekommt und da nix parsen kann. Aber ich hab ne Idee: Dazu müsste ich aber die eingebundene Funktion vom PHPJS-Projekt (sofern die strftime überhaupt startklatr haben) anpassen, was mir nicht gefällt. Vielleicht scheißen wir da einfach drauf und die Wochentage sind in Gottes Namen auf Englisch.

[garvinhicking]

Hi!

Btw. setzt das alte Twitter-Plugin doch auch PHP5 voraus.

Gna. Du hast sogar recht. War mir garnicht bewusst. Nun gut, dann lassen wir es bei PHP5, wenn das eh noch keiner bemäkelt hat.

Gutgutgut, ich stelle das auf strftime um, hast ja Recht.

Das wäre toll, denn wenn Ausgaben wie "Freitag" eh lokalisiert drin sind, müsste das ja auch mit strftime quasi genauso greifen...

Grüße,
Garvin

[Dr. Love]

Also, ich habe Deine Änderungswünsche jetzt drin:

1. strftime() statt date()

2. backup_entries heißt jetzt backup und presenter heißt jetzt showformat

3. Der Datenbank-Code hat keine Backticks mehr und ich habe Deine anregungen hierzu übernommen. Wäre gut, wenn das mal jemand in SQLite und pgSQL testen würde.

4. ein paar kleine Änderungen.

Aber jetzt viel Spaß beim Testen und immer her mit den Bugreports.

Edit: Vergesst das mit dem IE6 Fehler, lag an einer falschen Zeichenkodierung der Datei. Datei neu hochgeladen.

[garvinhicking]

Hi!

Ich hab dein Plugin jetzt mal bei mir (blog.garv.in) installiert um es zu testen.

Folgende Dinge habe ich noch bemerkt:

1. Das "Ohne Javascript" in der Beschreibung sollte raus

2. Das Plugin muss mit Datei und Klassenname noch in serendipity_plugin_twitter umfirmieren

3. Es muss eine Konfigurationsoption für die URL der Javascript-Datei geben. Derzeit wird /plugins /blabla/ festverdrahtet, das plugin könnte aber auch in /additional_plugins/plugins/blabla liegen. Das alte Plugin hat dafür die Callback-URL standardmäßig mit /plugins/blogger.js vorbelegt. Diese URL sollte auch konfigurierbar bleiben, damit man ggf. seine eigenen Callbacks hinterlegen könnte und auch die URL für verscachtelte Pluginverzeichnisse weiterhin nutzen kann

4. In den SQL-Statements muss das "CHARACTER SET" noch raus (kann durch {UTF_8} ersetzt werdne, das wird durch serendipity_db_schema_import automatisch ersetzt), und "FIRST" in ALTER TABLE muss auch raus.

Ansonsten sieht das sehr gut aus, ich denke dass es auf meinem Blog auch schon gutl äuft.

Grüße,
Garvin

[Dr. Love]

1. Das "Ohne Javascript" in der Beschreibung sollte raus

OK, ist raus.

2. Das Plugin muss mit Datei und Klassenname noch in serendipity_plugin_twitter umfirmieren

Das wollte ich erst machen, wenn das Ding wirklich stable ist. Sprich: Wenn es noch mehr Userfeedback als nur von Dir dazu gibt, werde ich das umbenennen. ich will nicht, dass irgendwer hingeht, das Ding einfach drüber haut und dann Probleme bekommt.

Ich würde das PlugIn auch in Abgrenzung zum alten PlugIn die Versionsnummer 2.0 geben, damit der komplette Rewrite ausgedrückt wird.

3. Es muss eine Konfigurationsoption für die URL der Javascript-Datei geben. Derzeit wird /plugins /blabla/ festverdrahtet, das plugin könnte aber auch in /additional_plugins/plugins/blabla liegen. Das alte Plugin hat dafür die Callback-URL standardmäßig mit /plugins/blogger.js vorbelegt. Diese URL sollte auch konfigurierbar bleiben, damit man ggf. seine eigenen Callbacks hinterlegen könnte und auch die URL für verscachtelte Pluginverzeichnisse weiterhin nutzen kann

OK, das verstehe ich grundsätzlich, aber warum ein Eingabefeld, das fast niemand je brauchen wird? (ist das so?) Gibt es keine Möglichkeit, herauszufinden, in welchem Ordner das Script liegt und das damit einzubinden? Das würde Fehleingaben in der Config wirkungsvoll verhindern und austauschen wird man das Script sowieso nicht und wenn doch, sollte man in der Lage sein, das Originalscript umzubenennen. Oder nicht? Übersehe ich da was?

4. In den SQL-Statements muss das "CHARACTER SET" noch raus (kann durch {UTF_8} ersetzt werdne, das wird durch serendipity_db_schema_import automatisch ersetzt), und "FIRST" in ALTER TABLE muss auch raus.

Also die komplette Zeile 'CHARACTER SET utf8 COLLATE utf8_unicode_ci' wird durch '{UTF_8}' ersetzt? ich mach das mal. Hoffentlich klappt das nach noch

FIRST ist draußen.


Hab übrigens gerade einen blöden Bug in der TwitterApi gefunden, der die Backup-Funktion wirkungsvoll verhindert hat ('Error in class TwitterApi: Missing mandatory config item cache_file. Check your config.' in der Logdatei). Die Prüfung auf die notwendigen Config-items war zu streng. Jetzt ist dem die Cachedatei egal, wenn die Cachezeit auf 0 steht.


Zu Deinem Blogeintrag: Danke für die Erwähnung. Allerdings möchte ich an dieser Stelle darauf hinweisen, dass das PlugIn wirklich vollständig neu geschrieben wurde. Vor Deinen Kompatibilitätsbegehrlichkeiten gab es quasi keine alte Zeile Code mehr und auch was ich vom alten PlugIn mehr oder weniger abgeguckt habe, habe ich auch neu geschrieben (wie die Backup-Funktion). Von "etwas zu überarbeiten" und "die PHP-Klasse etwas angepasst" kann echt nicht die Rede sein und ein Templating gab es gar nicht vorher. Das JavaScript ist ganz neu geschrieben und bietet völlig neue Möglichkeiten (das alte ähnelte dem offiziellen Widget von Twitter sehr und wahr eher rudimentär). Deine Beschreibung passt eher auf meinen Beitrag zue Version 0.7 des alten Twitter PlugIns. Ach ja, auch der Link hier zum Thread funktioniert nicht.

[ostfriesengott]

Hi...
Ist das Plugin schon in Spartacus verfügbar? Klingt alles sehr interessant.

[Dr. Love]

Noch nicht im Spartacus, aber Du kannsgt gerne mal die aktuelle Testversion testen. Ich hab noch eine Hand voll essentielle Verbesserungen vorgenommen.

0.2 RC3:
---

* improved DB code for backup feature for databases pgSQL and SQLite
* fixed a critical bug in in TwitterApi class that stopped the backup process in most cases (Error in class TwitterApi: Missing mandatory config item cache_file. Check your config.)
* introduced seperate logfiles for backup and other errors (like no cache available and Twitter API down)
* fixed the JavaScript @#!URL parser to work with more than one of one type in one message
* some minor non-critical fixes

Notice: First time backup is still problematic, so the backup feature keeps marked as experimental

0.2 RC2:
---

* improved backwards-compatibility for old Twitter plugin (strftime() instead of date, renamed config-items)
* DB code now hopefully also works with SQLite and pgSQL
* some minor improvements

[Dr. Love]

Gibt es eine Möglichkeit, JavaScripts (nur einmal) in den head-Bereich zu laden? Momentan wird das JavaScript mehrmals im Body geladen, wenn das PlugIn mehrmals geladen wird.

[kbm]

Also mal ehrlich, ...ich verfolge diese Diskussion mit wirklich großem Interesse. ABER, dennoch, ...ich bin ja doof und auch alt.
Nun: Nachdem ich das Twitter-Plugin "hochgeladen" hatte, wurde mir "gesagt", dass ich das Plugin nicht verwenden / nutzen kann, weil mein System oder so nicht PHP5 hat. Hmm... na und?!?
Von der Twitter-Homepage habe ich mir daraufhin einen mir angebotenen Web-Code "gekrallt", ...diesen in einen HTML-Klotz von s9y "gepackt", ...und schwupps war mein Getwittere in meiner Blog-Seitenleiste.

Der (mein) nächster Gedanke war: wie bekomme ich's hin, dass in meinem Getwittere auch irgendwie automatisch immer meine neu erstellten Blog-Artikel angezeigt werden?!
Das war gar nicht so schwierig, denn ich habe dazu flug's HIER im Forum, genau den richtigen Tipp und Hinweis erhalten.

Hmm... und nun frage ich mich, ...wenn das womöglich neue Twitter-Plugin, mir immer noch sagt, dass ich's als PHP4-User eh nicht einsetzen kann, ...und warum es so einen Riesenaufwand bedarf (also laut Diskussion), das "Teil" PHP5-konform zu "backen", ...ähie, wat soll der Schitt???
Klaus

[Dr. Love]

Es wäre ein Riesenaufwand, es für PHP4 tauglich zu machen, weil es die neuen möglichkeiten von PHP5 nutzt. Nicht umgekehrt.

Und gut festgestellt: Wer mit dem JavaScript Widget von Twitter gut bedient ist, braucht das PlugIn schlicht nicht. Hatte ich anfangs bereits erwähnt. Trotzdem bietet das JavaScript des PlugIns gegenüber dem JavaScript Widget von Twitter etliche Vorteile, etwa die Backup-Funktion und hübsche internationalisierte Zeitstempel je nach eingestellter Sprache im Blog, oder anklickbare @/!/#-Tags. Muss man wissen, ob man das braucht oder nicht. Und bei PHP4 hat sich die Frage ja eh erledigt.

Neue Blogeinträge bei Twitter anzukündigen war und ist nicht Aufgabe eines PlugIns, das aktuelle Twittereinträge in der Seitenleiste anzeigen soll. Seh ich zumindest so. Das Featureset des neuen PlugIns ist deutlich ausgereifter und praxistauglicher als das des alten (Neu sind: Templating, mehrstufiges Caching der PHP Version, schöne Zeitstempel, "via" und "als Antwort auf" Metaangaben, leichte Erweiterbarkeit um weitere Dienste, mehrere Dienste gleichzeitigf möglich und und und). Das soll der Schritt.

P.S. Wer redet von "Teil" und "backen"? Oder was sollen die Anführungszeichen?

[kbm]

Echt, ...mir ist es völlig Schnuppe, ob so'n Plugin PHP4- oder PHP5-konform ist. ...und wahrscheinlich oder sogar ganz bestimmt, kapiere ich nicht, was so ein neues Microblog-s9y-Plugin mir alles für schöne neue Welten eröffnen werden kann/könnte.
Genauso, wie ich mich schlapplachen kann, wenn mich wer "anmacht", dass ich'n Auto mit Kupplungspedal und nicht, mit'm Automatikgetriebe bewege.
JA, ...es bedeutet wirklich sehr viel Arbeit und Zeit, ...vor allen Dingen Zeit, so'n Plugin zu "backen", ...und ehrlich, ich schmeiße mich vor Deinen Füssen auf den Boden und in den Dreck, ...meine allergrößte HOCHACHTUNG.
Entschuldigung: ...es ist und war nie meine Absicht, Deine Leistung zu bezweifeln, ...ob mit oder ohne Anführungszeichen in meinen Zeilen
Klaus

[garvinhicking]

Hi!

Das wollte ich erst machen, wenn das Ding wirklich stable ist. Sprich: Wenn es noch mehr Userfeedback als nur von Dir dazu gibt, werde ich das umbenennen. ich will nicht, dass irgendwer hingeht, das Ding einfach drüber haut und dann Probleme bekommt.

Hm, okay. So muss ich halt immer erst manuell Hand anlegen wenn Du ein Update machst, bevor ich das Plugin testen kann.

3. Es muss eine Konfigurationsoption für die URL der Javascript-Datei geben. Derzeit wird /plugins /blabla/ festverdrahtet, das plugin könnte aber auch in /additional_plugins/plugins/blabla liegen. Das alte Plugin hat dafür die Callback-URL standardmäßig mit /plugins/blogger.js vorbelegt. Diese URL sollte auch konfigurierbar bleiben, damit man ggf. seine eigenen Callbacks hinterlegen könnte und auch die URL für verscachtelte Pluginverzeichnisse weiterhin nutzen kann

OK, das verstehe ich grundsätzlich, aber warum ein Eingabefeld, das fast niemand je brauchen wird? (ist das so?) Gibt es keine Möglichkeit, herauszufinden, in welchem Ordner das Script liegt und das damit einzubinden? Das würde Fehleingaben in der Config wirkungsvoll verhindern und austauschen wird man das Script sowieso nicht und wenn doch, sollte man in der Lage sein, das Originalscript umzubenennen. Oder nicht? Übersehe ich da was?

Selbst wenn es nur wenige Leute brauchen, es wird aber halt eingesetzt. Und vor allem von mir.

Leider kann man anhand der Symlinks nicht feststellen, in welchem symbolischen Verzeichnis eine Datei liegt, sondern nur das "echte" Verzeichnis. Das wiederrum lässt keinen Rückschluss auf den Document-Root zu. Sonst hätte ich das damals auch in allen anderen Plugins nie als eingabefeld gelöst sondern automatisch. Wenn Dir doch eine Lösung einfällt, nur her damit.

Konkret habe ich bei mir folgende Pfadstruktur:

* /home/garvin/cvs/serendipity/recent enthält mein s9y
* /www ist mein document root
* /www/cvs ist ein symlink auf /home/garvin/cvs
* /home/garvin/cvs/additional_plugins ist mein CVS-Checkout aller plugins
* /home/garvin/cvs/serendipity/recent/plugins/additional_plugins ist ein symlink auf /home/garvin/cvs/additional_plugins

D.h. bei mir müssen externe scripts als HTTP-Link /cvs/serendipity/recent/plugins/additional_plugins/ ausgegeben werden.

Zu Deinem Blogeintrag: Danke für die Erwähnung. Allerdings möchte ich an dieser Stelle darauf hinweisen, dass das PlugIn wirklich vollständig neu geschrieben wurde.

Sorry, damit wollte ich Dir nicht auf die Füße treten.

Gibt es eine Möglichkeit, JavaScripts (nur einmal) in den head-Bereich zu laden? Momentan wird das JavaScript mehrmals im Body geladen, wenn das PlugIn mehrmals geladen wird.

In den Headbereich nicht, nur per Javascript-DROM-Tree. Du kannst aber im Plugin eine globale $serendipity-Variable setzen, so dass das javascript nicht mehr ausgegeben wird, wenn die Variable gesetzt ist.

@kbm: Sorry, deine Sätze sind mir zu anstrenged zu lesen.
Grüße,
Garvin