Die Zukunft von Serendipity

[micha]

Hi,
jetzt habe ich mir zwei Tage, zumindest zum Teil, einen Kopf gemacht wie s9y erweitert werden könnte. Tatsächlich muss ich sagen, dass s9y als Blogsystem komplett ist. Eigentlich gibt es nur vier Dinge, die mich in den letzen Jahren gestört haben und die Tatsache, dass ich trotzdem bei s9y geblieben bin, zeigt, dass sie so schlimm auch nicht sind

Bilder in Artikeln (wurde hier schon diskutiert)

Galerie
Eigentlich ein Plugin Thema. Sollte aber meiner Meinung nach als "must have plugin" gesehen werden. serendipity_event_usergallery ist im Prinzip ganz ok, nur wird es mir in der Adminoberfläche zu unübersichtlich wenn mal mehr als zwei Galerien definiert sind. Zudem fehlt mir die Möglichkeit Vorschaubilder automatisch in einen Blogartikel einzubauen.

Caching
Ich halte das Caching der Seiten für eine wunderbare Methode die Last auf dem Server niedrig zu halten. Leider verträgt es sich nicht mit allen Plugins. Hier wäre ein Mechanismus, der das Caching verbietet, wenn Plugins installiert werden die damit kollidieren, sinnvoll.
Schön wäre auch eine komplette HTML Exportfunktion, die jedesmal wenn ein neuer Artikel geschrieben wird, die Seiten als HTML ablegt. Damit wäre zum Betrachten des Blogs (fast) kein PHP Aufruf notwendig.

Plugin Mangagement
Die Reihenfolge der Ereignisplugins ist für mich nach drei Jahren immer noch ein Mirakel. Hier wäre ein Automatismus nützlich, vielleicht auch mit der Möglichkeit sich gegenseitig ausschliessende Plugins bei der Installatio zu erkennen.

Mehr fällt mir leider (oder zum Glück) nicht ein. Auf die kommende Version freue ich mich schon und bedanke mich schon im voraus für die ganze Arbeit, die dafür geleistet wird.

micha

p.s. Legt bei der Gelegenheit PHP4 ad acta. Wer wirklich noch PHP4 braucht hat mit s9y 1.3.x immer noch ein gutes Blogsystem zur Verfügung.

[kleinerChemiker]

und wer wirklich noch kein php5 hat, kann ja immer noch die derzeitige version von s9y verwenden.

[Dr. Love]

Ich muss falk zustimmen was die PHP5-Sache angeht. Ein Refactoring schadet selten und wenn es stimmt, dass die PlugIns alle bereits PHP5 kompatibel sind, sehe ich keinen ernsthaften Nachteil, sondern nur Vorteile. PHP4 ist raus und wer es noch einsetzt kann das gerne tun. Aber dann braucht er auch nicht zu erwarten, dass neue Versionen von Software (egal welche) darauf noch Rücksicht nehmen.

[Lux]

Mir fallen auf Anhieb drei Vorschläge ein, die ich gerne einbringe.

0. Bereinigung und Überarbeitung der Styles und Templates
(Ich bin immer davon ausgegangen, dass Styles und Templates, die über die - offizielle - Spartacus Schnittstelle kommen valides HTML erzeugen. Matthias hat ich leider eines besseren belehrt).

1. Versionierung von statischen Seiten.
(Damit wäre Wiki-Funktionalität gewährleistet.)

2. Versenden des Kommentartextes in den Benachrichtigungen
(Hast Du bereits eingebaut und wolltest Du in das nächste Release aufnehmen.)

Punkt 0 wäre mir am wichtigsten.

Gruss

Dirk

[garvinhicking]

Hi!

@Lux: Wenn die invaliden Templates schonmal aufgelistet werden könnten, wäre das ein großer Schritt.

@falk: Ich bin gespannt, was Du alles als PHP5-only ansiehst und verändern möchtest (im positiven Sinne gespannt). s9y ist ja voll PHP5 tauglich, und ausser den PPP-Variablen seh ich eigentlich wenig was man in der API verändern könnte dass es unter PHP4 nicht mehr klappt.

Grüße,
Garvin

[yellowled]

@Lux: Wenn die invaliden Templates schonmal aufgelistet werden könnten, wäre das ein großer Schritt.

Invalide ist das flschae Wort Dirk spricht von "One True Layout", welches sich leider nach wie vor großer Beliebtheit zu erfreuen scheint, aber irgendwie doch mehr ein Versuch als ein Template war.

Es erzeugt meiner Erinnerung nach valides HTML und sollte in den meisten Umgebungen auch problemlos funktionieren, aber es ist leider in puncto CSS nicht so perfekt, wie es der Originalautor gern gehabt hätte. Zudem steht mit Bulletproof mittlerweile eine deutlich bessere Alternative bereit.

YL

[Lux]

Invalide ist das flschae Wort Dirk spricht von "One True Layout", welches sich leider nach wie vor großer Beliebtheit zu erfreuen scheint, aber irgendwie doch mehr ein Versuch als ein Template war.

Jein, ... lass mal beliebige Validatoren über Feeds und Blogs laufen.

http://www.w3.org/QA/Tools/#validators
http://jigsaw.w3.org/css-validator/
http://validator.w3.org/
http://www.w3.org/RDF/Validator/
http://validator.w3.org/feed/
http://feedvalidator.org/

Gruss

Dirk

[yellowled]

Jein, ... lass mal beliebige Validatoren über Feeds und Blogs laufen.

*räusper*

Tut mir leid, aber das, was der W3C-Validator ausspuckt, sind keine Fehler, die auf das Template per se zurückzuführen sind. Das sind - ich habe es nur kurz überflogen, aber auf den ersten Blick - Fehler, die auf Modifikationen Deinerseits zurückzuführen sind (wie etwa das flscha eingebaute favicon).

Dafür (und vor allem dagegen) kann das Template nichts

YL

[Lux]

Dafür (und vor allem dagegen) kann das Template nichts

Ich meinte tatsächlich nicht mein Blog ...

Gruss

Dirk

[Cohnina]

...
@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 nicht 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 wahrscheinlicher 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.
...

Das Link-List Plugin ist bereits im Einsatz, aber ich hab wohl einfach zu viele Links (und bin zu anspruchsvoll)
Für die offizielle Dokumentation reichen meine Kenntnisse leider nicht aus, aber ich bemüh mich ab und an mal einen s9y Beitrag zu bloggen.

[yellowled]

Dafür (und vor allem dagegen) kann das Template nichts

Ich meinte tatsächlich nicht mein Blog ...

Dann nenne bitte andere Beispiele oder noch besser Stellen im Code des OTL-Templates, welche nicht validen Code erzeugen

YL

[Lux]

Dann nenne bitte andere Beispiele oder noch besser Stellen im Code des OTL-Templates, welche nicht validen Code erzeugen

Ich suche gerne ein paar Beispiele heraus, bei denen mir das aufgefallen ist.

Für die Recherche habe ich erst am Wochenende Zeit (auf der Arbeit habe ich leider nur einen sehr kastrierten Internetzugang).

Gruss

Dirk

[MagicV]

Was ich mir noch wünschen würde wären folgende zwei Punkte:

1. Einen Wartungsmodus, für den Fall das man mal die DB oder Dateien warten will, ohne dass es gleich für Beuscher zu verwirrungen und Fehlermeldungen kommt.
Am Betsen würde der Watungsmodus dann in der config.local abgelegt, und eine Datenbankunabhängige Ausgabe auf den Wartungsmodus hinweisen.

2. Eine Möglichkeit neue/andere als das aktive Template in einem "Vorschaumodus" mit dem Blog zu testen, ohne dass es für die "normalen" Besucher eine Auswirkung hat.

[juergen]

Hallo Garvin,

erst einmal ein großes Dankeschön für die geleistete Arbeit der letzten Jahre & das Buch!

Für die nächste Serendipity 1.4 Version fehlen mir noch ein paar sinnvolle Neuerungen, und daher möchte ich bei euch Benutzern anfragen, was die Dinge sind die ihr am meisten vermisst, oder wo ihr den größten Handlungsbedarf seht. Denn daran würde ich dann gerne basteln.

Ich setze s9y in mehreren Installationen ein, nicht nur als klassisches Blog. Daruas entstand der Wunsch, die Artikel / Einträge nicht nur wie bisher nach der Zeit des Entstehens zu sortieren, sondern alternativ nach anderen Kriterien. Zum Beispiel alphabetisch nach dem Titel. Ein praktischer Anwendungsfall: Wenn man (in verschiedenen Kategorien) Personen, Aufgaben, Themen, Literatur, Projekte erfasst und dies alles sinnvoll mit Tags versieht, hat man eine hübsche kleine, aber feine Wissensbasis. Ich habe so etwas fürs Intranet gemacht, dabei störte mich nur die Sortierung. (Der Hack, den Timestamp zu manipulieren, ist nicht komfortabel.)

Also Wunsch 1: Sortierung nach Alphabet als Alternative.

Da es unkomfortabel ist, bei jedem einzufügenden Bild manuell die gleichen Angaben zu machen bzw. die Vorgaben aus editor.js zu ändern, der Wunsch 2: Beim Einbinden von Bildern aus der Mediendatenbank wäre es sehr gut, könnte man hierbei gleich mit angeben
- den alt-Text (wie title-Tag bei Hyperlinks),
- margins (in alle vier Richtungen)
Das sollte dann auch für den Image-Style funktionieren, bei dem wegen der Bildunterschrift ein Rahmen ums Bild erzeugt wird... Vielleicht auch mehr Optionen als die jetzigen drei zum Platzieren des Bildes, zum Beispiel ein Zentrieren.


Wunsch 3: Ein differenzielles Update als Option, bei dem nur die Verzeichnisse mit geänderten Dateien auf den Server zu beamen sind.


Wunsch 4: Wartungstools in der Admin-Oberfläche. Zum Beispiel eine Information über die Größe und Möglichkeit zum Löschen der Inhalte der spamblock-Tabellen.


Soweit erst 'mal.

Viele Grüße,

Jürgen

[garvinhicking]

Hi!

Also Wunsch 1: Sortierung nach Alphabet als Alternative.

Man kann dafür bereits das plugin "Erweiterte Eigenschaften für Kategorien" einsetzen, und dann pro KAtegorie individuelle Sortierung setzen, wie auch global für die Startseite. Hast Du das mal probiert?

Die Idee für die Bildmanagererweiterung finde ich gut, ich meine, ich hätte das schon irgendwo mit aufgenommen als Todo-Punkt. Muss ich mal prüfen und sonst erweitern.

Wunsch 3: Ein differenzielles Update als Option, bei dem nur die Verzeichnisse mit geänderten Dateien auf den Server zu beamen sind.

Das würde mir den Release-Prozess sehr erschweren. Ich brauche jetzt schon 2-3 Stunden für ein s9y Release...so etwas könnte man nur anbieten, wenn mir jemand anderes dabei hilft und die Dateien alle raussucht die sich geändert haben.

Wunsch 4: Wartungstools in der Admin-Oberfläche. Zum Beispiel eine Information über die Größe und Möglichkeit zum Löschen der Inhalte der spamblock-Tabellen.

Dafür möchte ich ungerne phpmyadmin-funktionialität duplizieren, ich würde eigentlich schon sehr nahelogen solche Wartungstools zu nehmen die weitaus fortschrittlicher sind. Was man machen könnte wäre in den jeweiligen Plugins eine "Leere Datenbank" einzubinden für plugins, die irgendwo caches o.ä. anbieten...?

Grüße,
Garvin