Styx-Stand: 3.0.1 (18.06.2020)

? Mist! Was ich nicht bedacht hatte war, dass es sich bei styx.doku um ein 1-sidebar Blog layout handelt.

In dem letzten commit für diese Zwecke hatte ich mich um eine Nachwirkung der Grid-Geschichte (zur Vermeidung der layout javascript Verschiebung) gekümmert, falls die content Seite leer ist oder nur einen minimalen content anzeigt, zb wenn man einen freeTag anzeigen lassen will den es gar nicht gibt. Die kleine Änderung hatte ich nicht nochmal auf 1-sb layouts gegengecheckt. Und jetzt ham-wa-den-Salat. Sie ist eben doch noch nicht ganz fertig. Der Versuch solch kaum expandierenden content abzufangen, zeigt eben auch die Limitierung der Grid-Geschichte, soweit ich sie persönlich vollständig erfasst habe; Sie scheint gerade im flexiblen content container abhängig von ihrem (expandierenden) Inhalt und schwierig zu handeln wenn dieser nur ungenügend  vorliegt. Vorstellbar wie ein aufgeblasener Ballon in einem begrenzenden Kasten, respektive dem Browserfenster. Wenn der Ballon darin schlaf herumhängt - weil ohne Luft - kann er auch nicht anschlagen und das Layout halten. Nicht umsonst hatte das vorherige und jetzige 2019 pure theme ein anderes Grundlayout (left, content, right) das dann reaktiv per javascript zwischen mobiles und desktops responsiv gesetzt wird.

Verschiebe das 1024px "display: flex;" im body in Zeile 1873 einfach folgendermaßen in die beiden folgenden als

  body {
    width: 100%;
    margin: 0 auto; }
    /* two sidebars */
    body.grid-col {
      display: flex;
      grid-template-rows: initial; }
    /* no OR one sidebar */
    /* chrome workaround */
    body.grid-flex {
      display: grid;
      grid-template-columns: 1fr; }

Vielleicht können wir das mal testen mit styx.doku und hier auf blog.doku.

Und doch wäre es ganz gut wenn man beide test blogs in den styles gleich hätte, um weitere Eventualitäten auszuschließen. Ich musste gerade noch etwas nachbessern, siehe letzte Zeile.

Das pure theme braucht es nicht, also ab damit, nur die pure style.css musste gleich gesetzt sein.

zb in den upgrade tasks ... mit denen hätte u.a. gelöscht werden sollen "templates/2styx", weil vollkommen durch templates/styx abgelöst, und zb auch "bundled-libs/zendframework". Im Grunde auch Sachen, auf die man sich später verlässt das sie auch echt weg sind. Es wäre also nett wenn du - jetzt nachdem du alles manuell gelöscht hast - mal ein eigenes test theme in den templates Ordner wirfst und den Altlastenmanager erneut testest, vielleicht mit den vorgeschlagenen 770 permissions (rekursiv gesetzt). Ansonsten wirklich mal Manitu fragen, wie sie sich vorstellen, dass man das progammtechnisch händeln soll.

Also beat liegt im übergeordneten /web Ordner, oder?  Welche Berechtigungen hat er?

Wo liegt Styx, auch darin? Oder hat es eigenen "/web" Ordner? Wie wurde dieser kreiert? Welche Berechtung ist dort vergeben?

Gib dem styx directory mal eine neue 770 Berechtigung rekursiv für Dateien und Ordner gesetzt (bevor du das automatische update anstößt)

? Es verhält sich genau umgekehrt.

Es war schon immer so dass das heruntergeladene autoupgrade serendipity-x.y.z.zip File nicht gelöscht wurde, damit man es bei einem error im Falle des Falles schon vorrätig hatte. Der Nachteil war eben das sich im Laufe der Zeit Mengen von Zips ansammelten. Deshalb habe ich vor 11 Tagen die Version 1.7.1 herausgegeben und auf der Blogseite zum letzten Release vermerkt, man möge die Option einschalten, bevor man das update laufen läßt. So können - gerade im Falle sehr alter Blogs -  bis zu mehreren 100 MB Platz befreit werden.

Das manuelle Löschen war unnötig. Das wäre automatisch für alle vorliegenden alten autoupgrade zip files beim nächsten autoupdate geschehen.

Unerhört❗ ?

? Tja nun.., so ist es eben. Er erlebt, was man so erlebt, wenn man sich da hineinpuzzelt. Ihm fehlt ein wenig das historische Verständnis, warum manches so ist wie es ist, und vieles gut ist, so wie es ist.

Der Hauptgrund warum es mit s9yorigin eher abwärts geht, ist der fehlende Maintainer, der die Dinge vollständig beurteilen und durchblicken kann. Da kostet Zeit und viel Verantwortungsgefühl. Ohne jemand nahe treten zu wollen; Das will oder kann heute keiner der Gebliebenen mehr. Sie haben sich für die Öffentlichkeit als die ("führenden") Entwickler positioniert, aber nehmen diese Führung nicht wahr. Das war früher anders.

Nun ist es aber so, dass Serendipity ein wirklich Klasse System ist! Es ist wirklich Genial und ich habe es wieder und immer wieder erlebt, dass die große Weitsicht der Anlage es zu einem komplexen aber enorm leistungsfähigen Kunstwerk macht, mit dem man auch heute wunderbar arbeiten kann, ohne das Gefühl zu haben auf einem argen Klepper zu sitzen.

Insofern ist zwar das "Geflenne" über die fehlende Verbreitung und fehlende Wahrnehmung von Außen verständlich, aber nicht zielführend. Man muss positiv herangehen und unterstreichen, dass dieser Schatz es wert ist erhalten zu bleiben und weiterentwickelt zu werden. Es braucht Leidenschaft! [Und stete Weiterentwicklung!] Das ist es was ich mit Serendipity Styx versuche. [Es wäre übrigens ein fataler Irrtum, würde man diese Weiterentwicklung auf den besseren WYSIWYG Editor reduzieren.]

Verantwortung zu übernehmen heißt aber auch Dinge abzulehnen oder eben auch (zum Zeitpunkt) nicht zu übernehmen, wenn diese nicht wirklich erklärt sind oder aber sehr (oder zu) komplex werden (und damit potentiell Auswirkungen auf das System haben) um eine kleine (und vielleicht nur sehr spezielle) Erweiterung zu ergänzen und ins System einzufügen. Ein verantwortungsbewußter Maintainer würde also eine (erklärende) Antwort geben, möglichst zügig.

Verantwortung zu übernehmen heißt auch, es zu verteidigen gegen diejenigen, die dieses Grundverständnis nicht mitbringen und daran herumkritisieren, dass es nicht komplett objektorientiert geschrieben sei, oder nicht heutigen Gewohnheitseffekten wie automatischen code-binding, usw. unterliegt, alt und bäh sei, oder das wordpress doch so viel mehr verbreitet ist, denn Millionen Fliegen könnten ja wohl nicht irren... ?

Ja, das ist mühsam und erfordert den scharfen Blick bis ins Kleinste zu erhalten. Nur als kleines Beispiel sei hier genannt die ursprüngliche Namensgebung für bestimmte strukturelle (HTML) Grundgerüste, die bis in die Templatestruktur und damit auch Plugins hineinwirkt. Verändert ein Template Designer diese "Variablen", weil sie ihm zu lang und zu mühsam sind, ihm zu vorsintflutlich vorkommen, so unterbricht er die Kette. Das muss erkannt und unterbunden (und erklärt) werden. Dazu gehört eben auch historische Kenntnis, dass es eben auch mehr gibt, als die git code Basis hergibt.

Für Styx habe ich entschieden, dass bestimmte Versionssprünge eben auch bestimmte Zöpfe abschneiden um damit die urspüngliche Bwegungsfreiheit wiederherstellen. ZB bei den Templates. Sie laufen heute alle als HTML5 und sind alle auf dem aktuellen Stand, was die Beziehung zu Styx und zu Smarty angeht. Das Design ist von damals; Ja! Aber das kann man ja ändern. Jeder muss doch seinen eigenen Weg finden, so wie du es für pure-beat gemacht hast. Es ist halt nicht klickibunti - fertig, mit polierten Oberflächen und Hochglanz Optik, die mehr versprechen als sie halten.

Amen! ?

... ? ...

Vielleicht nur so viel dazu...

... gibt es den unweigerlichen Konflikt zwischen dem was ich will und dem was der Haupt-Maintainer will.

Das wird dir - so wie allen neueren Mitarbeitern an einem Softwareprojekt - potentiell immer und überall so gehen. Und deswegen gibt es ja auch Maintainer! Sie geben die Vision vor und wissen um die Umstände. Bremsen also allzu forsche Mitstreiter auch mal ein; auch im Ton. Sie erklären und/oder bestimmen was auf welche Weise hineinkommt. Und wenn sie gut sind, werden sie deine Bemühungen eher weise in die richtige Richtung lenken, als sie brüsk zurückzuweisen. Aber ihr Wort gilt und muss dann auch akzeptiert werden. So ist das nun mal. Und das ist gut so! ?

✔ supi!

Jetzt musst du nur noch die CSS styles Option abschalten damit deine user styles wieder wirken. ☺

Och nee--- wie dumm.

Ich hatte eine Rückfall-style-option eingebaut. Die auch im Falle von nein (da diese Option eigentlich für die Aufhebung von eventuellen Linkstyles gedacht war) trotzdem deinen Abstandhalter-styles nahe kommt - leicht abgeändert als default. Da das aber nicht im durchgereichten eventData Stream ist und damit in die serendipity.css eingefügt wird, und damit dann über deinen user styles stünde, sondern einfach per runtime als styles in die sidebar geschrieben wird, steht es eben darunter. So musst du das eben anders überschreiben - entweder mit important (was eher zu vermeiden ist) - oder das du statt

.mediasidebaritem img {...}

ein

#serendipityRightSideBar .mediasidebaritem img {...}

in deiner user.css benutzt. Letzterer hätte als Knoten (-anweisung) die höhere Priorität.