Die Zukunft von Serendipity

[Joaquin]

Eine Übersicht darüber wer welchen Beitrag abonniert hat, mit der Möglichkeit dort Emailadressen herauszunehmen. Ich bekomme nämlich immer wieder gebouncde Emails von alten bzw. nicht mehr existenden Emailadressen, wenn wieder jemand auf einen alten Beitrag antwortet.

[Joaquin]

Ein Löschen des Spam-Logs direkt aus s9y heraus wäre gut bzw. eine Beschränkung auf eine vordefinierte Größe. Die Limitierung auf eine maximale Größe wäre auch für andere Log-Dateien sinnvoll.

[Dr. Love]

Hi Garvin,

auch ich gratuliere nochmals zum schönen System. Als kleinere Anregung habe ich die bereits an anderer Stelle diskutierten Änderungen am Kern, um ein Feedburner-Ersatz für Arme implemenieren zu können:

Siehe Überlegungen: Feedabos selber zählen statt Feedburner

Lg,
Nathanael

[dhm]

Hallo Garvin,

an dieser Stelle möchte ich abermals großes Lob aussprechen:
du bist für mich ein Vorbild der Free/Libre Open Source Software. Großartiger Support, ansteckendes Engagement, hier fühlt man sich einfach wohl und hat ein gutes Gefühl mit s9y. Dieser Thread ist ein weiterer Beweis dafür. Und zugleich auch mein erster "Vorschlag": all das beibehalten. Bitte.
... wenn ich Programmierer wäre, ich würde so sein und Projekte führen wollen wie du - ja.

Zu den Features:
Ich persönlich bin eigentlich ständig auf der Suche nach geeigneten CMS in allen Ausprägungen (Blogs sind eine Untergruppe davon). Wenn ich mir nun überlege, was mich endgültig bei s9y als Blog-Software halten würde, stelle ich fest, dass es ein Thema ist: Sicherheit.

1. Plugins
Es ist schön & richtig, Funktionen, die nicht zu den Grundlagen gehören, als Plugin auszulagern. Allerdings ist jedes Plugin grundsätzlich ein vergleichsweise großes Sicherheitsrisiko (in vielerlei Hinsicht: Stabilität, Wartung, Sicherheitslücken, Funktion). Um Plugins auch für paranoide Übervorsichtige wie mich (die leider selber nicht die Fähigkeiten haben, Programmiertes zu verstehen) schmackhaft zu machen - ja, ich vermeide Plugins wo es nur geht - wäre folgendes prima:

eine Zertifizierung oder gar Garantie für von Usern beigesteuerte Plugins. Ich als s9y-Anwender, der keine Ahnung von Skriptsprachen hat, möchte davon ausgehen können, dass das Plugin

1. nicht böswillig ist (keine bewussten Sicherheitslücken aufweist)
2. keine Lücken in s9y aufreißt (unbewusst vom Plugin-Autor)
3. auch weitere s9y-Updates mitmacht (ohne vom Plugin-Autor abhängig zu sein)
4. möglichst tut, was es verspricht

(und zwar in dieser Reihenfolge)

Habe ich bei einem Plugin das Gefühl, dass Punkte davon nicht erfüllt sind (was eigentlich derzeit bei 95% aller CMS der Fall ist), dann setze ich es nicht ein. Und daraus folgt, dass ich mit dem System meist nicht warm werde, weil es ja eben die Philosophie ist, Plugins einzusetzen.

Wichtig ist es, dass man weiß, dass sich Projektmitglieder die beigesteuerten Plugins wirklich anschauen, begutachten, kontrollieren, durchleuchten, etc. - nicht einfach nur drüberschauen und "was kümmert mich das, ist des Users Bier"-Einstellung fahren (wobei ich hiermit nicht sagen will, dass das bei s9y so läuft oder lief).

Ein Zertifikat für Plugins - das wäre riesig. Dadurch werden oben genannte 4 Punkte (soweit wie möglich) eingehalten und es entsteht keine unüberschaubare Anzahl von Plugins, die in weiten Teilen das gleiche tun.

(ich bin derzeit nicht auf dem Laufenden hier, daher weiß ich auch nicht, ob die automatische Plugininstallation -an die kann ich mich noch erinnern- über das Backend sowas in der Richtung darstellt)

2. Auditing

Die deutsche Wikipedia über OpenBSD:

Traditionell wird von den Entwicklern ein regelmäßiges Auditing, eine Untersuchung von Quellcode auf Programmfehler durchgeführt.

und über Software-Audit:

die systematische Suche nach potentiellen Sicherheitslücken in Programmen

Das hat mich sehr beeindruckt, muss ich zugeben. Und mich "heiß" gemacht: wie wunderbar wäre es, wenn man weiß, dass der gesamte Code immer und immer wieder gecheckt wird? "Unsaubere Implementierungen" umgeändert werden, potentielle Sicherheitslücken gefixed werden? Nichts "mal eben Gehacktes" vergessen wird ( ... bis es Probleme macht ).

s9y, das OpenBSD der Weblogs - das wäre fürwahr mein Killerfeature.

[Cohnina]

Im Vergleich zu WP fehlt(e) mir nur folgendes:

Eine bessere Lösung für die Blogroll
Das Link Indication Plugin

Letzteres hab ich nun per CSS gelöst - ist zwar etwas umständlicher, kommt dem gewünschten aber recht nahe.

Aber für die Blogroll hätte ich gern noch bessere/mehr Möglichkeiten die Links darstellen zu lassen. Die Baumansicht ist nicht wirklich hübsch anzusehen und alle Links auf einmal sind zu viel. Vielleicht gibt es hier ja auch die Möglichkeit, die eingestellten Kategorien teilweise und zufällig darstellen zu lassen und ich hab's nur noch nicht gefunden
- Das bringt mich noch zu einem anderen Punkt, der jetzt nicht unbedingt technisch ist, sich aber mit Unterstützung aller Serendipity Nutzer beheben lässt: Man findet zu wenig, wenn man etwas sucht.

WP hat zb ganze Webseiten zu den einzelnen Plugins (ich kann mir vorher anschauen, was es macht und wie es das tut - wobei es mit s9y auch kein Problem ist das betreffende Plugin mal eben fix zu installieren und gegebenenfalls wieder rauszuwerfen). Serendipity erscheint, kurz gesagt, eben immer recht technisch und mit Arbeit verbunden und viele befreundete Blogger würden sich niemals rantrauen - WP dagegen ist auch für Doofies (macht dann aber doch mehr Probleme und Zicken ).

Viel Text, wenig Gemeckert - also ein dickes Lob an Garvin & Co!

[Hiwelt]

Hallo Garvin,

gerne steuere ich auch noch eine Idee zur möglichen Zukunft von s9y bei.

Es handelt sich bei meinem Wunsch um eine ganz spezielle Idee, die vielleicht nicht vielen aber doch einigen (mich eingeschlossen) nützlich sein dürfte.

Beschreibung:

Es gibt Anwender, die s9y ganz bewußt als Tagebuch einsetzen und die es auch gern irgendwann als echtes gedrucktes Buch in Händen halten würden.

Zwar gibt es ja schon das Plugin serendipity_event_blogpdf, allerdings fehlen mir dabei für eine mögliche Weiterverarbeitung zur Buchproduktion zwei Kriterien

• * die Blogeinträge müßten umsortiert werden (ältester zuerst)
  * es werden derzeit keine Bilder mit exportiert, sollten sie aber

Diese beiden Funktionen würden schon voll und ganz reichen. Um das finishing muß sich schon jeder selbst kümmern.
Nach Gesprächen mit einigen Programmierern (ich bin nun wahrlich keiner) weiß ich, dass dies allein schon eine sehr anspruchsvolle Aufgabe ist.
Aber ich glaube, solch ein Funktion könnte die Verwendung von s9y noch viel interessanter machen.

Übrigens: in den USA gibt es einen Service - blurb - der den ganzen Prozess, allerdings für viel Geld, schon anbietet.

Ansonsten bleibt mir nur fetzustellen, dass s9y mir schon seit Jahren viel Freude bereitet und immer mit ein Grund dafür war, in Bo(g)ckade-Zeiten nicht einfach mit dem Bloggen aufzuhören.
Danke nochmal an alle Entwicker und Helfer für diese tolle Software.

Holger

[garvinhicking]

Hi zusammen!

Vielen Dank für das hilfreiche Feedback soweit. Ich hätte nicht mit so viel reger Beteiligung gerechnet.

Daher ist es schwierig jetzt hier zu allem detailiert bezug zu nehmen. Ich habe unter

http://www.s9y.org/238.html

eine (englische) Todo-Liste erstellt und hoffe, dort alles aufgenommen zu haben.

@moenk: Du kannst Benutzern doch über die Gruppenrechte so einteilen, dass sie keine Kategorien bearbeiten dürfen usw.? Dasselbe gilt für die Redakteurssprache, die lässt sich doch individuell festlegen. Das Artikel-freischalten wäre für ein "Workflow"-Plugin recht gut.

@winkiller: Sehr gute Idee zur Konfiguration von "Erweiterte Eigenschaften", das kann ich als eine der ersten Sachen mal umsetzen.

@mastaYoda: Der PHP5-Nazi schon wieder! Spaß beiseite: Ich finde, neue Plugin dürfen gerne jederzeit PHP5 voraussetzen. Bis auf PPP sehe ich in der jetzigen API aber keinen zwingenden Grund, die PHP4-Kompatibilität zu entfernen. Das Problem ist, wenn man die API zu sehr ändert, wird man dadurch direkt alle bestehenden Plugins unnutzbar machen. Daher bin ich eher der Meinung, dass die API den Bedürfnissen folgen sollte, und nicht die API als Selbstzweck neu erfunden wird.
Deine Idee mit der Kombination zu den Textformatierungsplugins wurde ja auch glaub ich schonmal in #s9y diskutiert. Grundsätzlich fände ich das gut, mir fehlt nur ehrlich gesagt ein konzeptioneller Ansatz dafür.
Unit-Testing: Oh ja, gerne. Leider ist Unit-Testing für bestehende Projekte ein einziger Popo-Schmerz, was vermutlich für Dich auch ein ausschlaggebender Grund für eine neue API wäre, die man direkt anhand von Unit-Tests entwickeln könnte...

@kho: Gute Idee mit der Erweiterung der Bildeinfügung. Zu Lightbox-Problemen bitte ich dich, einen eigenständigen Thread mit Details dazu aufzumachen.
Beim Update haben sich FTP-Programme mit Threading eigentlich gut bewährt. Den Upload lässt man dann die 3-4 Minuten einfach laufen. Es ist schon sehr komplex, ein eigenes s9y-Downloadpaket für jede Sprachversion anzubieten, da bräuchte ich beim Release nen ganzen Tag sowas einzupflegen.

@Robert: Wiki, Forum und Blog zu verheiraten ist ja immer ein schönes Thema. Allerdings sehe ich die jeweiligen s9y-Alternativen zu phpBB und coWiki bei weitem nicht ausführlich genug, um s9y.org damit zu betreiben.

@yellowled: Man könnte für's erste in Spartacus auf die Changelogs hinweisen. Ansonsten ist Dokumentation natürlich immer ein Fleißthema, wofür wir schlicht mehr Leute bräuchten. Das Problem über eine automatische Info zu Updates ist, dass dafür die BLoginstallation mit s9y.org sprechen müsste. Damals hieß es immer, aus sicherheitsgründen und "Datenspionage" würden die User sowas eher nicht wollen. Technisch wäre das kein wirklich großes Problem...

@Joaquin: Die Kommentaroberfläche habe ich mit aufgenommen. Was Logfiles angeht: Ich bin da eher ein Freund, wenn jemand sowas loggt, dass er selber bestimmt wann Logfiles wie beschnitten werden...

@dhm: Was Plugin angeht: Alles was in Spartacus landet, ist von mir so gut es geht auf Sicherheit geprüft. In Spartacus ist kein Plugin, von dem ich behaupten würde es wäre ein Sicherheitsrisiko. Im Grunde achte ich auf alle Spartaucsplugins genauso wie auf den internen s9y-Quelltext. Sprich: Die Zertifizierung ist eigentlich schon dadurch da, dass ein Plugin in Spartacus aufgenommen wird. Auditing findet eigentlich immer wieder anhand von neuen Sicherheitslücken und -Techniken statt, z.b. als es damals CSRF-Attacken gab, wurde der s9y Code daraufhin so gut wie möglich getestet und angepasst. Ansonsten ist regelmäßiges Code-Rewrite nur bei Projekten möglich, dass mehrere Entwickler hat. Serendipity ist dafür eigentlich zu klein.

@Cohnina: Das Link-List Plugin dient Dir hier nicht als hilfe? Dokumentation wäre natürlich toll, mit meinem Buch habe ich versucht einen großen Schritt in die Richtung zu gehen. Letztlich sind das halt alles große Textmengen, die niht unbedingt ein Entwickler wie ich leisten könnte, sondern jeder der die Plugins auch einfach nur einsetzt. WP hat mit seinen Millionen Usern hier einen großen Vorteil, da es einfach wahrschienlicher ist, dass sich einer von 1.000.000 Usern mal hinsetzt und einfach eine Doku dazu macht. Grundsätzlich ist das s9y.org Wiki frei zugänglich und ich gebe jederzeit Accounts heraus für Personen, die gerne Dokumentation schreiben wollen.

@Hiwelt: Deine Anforderung ist tatsächlich etwas speziell. Grundsätzlich liegen die s9y Artikeldaten ja als HTML vor. Es muss also "nur" die Datenbank dazu angesprochen werden. Leider ist ein Export von HTML nach PDF meines Wissens nach extrem schwierig. Ich wüsste nicht, wie man Bilder sinnvoll dahinein einbetten würde. Ich denke, es wäre sinnvoller den Druckprozess hier mit einem HTML-Konverter und einem eigenen, reduzierten Smarty-Template anzugehen. Es gibt wohl auch PDF-Konverter mit denen man HTML-Code in PDF überführen kann, aber da habe ich mich nie wirklich eingearbeitet weil das Thema für mich nicht so interessant ist, da ich die HTML-Ausgabe einer gedruckten Ansicht sogar vorziehe.

Viele Grüße,
Garvin

[yellowled]

Das Problem über eine automatische Info zu Updates ist, dass dafür die BLoginstallation mit s9y.org sprechen müsste. Damals hieß es immer, aus sicherheitsgründen und "Datenspionage" würden die User sowas eher nicht wollen. Technisch wäre das kein wirklich großes Problem...

Als Plugin umsetzen? Als Konfigurationsoption? So könnte jeder User individuell entscheiden ...

Es gibt wohl auch PDF-Konverter mit denen man HTML-Code in PDF überführen kann

Das führt meines Wissens üblicherweise über den Umweg HTML -> LaTeX -> Postscript -> PDF. Von LaTeX nach PDF, das weißt Du sicher selbst, ist es nicht mehr weit. Mit Einschränkungen können gewisse HTML-Dokumente oder -Abschnitte natürlich relativ leicht nach LaTeX überführt werden, da beide Auszeichnungssprachen letztlich ähnlich mit anderer Syntax arbeiten.

Eine mögliche (aber meiner Ansicht nach unschöne) Alternativ ist der Export eine kompletten HTML-Seite als Grafik (EPS), die dann in PDF eingebettet wird.

YL

[robert]

Hi Garvin,

@Robert: Wiki, Forum und Blog zu verheiraten ist ja immer ein schönes Thema. Allerdings sehe ich die jeweiligen s9y-Alternativen zu phpBB und coWiki bei weitem nicht ausführlich genug, um s9y.org damit zu betreiben.

Das stimmt natürlich. Das wäre für mich eine Vision für die Version 2.0 oder so - sofern die PluginautorInnen hier noch weiter arbeiten.

Man/Wir sollte/n darauf schauen, dass soviele Angebote wie möglich bei s9y.org über S9y selbst laufen. Denn die Website ist natürlich eines der Aushängeschilder von Serendipity.

[maxfli55]

Die Idee des 'Link Indication Plugin' finde ich gut, insbesondere, dass für jeden Link bzw. Dateityp ein kleines Symbol hinter dem jeweiligen LInk erscheint.

Ich bin dafür...

[garvinhicking]

@yellowled: Hab's mal als config option mit in die liste aufgenommen.

[falk]

Hallöle,

mal wieder seit langem ein Post von mir .

Garvin, ich weiß du hörst es nicht gerne, aber ich habe angefangen S9y PHP5-Tauglich zu machen. Derzeit arbeite ich an der Plugin-API und möchte mal sehen, in wie weit man diese an PHP5 anpassen kann, ohne die Plugins anpassen zu müssen. Wenn es hier wirklich dazu kommen sollte, S9y auf PHP5 umzustellen, stehe ich gerne mit meinen Erfahrungen zur Verfügung.

Und um hier Gerüchten zuvor zu kommen: Ich werde S9y nicht forken. Aber ich möchte mit diesem Hinweis ein Zeichen setzen, doch mal intensiv über PHP5 nachzudenken und endlich PHP4 fallen zu lassen. Und zwar nicht nur in den Plugins, sondern im gesamten Framework.

So, das waren meine 2 Cent. Ihr könnt mich jetzt virtuell auseinander nehmen .

Falk

[yellowled]

Ihr könnt mich jetzt virtuell auseinander nehmen

Ich hätte gern den Kopf

YL

[robert]

@falk
Nur eine Frage aus Usersicht. Ist überhaupt sichergestellt, dass die meisten (alle) User, die ein S9y Blog betreiben auf ihrem Webspace auch PHP5 zur Verfügung haben?

Ohne jetzt überlange Zöpfe mitzuzerren. Ich habe mich immer wieder bei Wordpress Usern gewundert, wenn die schrieben, dass man vor einem Update Plugins abschalten soll und danach nicht sicher war, welche noch funktionieren.
Diese Sicherheit bei S9y, dass auch ältere Plugins noch funktionieren etc. ist/war ein Plugspunkt.

Natürlich muss man irgendwann einmal Schluss sagen. Aber nur wenn die User da auch mitkönnen.

[falk]

@yellowled
Lass ihn dir schmecken ...

@robert
Du musst wissen, das der Support für PHP4 im März diesen Jahres eingestellt wurde. Bis 8.8.08 gibt es zwar noch Sicherheitsupdates, aber das war es dann. Die Provider haben über fünf Jahre Zeit gehabt, endlich PHP5 auf ihren Servern zu installieren. PHP5 bietet eine Menge vorteile und erleichtert das Programmieren. Und wenn ich ganz ehrlich bin: Ich habe mir schon überlegt, von S9y zu wechseln, weil die reine PHP5-Unterstützung so lange auf sich warten lässt.
Alle User, die kein PHP5 beim Provider haben, sollten dringend den Provider wechseln. Und die derzeitigen Plugins sind PHP5-kompatibel.
Was ich derzeit mache ist nicht die API von Sy9 zu ändern (also die Schnittstellen), sondern ein refactoring, also eine Quelltextbereinigung. Mein Ziel ist es, die Version 1.3.1 soweit auf PHP5 umzustellen, dass diese als Diskussionsgrundlage oder besser für eine Weiterentwicklung genommen werden kann. Ich habe mir anfangs sogar überlegt, das ZendFramework in S9y zu integrieren, doch das wäre zu viel Arbeit. Deshalb ist dieser Gedanke derzeit (leider) auf Eis gelegt.
Klar wird es irgendwann Kompatibilitätsprobleme geben. Aber, he, das ist Weiterentwicklung. Wer rastet, der rostet. Und wer nicht mit der Zeit geht, geht mit der Zeit.