Beta 2.0 - Statische Seiten

[Timbalu]

Darf ich noch ein paar Wünsche äußern?

...äußern schon ...

Bei WP werden die permalinks automatisch durch Javascript ausgefüllt (sind trotzdem manuell zu ändern), abhängig vom Titel der neuen Seite. Es ist schon ein wenig nervig, viermal den Titel einer Seite in vier Felder eingeben zu müssen (Kopfzeile, Seitentitel, Url-Titel der Seite und Permalink).

Ja, das wäre bestimmt cool. Allerdings habe ich dazu zwei Anmerkungen. Ich selber verwende nur für zwei Felder (Kopfzeile, Seitentitel) die gleichen Strings und auch das nicht immer. Permalink und URL-Titel sind oft komplett anders, ersteres, weil ich gerne kurze staticpage Uris verwende, und für das zweite eigentlich nur einen möglichst einzigartigen (kurzen) Einwortnamen verwende. Aber da bin ich vielleicht auch zu eigen.
Die zweite Anmerkung bezieht sich auf die voraussichtliche Menge. Ein Blog als CMS aufzuziehen, mit einer signifikaten Menge an Staticpages (um den Aufwand zu rechtfertigen), wirft leider noch andere Fragen auf, die ungelöst sind, namentlich, wie man zb eine Menge über 15-20 Seiten noch gut verwalten kann, ohne eine extra entrypaging Navigation einzubauen. Ich kann mich nicht erinnern, in der ganzen Zeit, in der ich mit Serendipity zugange bin und das Forum lese, dass jemand einmal vor einem solchen Problem stand. Das scheint es wohl nur theoretisch zu geben. Insofern ist die Frage berechtigt, ob das den Aufwand wirklich rechtfertigt. Ein paar mehr Meinungen (und vielleicht auch ein paar diesbezügliche snippet Vorschläge) wären also sicherlich angebracht.
Das etwas konservative handling von Serendipity bei solchen Sachen hat eventuell auch den Vorteil, dass man nicht in kurzer Zeit eine unüberschaubare Menge an Staticpages zusammenklickt, sondern vielleicht eher erst einmal eine Site-Planung für dieses Werkzeug macht.

Generell zum Editor: Wie wäre es, auf die zwei Fenster zu verzichten und stattdessen einen Umbruch einfügbar zu machen, der dann den erweiterten Eintrag enthält? (Idee auch wieder von WP).

Du meinst damit sicherlich das "Template" das früher "Simple Form" und jetzt "Default Form" heißt, nicht wahr? Hast du schon einmal auf das "Responsive Template" geschaltet? Oder liege ich da falsch und du meinst mit "Fenster" die 'Collapsible Boxes'?

Mit "Custom" muss ich mich mal noch beschäftigen.

Das ist auch nichts neues, nur jetzt schon mal in einem der Templates aktiviert, so dass es überhaupt bemerkt werden kann. Gebrauchen wird man das sicherlich nur selten.

[ICE]

Sagen wir mal so ... ich würde manchmal echt gern S9Y auch als CMS einsetzen, einfach, weil man darin heimisch ist (so von wegen Eierlegende Wollmichsau). Ich würde sogar noch weiter gehen, für mehr als 10 statische Seiten wird es im Augenblick viel zu unübersichtlich, die neue Baumansicht im 2.0 backend ist aber schon einmal ein weg für mehr Seiten ... Dafür ist das handling der Seiten im backend im Augenblick einfach zu schwurbelig. Du hast recht, meistens bleibt es bei einer Projektseite, einem Impressum und einer Startseite ... und dafür reicht es, so wie es jetzt ist... es könnte aber geschmeidiger werden

Nee, ich meinte die doppelten Textareas nicht nur im Zusammenhang mit den statischen Seiten, sondern auch beim verfassen von Beiträgen. Aber ich denke, aus Gründen der Abwärtskompatiblität sollte man an den zwei Texteingabefenstern festhalten...

[Timbalu]

Dafür ist das handling der Seiten im backend im Augenblick einfach zu schwurbelig.

Na, lass das mal nicht den YL hören... (Was auch immer du damit meinst...)

Du hast recht, meistens bleibt es bei einer Projektseite, einem Impressum und einer Startseite ... und dafür reicht es, so wie es jetzt ist.

Nicht immer. Ich habe schon sites damit erstellt, aber es wurden eigentlich nie mehr als 10-12 statische Seiten, wenn man sich ein wenig zusammenreißt.

... es könnte aber geschmeidiger werden

Daran kann man ja arbeiten, wenn das genauer definiert wäre. So richtig genaues kann ich mir da nicht vorstellen, mit der Aussage.

Nee, ich meinte die doppelten Textareas nicht nur im Zusammenhang mit den statischen Seiten, sondern auch beim verfassen von Beiträgen. Aber ich denke, aus Gründen der Abwärtskompatiblität sollte man an den zwei Texteingabefenstern festhalten...

Das ist ein völlig anderes Fass! Und müsste bitte gesondert gepostet werden.

[yellowled]

Na, lass das mal nicht den YL hören... (Was auch immer du damit meinst...)

Höh? Ich hab statische Seiten im 2.0-Backend noch nicht mal gesehen.

Und ich sage darüber hinaus seit Jahren, dass man s9y meiner Meinung nach eher nicht als CMS für etwas einsetzen will, was mehr als 10-15 statische Seiten hat, die womöglich noch hierarchisch verschachtelt sind, Vertrautheit mit dem System hin oder her. (Was aus meiner Sicht nicht schlimm ist, es ist halt ein Blogsystem und wird als solches entwickelt.)

Das liegt u.a. daran, dass das (nur für mich, andere mögen das anders sehen) der Punkt ist, an dem das Handling von statischen Seiten im Backend unübersichtlich und zäh wird. Hinzu kommt, dass es keine gute Möglichkeit gibt, aus statischen Seiten bequem eine dynamisch erzeugt Navigation zu erzeugen und in ein Theme zu integrieren.

YL

[Timbalu]

Höh? Ich hab statische Seiten im 2.0-Backend noch nicht mal gesehen.

NA, dann wird das aber Zeit! Wenn das von ICE nur auf die SP gemünzt war, nehme ich alles zurück.

Hinzu kommt, dass es keine gute Möglichkeit gibt, aus statischen Seiten bequem eine dynamisch erzeugt Navigation zu erzeugen und in ein Theme zu integrieren.

Ja, darüber habe ich mich vor kurzem auch geärgert. Da habe ich das mühevoll per Hand machen müssen. Bzw, eigentlich eine Sache der Navigation Erzeugung in template configs.

[yellowled]

NA, dann wird das aber Zeit! Wenn das von ICE nur auf die SP gemünzt war, nehme ich alles zurück.

Ich finde es wichtiger, erstmal den Kern einigermaßen fehlerfrei zu kriegen.

Ja, darüber habe ich mich vor kurzem auch geärgert. Da habe ich das mühevoll per Hand machen müssen. Bzw, eigentlich eine Sache der Navigation Erzeugung in template configs.

Der schwierige Teil ist eben auch, dass man in einer (globalen) Navigation irgendwie auch den Blog-Teil mit einbinden wollen würde sowie ggf. von Plugins erzeugte Seiten, die technisch gesehen auch statische Seiten sind. Und das alles eben so, dass es sich dynamisch aktualisiert, wenn neue Inhalte angelegt werden. Hart kodierte Navigationen werden ab einer gewissen Seitenkomplexität unwartbar.

YL

[ICE]

Ich habe jetzt nichts mehr geschrieben, weil ich kein Öl ins Feuer gießen wollte. Bin aber positiv überrascht, dass das mit dem Menü ähnlich gesehen wird, deswegen kann ich ja jetzt noch folgendes schreiben:

Ich bin seit 2005 S9Y-Anwender und finde, es ist ein ausgesprochen schönes System.
Ein Blick über den Tellerrand Richtung WP hat mich aber vor knapp einem Jahr staunen lassen. Die statischen Seiten sind dort mittlerweile wirklich gut gelöst, auch der Aufbau eines Menüs ist losgelöst vom Template in einem eigenen Menü-Bereich. Ich muss nicht bei jeder statischen Seite einen Schalter anklicken "Im Menü anzeigen", sondern kann das ganz zentral an einer Stelle machen.
Ich denke, das liegt bei S9Y einfach daran, dass die statischen Seiten ein Plugin sind und nicht zum Kern gehören. Die hart kodierten Links (die auch noch selbst als Url einzutragen sind) in den Templates sind meiner Meinung nach nicht mehr zeitgemäß .. es ist ja noch nicht mal eine weitere Ebene unterhalb der Hauptebene möglich (aufklappendes Menü).
Wenn man S9Y aber wirklich nur als Blog sieht, so reicht es wirklich ...

[Timbalu]

Ich habe jetzt nichts mehr geschrieben, weil ich kein Öl ins Feuer gießen wollte.

Hier gabs kein Feuer. Alles ganz freundschaftlich!

Ich muss nicht bei jeder statischen Seite einen Schalter anklicken "Im Menü anzeigen", sondern kann das ganz zentral an einer Stelle machen.
Ich denke, das liegt bei S9Y einfach daran, dass die statischen Seiten ein Plugin sind und nicht zum Kern gehören.

Wahrscheinlich. Allerdings auch, weil das Plugin sooooo unübersichtlich war, was sich gerade durch meinen kleinen Beitrag ändern könnte (jedenfalls ein wenig).
Mit den Schaltern pro eigener Seite, gibt es jetzt auch noch ein paar mehr Möglichkeiten der Vorbelegung in der Staticpage Plugin Config.

Die hart kodierten Links (die auch noch selbst als Url einzutragen sind) in den Templates sind meiner Meinung nach nicht mehr zeitgemäß .. es ist ja noch nicht mal eine weitere Ebene unterhalb der Hauptebene möglich (aufklappendes Menü).

Nun, man bräuchte tatsächlich Ideen, wie sich so etwas more neatless mit Serendipity verbinden lassen könnte, dass es zu einem echten Gewinn führt, bei gleichzeitiger Kompatibilität. Das ist ja auch mehr eine Kombi aus Staticpage und Template Menu, und damit durchaus etwas schwieriger zu lösen.

[yellowled]

Ich denke, das liegt bei S9Y einfach daran, dass die statischen Seiten ein Plugin sind und nicht zum Kern gehören.

Das stimmt grundsätzlich schon. (onli hatte auch schon mal einen Denkansatz, das zu ändern.)

Was Du allerdings auch nicht vergessen darfst:

s9y ist ein reines Open-Source-Projekt, das von einem sehr überschaubaren Team von freiwilligen Entwicklern in ihrer Freizeit entwickelt wird. Hinter WordPress steht seit Jahren (neben der Community) eine 230 Mitarbeiter umfassende Firma, die sich zwar nicht ausschließlich, aber eben auch um die Weiterentwicklung von WordPress kümmert.

Dieser Vergleich muss hinken.

YL

[onli]

Das Plugin für statische Seiten ist ziemlich alt. Der Code hat im Laufe der Jahre ziemlich gewuchert - so sieht er zumindest aus - und die Benutzerführung ist furchtbar. Mein Ansatz das zu verbessern findet sich hier, ich hab das damals für 2.0 hintenangestellt (und ein bisschen das Interesse verloren gehabt). Wenn Ians Überarbeitung das Plugin aufräumt wäre das toll.

PS: Ich habe nie kapiert, warum das Plugin so kompliziert ist. Alles, was es für mich können müsste, wäre einen Texteditor bereitstellen und das so erzeugte HTML unter einer URL anzeigen. Das gepaart mit einem sauberen Menü reicht für die Usecases, die ich sehe - aber das reguläre staticpage-plugin scheint viel mehr Sonderwünsche abzudecken.

[Timbalu]

Wenn Ians Überarbeitung das Plugin aufräumt wäre das toll.
... das reguläre staticpage-plugin scheint viel mehr Sonderwünsche abzudecken.

Ja und Ja.
Immerhin rund 800 Zeilen Einsparung im Plugin selbst sind eine ganze Menge und die >=99% Trennung von Anwendungslogik und Präsentationslogik machen das Leben mit diesem Monster viel einfacher.
(Ich habe auch fast das Gefühl als sei es jetzt schneller geworden! (mit der 4.19))

[Czorneboh]

ICE am 28.04.2014, 05.16 pm:

Darf ich mal frech dazwischen fragen und einen Wunsch äußern?

Ich komme mit der Auflistung der statischen Seiten im Backend einfach nicht klar. Ich habe mir schon so oft andere Statische Seiten zerschossen, dass ich so langsam darüber fluche.
Wenn ich eine Seite bearbeite, so kommt es manchmal vor, dass ich oben in der schnelle eine andere Seite aus dem Dropdownfeld wähle und auf speichern drücke ... damit habe ich dann ganz schnell die andere Seite mit der gerade bearbeiteten überschrieben ... Okay, ganz klar Bedienfehler von mir, nur leider passiert mir das immer wieder, ...

Mir ist das auch mehrmals passiert, dass ich bestehende statische Seiten überschrieben habe. Dabei habe ich nicht mal bemerkt, dass ich daneben getippt habe bei den Buttons.

Was also richtig toll wäre, wenn die statischen Seiten in einem Baum angezeigt werden und nicht über ein Dropdown-Feld. Klickt man innerhalb des Baumes auf eine statische Seite, so gelangt man auf diese Statische Seite und kann sie bearbeiten. Mit einem Klick auf speichern, gelangt man dann wieder zur Baumansicht.

Ist da was zu machen?

Baumstruktur mit child und parent fände ich auch toll. Hilft sehr bei der Orientierung.
Weil hier schon über die Menge von statischen Seiten, die ein Blog gewöhnlich braucht, geredet wurde: Ja, ich habe ziemlich viele statische Seiten.. Ich benutze das Premium-Template "Kinetic". Bin also, was den Umfang angeht, kein durchschnittlicher Blogger mehr.

Bei mir liegen die statischen Seiten auf bis zu 3 Ebenen verteilt.

Bei Kinetic kann man seit Version 1.2. oder 1.3. im Backend Teilbereiche, die man nicht braucht, zuklappen, so dass man die untere Ebene (die Unterpunkte eines Bereiches, z.B. Bereich 1. Navigationsleiste, Bereich 2. Navigationsleiste u.a. nicht sieht. (Ich glaube, dass hat YL gemacht.). Man muss dann nicht weit srollen und erspart sich angestrengtes Gucken. Hatte mich sehr gefreut, als dieses Feature kam. Da hat sich ein Wunsch erfüllt.

Ich verstehe aber, wenn der Baum abgelehnt wird, weil es dafür zu wenige in Frage kommende Nutzer gibt. Ich insistiere da nicht weiter.

Aber wir hatten mal die Diskussion (von mir angeregt) zum Thema S9y bekannter machen durch Bemühungen, in einschlägigen Medien über das nächste große Upgrade (damals war es 1.7., bald ist es 2.0) berichten zu lassen oder aus unserem Kreise Artikel schreiben zu lassen, mit dem/denen das Interesse von (potentiellen) Bloggern geweckt werden soll (wenn wir die hoffentlich in Zeitschriften/auf wichtigen Portalen unterbringen können).

Und dann geht es darum, was man alles wie leicht machen kann, wie gut man "durchsieht", den Funktionsumfang.
Für Anfänger wäre das dann wenig relevant, aber mehr relevant für schon erfahrene, internetaffine User, auch für kleine Unternehmen (wobei: dann kommen viell. noch andere Anforderungen wie Datenschutz hinzu, die nicht mit s9y zu erfüllen wären; weiß nicht)

Ich weiß: das Coden ist die eine Sache. Das Reklamemachen noch mal eine ganz andere. Niemand weiß jetzt schon, wo man für einen Artikel für s9y bereit ist Platz zu verschenken. Und wer (oder welches Team) es schafft, einen betreffenden Artikel zu den Vorteilen an sich und die Neuerungen im Besonderen zu schreiben.

Es sind häufig die begrenzten Ressourcen, Wünsche nach bestimmten Features ablehnen zu müssen. Dafür habe ich Verständnis.

Es könnten sich aber auch mehr User hier beteiligen ...

[yellowled]

(Ich glaube, dass hat YL gemacht.)

Ich habe mit Kinetic nichts zu tun.

Niemand weiß jetzt schon, wo man für einen Artikel für s9y bereit ist Platz zu verschenken.

Ich will natürlich niemandem ausreden, im Print- oder Online-Bereich einen s9y-Artikel zu veröffentlichen. Insbesondere kleine Redaktionen in dem Fachbereich sind oft dankbar für externe Artikel, sofern man nicht mit einer Entlohnung rechnet, die über ein Belegexemplar und eine namentliche Nennung hinaus geht.

Aber: Das Interesse an s9y fernab von sehr spezialisierten Redaktionen (z.B. PHP-spezifische) ist meines Wissens sehr gering. Die Zeiten, in denen es in Auflistungen beliebter Blogsysteme als erste Alternative zu WP genannt wurde, sind vorbei.

Davon mal ganz abgesehen ist die 2.0 aus meiner Sicht noch weiter von einem stabilen Release entfernt, als es angesichts der schon recht gut funktionierenden Beta den Eindruck machen mag.

YL

[ICE]

Davon mal ganz abgesehen ist die 2.0 aus meiner Sicht noch weiter von einem stabilen Release entfernt, als es angesichts der schon recht gut funktionierenden Beta den Eindruck machen mag.
YL

Echt? Ich dachte noch ne beta 3 und dann wäre es schon so weit!

[Timbalu]

Baumstruktur mit child und parent fände ich auch toll. Hilft sehr bei der Orientierung. [...] Bei mir liegen die statischen Seiten auf bis zu 3 Ebenen verteilt.

Der Wunsch von ICE (soweit ich das verstanden habe) waren Entrylisten ganz allgemein, nicht speziell Baumstrukturen für parent/child Äste. Dieser (p/c) Baum wäre (vielleicht) einzig (wirklich) sinnvoll für Kinetic User. Das ist - wie schon gesagt - eine geschlossene Benutzergruppe mit geschlossenem Code. Ich halte es nicht für sinnvoll, etwas besonderes nur für solche Fälle zu implementieren, besonders wenn man nicht davon weiß, wie das genau gemacht ist.

Trotzdem ist die parent/child Struktur ja bereits seit längerem implementiert, Kinetic hin oder her. Deshalb habe ich jetzt in der pre 4.20 version für >= 2.0 only eine einfache treeview-artige Ansicht für das entrylisting und das pageorder-listing experimentell ermöglicht. Im selectfield war das (sogar als echte Treppe) schon immer da.

Weil hier schon über die Menge von statischen Seiten, die ein Blog gewöhnlich braucht, geredet wurde: Ja, ich habe ziemlich viele statische Seiten.

Von wievielen reden wir hier? Gibt es mehr Nutzer bei denen das dann so(...) ist?

Ich verstehe aber, wenn der Baum abgelehnt wird, weil es dafür zu wenige in Frage kommende Nutzer gibt. Ich insistiere da nicht weiter.

Vielleicht kannst du ja mit der oben erwähnten experimentellen (eher simplen) Ansicht auch leben, ohne das man dafür alles umbauen muss. Ich habe außerdem noch vor, eventuell eine Filterfunktion einzubauen, mit der man die staticpage listings individuellen Bedürfnisssen in der Sortierung anpassen kann.

Siehe aktuelle screenshots:

simple-treeview.png (99.13 KiB) Viewed 4727 times

pageorder-simple-treeview.png (56.01 KiB) Viewed 4727 times