Die Zukunft von Serendipity

[Timbalu]

Smarty3 ist weitgehend kompatibel, vollständig in php5 geschrieben und IMHO eigentlich nur ein Gewinn.

Überblicke:
http://www.smarty.net/v3_overview (en)
http://it-republik.de/php/artikel/Neue- ... ml?print=1 (de)

Benchmarks:
http://blogs.kd2.org/bohwaz/?2009/09/30 ... te-vs-dwoo
http://cedric.emisfr.info/en/tag/smarty-vs-dwoo/

Alternativen:
bei http:// dwoo.org/ müsste man erst noch prüfen wie es um die Kompatibilität steht. Ansonsten ist dies eine interessante Alternative.

Migrating:
http:// smarty-php.googlecode.com/svn/trunk/distribution/SMARTY2_BC_NOTES

(leider nur 4 vollständige links erlaubt, bitte zusammensetzen)

und hier was für unsere Frontendler Fröhliche Weihnachten YL!

== newline at {if} tags ==
A \n was added to the compiled code of the {if},{else},{elseif},{/if} tags to get output of newlines as expected by the template source.
If one of the {if} tags is at the line end you will now get a newline in the HTML output.

und

== Delimiters and whitespace ==
Delimiters surrounded by whitespace are no longer treated as Smarty tags.
Therefore, { foo } will not compile as a tag, you must use {foo}. This change
Makes Javascript/CSS easier to work with, eliminating the need for {literal}.
This can be disabled by setting $smarty->auto_literal = false;

Ian

[kleinerChemiker]

Man könnte auch überlegen, eine DB-Abstrahierung wie ADOdb einzusetzen um die Probleme mit den verschiedenen DBs zu minimieren.

[yellowled]

Ich würde jquery als Defaultbibliothek nutzen wollen. Man müsste mal überlegen wie man dann mit Plugins vorgeht, die jquery ja bereits bundleln, ob mehrere referenzierte jquery versionen dann große probleme machen. Im Plugin selbst kann man sonst sicher die s9y version überprüfen und dann jquery unterbinden.

Es ist definitiv die weit verbreiteteste, sehr wahrscheinlich diejenige, die für Einsteiger am zugänglichsten ist, und damit wirklich die richtige Wahl, zumal wir sie in der Tat z.T. schon nutzen.

Mehrere referenzierte Versionen sollten weder nötig noch wünschenswert sein, aber man müsste einige der JS-aber-kein-jQuery-Plugins prüfen. Ich weiss z.B., dass das Lightbox-Plugin bei eingebundenem jQuery nicht mehr tut. Das sollte aber absolut kein Problem sein, schließlich gibt es haufenweise jQuery-Lightboxen und den noConflict-Modus in jQuery.

Das mit der "Widget area" ist mir noch nicht so klar, seitenleistenplugins sind ja nie wirkich fix in ihren ausmaßen?!

Äh, und? In Drupal kann man z.B. (so weit ich weiss templateseitig) Widget-Bereiche definieren, in denen dann meinethalben 3 Platzhalter für Codeblöcke (Plugins, Widgets halt) vorgesehen sind und in die man dann im Backend per Drag 'n' drop je einen Codeblock ziehen kann. Dasselbe kann man auch mit Seitenleistenplugins machen. Es ist vermutlich eine gute Idee, dass templateseitig zu regeln, da das Template eben auch für eine korrekte Darstellung sorgen muss, aber es erleichtert die Handhabung von z.B. horizontalen Seitenleisten halt enorm, wenn ich als Templateautor davon ausgehen kann, dass in der Seitenleiste maximal z.B. 4 Plugins sitzen. Denen kann ich dann z.B. in einem Grid-Layout eine feste Breite verpassen und gut.

Für die konkreteren Diskussionen zu den Einzelwünschen wäre ein neuer Thread ganz praktisch...

Vielleicht erstmal sammeln und dann in einzelnen Treads diskutieren? Sonst gibt das wieder so einen unlesbaren Monstertread wie seinerzeit bei BP ...

YL

[onli]

Bei den Kern-Features hätte ich gerne eines, dass das Aufräumen der Datenbank nach bestimmten Kriterien aus der Adminoberfläche heraus möglich macht.

Ich hab mich durch deinen Kommentar an dbclean erinnert, was ja sowieso durch deinen Wunsch entstanden ist. Keine Kernfunktion und das mit den bestimmten Kriterien meintest du wahrscheinlich auf einer anderen Ebene (dbclean kann nur nach Zeit löschen), aber ein Anfang. Vll dazu dort weitermachen?

[Lux]

Ich hab mich durch deinen Kommentar an dbclean erinnert, was ja sowieso durch deinen Wunsch entstanden ist. Keine Kernfunktion und das mit den bestimmten Kriterien meintest du wahrscheinlich auf einer anderen Ebene (dbclean kann nur nach Zeit löschen), aber ein Anfang. Vll dazu dort weitermachen?

Yip, gute Idee!

Gruss

Dirk

[seraphyn]

Ich würde mir wünschen, dass ich Areas selber in dem template definieren kann und diese auch bei "Plugins verwalten" wiedergespiegelt werden. Es müssten nur in der index.tpl/entries.tpl die variablen ausgelesen werden
Im Grunde eigentlich wie bei Drupal 7.
Sprich ich habe mein tempale definiert mit menu, content, left, right, footer, teaser 1, teaser 2 teaser 3, footer 1, footer 2, footer 3.
Das Aussehen definiere ich natürlich in der CSS dafür, die Areas definiere ich wie gehabt in der index.tpl, oder entries.tpl
Wenn ich un im "plugins verwalten" bin, kann ich anstelle links, versteckt und rechts die Plugins auswählen und per DropDown in die Area verschieben in welcher ich sie haben möchte.
Dazu kann man noch ein Gewichtungsauswahl hinzusetzen, falls sich mehrere Plugins eine Area teilen.
Die Abwärtskompatibilität wäre auch gegeben, da die Variablen für Links, Rechts versteckt beibehalten werden können und die alten Themes im Grunde noch gleich angesprochen werden.
Das würde eine starke Freiheit bieten in dem Sinne der Templategestaltung.

Grüsse Chris

[yellowled]

Wenn ich un im "plugins verwalten" bin, kann ich anstelle links, versteckt und rechts die Plugins auswählen und per DropDown in die Area verschieben in welcher ich sie haben möchte.

Das haben wir schon eine ganze Weile, das Template muss nur entsprechend vorbereitet werden:

http://www.optional-necessity.com/archi ... lates.html (englisch)

YL

[seraphyn]

Ja Hallo,

das ist wohl an mir vorbeigeflogen.
Englisch kein Problem.
Wie wäre es jenes in den neuen Code anstelle eines Plugins einfliessen zu lassen?
Auf alle Fälle werde ich mal damit ein wenig arbeiten und mir das Ganz mal komplett durch die Finger gehen lassen.
Dankeschön für den Hinweis

Grüsse
Chris

[yellowled]

Wie wäre es jenes in den neuen Code anstelle eines Plugins einfliessen zu lassen?

Hmtja, ich hatte das bereits als Vorschlag für die Zukunft eingebracht, bin aber irgendwie™ daran gescheitert, Garvin die Vorteile von widget areas in Drupal nahe zu bringen. Vielleicht gelingt Dir das eher?

YL

[seraphyn]

Also gerade bei Beginnern sehe ich es als Heavy factor an, wenn sie ein template selbst erstellen und dann das Plugin nutzen und damit klarkommen müssen.
Es sind ja nur Links und rechts vorhanden, dann sollte wenigstens diese beiden noch um footer und header/teaser erweitert werden.
Gerade in Punkto Anpassung ist das viel wert.
Ich habe auch nach zwei Monaten angefangen mir meine eigenen templates zu erstellen und es war eine mächtige Hackerei es so zu machen, wie ich es wollte.
Z.b habe ich meine dents von ident.ica oben in den Header positioniert und bearbeite die index.tpl direkt um den Footer nutzen zu können. Ja nach dem Wissen um das Plugin hätte ich mir das ersparen können.
Nur wenn man sieht, dass ich schon seit 2006 serendipity nutze und dies an mir vorbeiflog ( Plugin), wie ist es dann bei einem Beginner?
Vor allem im Bereich smarty- und template-hacking
Für mich war drupal in einer Sache toll und dies waren die Areas die ich selber und ziemlich simpel definieren konnte. Für mich spricht eines gegen Drupal als Blogsystem, das ist die Geschwindigkeit, der massiv hohe Grad an Einstiegsanforderung im Lernbereich.
Wenn man nach Gut 6 Monaten Drupal auswendig kennt, dann merkt man auf einmal, dass es so viele Plugins gibt um den Inhalt, die Darstellung noch massiver zu ändern, dass es bald keine Lust mehr macht, Abhängigkeiten der Plugins mitzuinstallieren und zu lernen.
Somit, ist mein einziger Hänger eigentlich, das ab Werk serendipity einfacher und besser zu handeln ist, aber gerade der Bereich der Selbstdarstellung der Homepage in diesem Bereich laggt.
Natürlich muss es nicht wie bei drupal sein, sonst würde ich drupal nutzen und nicht die Stammseite in HTML4 strict und mein Blog mit serendipity betreiben

Also ich würde mich einfach freuen, wenn wenigstens noch zwei Bereiche eingeführt werden würden, damit man ein typisches Header, Left, Right, Footer-Model ab Werk hat.
Das ganze natürlich weiterhin mit dem Verzicht auf, ich muss Script in meine Seite zur Darstellung einbinden. Ich gehe davon aus, dass viele Besucher Script doch der Sicherheit wegen ausschalten (Letzteres funktioniert auf meiner Hauptdomain nicht, wegen Design, aber das ist halt Portfolio LOL)

Grüsse und würde mich freuen, wenn Garvin nochmals etwas dazu sagen könnte...
Chris

[onli]

Man könnte auch überlegen, eine DB-Abstrahierung wie ADOdb einzusetzen um die Probleme mit den verschiedenen DBs zu minimieren.

Ich würde das gerne nochmal aufgreifen. Ich bin vor kurzem darüber gestolpert: Auf meinem lokalen Testblog nutze ich lighttpd mit sqlite, und ich hatte wirklich Bedenken ob ich jetzt nicht in Probleme mit Plugins rennen werde. Was mich wiederum daran erinnerte, wieviel Aufwand es war, für spamblock-bayes die Importfunktion mit drei verschiedenen SQL-Methoden zu realisieren.

Wenn wir eine Datenbankabstraction hätten, die Unterscheidungen zwischen den Datenbanken im (Plugin-)Code unnötig macht, wäre das glaube ich etwas tolles.