Serendipity Forums

Hallo miteineinander!

Im Laufe der Jahre habe ich mehrfach Probleme mit Plugins gesammelt oder darüber hier im Forum gelesen, wo sich herausstellte, dass sie in Konflikt mit bestimmten anderen Plugins geraten sind. Oder viell. nicht nur Plugins, sondern sagen wir, auch Editoren wie Xinha. (Weiß nicht - vielleicht auch mit Templates?)

Aktuelles Beispiel.
Von mir gefundener Bug im event_static_page_plugin (an Don berichtet, Don hat es hier im Thread zur Sprache gebracht:
http://board.s9y.org/viewtopic.php?f=4& ... #p10432841

. Timbalu schrieb dazu heute gerade, dass herausgefunden wurde, dass das an dem Editor Xinha liegt.
Der Fehler äußert sich darin, dass das extended-entry-Feld im Backend ein Hineinschreiben nicht (mehr) zulässt. Der Fehler trat ab einer bestimmten Version des Plugins auf (ungefähr 3.96); es gab ja in letzter Zeit mehrere Updates.

Falls ich zur Rechtfertigung des Vorschlags noch weitere Beispiele nennen soll - nur zu! Fragt ruhig.

Ich wünsche mir eine Sammlung von Dokumentationen von derlei inkompatiblen Plugins, geordnet (in Unterkategorien) nach Plugins. Hier kann man sich dann vor einer beabsichtigten Installation eines (neuen) Plugins im eigenen Blog informieren. Oder probeweise ein Plugin deinstallieren, von dem Probleme berichtet werden, wenn man Probleme hat und keine Ahnung hat, woher die rühren.

Hier sollten Einträge von nicht technisch Versierten (ich zähle mich dazu) erst nach Moderation freigegeben werden.

s9y-Entwickler/Coder haben so auch eine strukturiertere Übersicht an To-dos.
Und User können sich informieren, mit welchen Plugins sie Risiken eingehen bzw. wenn sie ein Plugin installiert haben und dann Probleme haben, leichter die Herkunft der Ursache von Problemen lokalisieren.

Vorteil gegenüber dem Ordner "Plugins" bzw. "Bugs", wie sie jetzt sind, soll sein. Besseres Auffinden nach Logik und Navigation. Die Inkompatibilitäten betreffen ja beides, sind also eine Spezialproblemgruppe.

Wenn mein Vorschlag prinzipiell ankommt:
Frage: Soll das in englisch sein (englische Pluginnamen) oder in deutsch?

Beste Grüße

Czorneboh

Czorneboh wrote:Der Fehler äußert sich darin, dass das extended-entry-Feld im Backend ein Hineinschreiben nicht (mehr) zulässt.

Wenn ich das richtig mitbekommen habe, gibt es übrigens mittlerweile einen Woraround für dieses Problem, was in zukünftigen Versionen enthalten sein wird.

Czorneboh wrote:Ich wünsche mir eine Sammlung von Dokumentationen von derlei inkompatiblen Plugins, geordnet (in Unterkategorien) nach Plugins.

Spontanreaktion: „Die stehen doch normalerweise hier im Forum. Oder zur Not auf GitHub in den jeweiligen Issues-Trackern.“

Zweite Reaktion: „Aber im Forum müsste man suchen, GitHub ist vielen Benutzern vielleicht zu technisch, insofern wäre eine Sammelstelle vielleicht gut.”

Dritte Reaktion: „Dafür müsste halt jemand Zeit haben. Das geht eigentlich nur als Kollektivleistung. Wem was auffällt, der trägt es ein (Wiki?) oder meldet es an jemanden, der sammelt.”

Das letzte hört sich schweinefaul an, ich weiß. Es ist aber nun mal eine Tatsache, dass wir ein kleines Entwicklerteam sind, in dem es gilt, Zeit effizient zu nutzen. Und, äh, Entwickler schreiben leider ungern Dokumentation. Ist doof, ist aber so. Jede Zeit, die wir in Nicht-Entwicklung stecken, geht von der Entwicklung ab.

Das soll nicht heißen, dass ich dagegen wäre, aber ich denke, es geht nur, wenn sich ein Freiwilliger findet, der das sammelt und irgendwo™ veröffentlicht. Kollektives Eintragen klappt eher nicht so gut. Und richtig, die Einträge müssten in irgendeiner Form geprüft werden.

Eine andere Frage wäre, ob es wirklich so viele Plugin-Inkompatibilitäten gibt, dass es sich lohnt, diese aufzulisten. Normalerweise bemühen wir uns ja schon, Bugs zeitnah zu fixen.

Czorneboh wrote:Frage: Soll das in englisch sein (englische Pluginnamen) oder in deutsch?

In jedem Fall (komplett) in English, damit es möglichst vielen Benutzern zugänglich ist.

YL

Danke für Dein Feedback, YL.

Dafür müsste halt jemand Zeit haben. Das geht eigentlich nur als Kollektivleistung. Wem was auffällt, der trägt es ein (Wiki?) oder meldet es an jemanden, der sammelt.

Ja, sehe ich auch so. Ich würde meinen Beitrag leisten. Wenn ich nachkrame, finde ich noch 2, 3 oder 4 Fälle aus meiner Blog-Geschichte.. Sammelstelle sollte aber bei denjenigen sein, die das mit ihren technischen Verständnis auswerten und dann dokumentieren, so in der Art, wie ich das bei Mozilla gesehen habe. Da werden mit einem Update, mit dem Bugs gefixt werden, auch noch offene Probleme beschrieben, die noch zu erledigen sind.

Wenn ich das richtig mitbekommen habe, gibt es übrigens mittlerweile einen Woraround für dieses Problem, was in zukünftigen Versionen enthalten sein wird.

Das bot sich als brandaktuelles Beispiel an. Es ist aber, wie ich es verstehe, ein Notflicken, hilft nur teilweise.
Ich kann aber andere Beispiele liefern.

ob es wirklich so viele Plugin-Inkompatibilitäten gibt, dass es sich lohnt, diese aufzulisten.

Wenn es nicht viele werden, macht es auch nicht viel Arbeit und damit ist das "Faulheits"-Argument geschwächt. Dann schafft man das schon und für die Zukunft hat man einen leicht zugänglichen Parkplatz für weitere Imkompatibilitäts-Fälle.

Ich verstehe den Forumordner mit Unterordnern (wie beschrieben) also als Konzentrat einer Kommunikation eines Problems entweder unter den Entwicklern (wie während Eurer neuen Gruppenchats wie zuletzt am Wochenende) oder aus dem Forum. Die Forumteilnehmer liefern ja die entdeckten Probleme und die "Techniker" stellen die Diagnose. Es muss eben noch mal zusammengefasst werden.

Beim Hin- und Her des Forums, vielleicht auch bei Github versickert das zusammen kommunizierte Wissen.

In Zukunft kann auch wieder Zeit gespart werden (doch wenigstens im utilitaristischen Sinne), wenn man so eine Knowledge-Base hat.

Ich bin dagegen. Wir haben das Forum.
Jemand meldet einen Bug oder eine Unverträglichkeit oder möchte ein neues Feature haben.
Das wird besprochen und gefixt, für individuelle Zwecke verändert oder fallengelassen.
Ich wüßte jetzt keinen Fall, an dem ich mich erinnerte, in dem das nicht so lief. Mitunter fehlt die Rückmeldung des Users das alles glatt läuft, oder ihr/ihm geholfen wurde, im Nachhinein.
Ansonsten gilt, Software ist von Menschen an einem bestimmten Zeitpunkt ihrer Entwicklung geschrieben und enthält immer Verbesserungsmöglichkeiten und Ansätze wie bestimmte Codeteile von anderen Menschen oder Programmen ausgehebelt werden können. Deshalb ist Software ein Workflow und muss sich anpassen. Das gilt insbesondere auch für Plugins. Jemand der solche benutzt, muss darauf achten ab und zu upzugraden.

Czorneboh wrote:Das bot sich als brandaktuelles Beispiel an. Es ist aber, wie ich es verstehe, ein Notflicken, hilft nur teilweise.

Was heißt das "...teilweise"? Meines Erachtens haben wir nur eine Klappbox Usability entfernt, wenn jemand den Wysiwyg-Editor verwendet, der sich nicht mit diesem einfachen Javascript vertrug.

Czorneboh wrote:Ich kann aber andere Beispiele liefern.

Bitte gerne.

Czorneboh wrote:Sammelstelle sollte aber bei denjenigen sein, die das mit ihren technischen Verständnis auswerten und dann dokumentieren

Ich halte es für sehr unwahrscheinlich, dass sich aus dem derzeitigen Entwicklerteam jemand findet, der das (womöglich alleine) übernimmt. Allein aus Zeitgründen.

Czorneboh wrote:Da werden mit einem Update, mit dem Bugs gefixt werden, auch noch offene Probleme beschrieben, die noch zu erledigen sind.

Da arbeiten auch ein paar mehr Leute.

Czorneboh wrote:Wenn es nicht viele werden, macht es auch nicht viel Arbeit und damit ist das "Faulheits"-Argument geschwächt.

Ich kann es auch mal ganz „brutal“ formulieren: Aus Entwicklersicht gibt es keine Notwendigkeit für eine solche Liste. Ich kann verstehen, dass sie aus Benutzersicht wünschenswert wäre, dann müsste sich aber auch ein Benutzer finden, der sowas pflegt.

Czorneboh wrote:Beim Hin- und Her des Forums, vielleicht auch bei Github versickert das zusammen kommunizierte Wissen.

Im Gegenteil. GitHub hat die Kommunikation (unter Entwicklern) aus meiner Sicht verbessert und beschleunigt.

YL