Kommentare von

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

Deshalb hatte ich mal angeregt nachzufragen wie Manitu User mit Löschungen durch Skripte umgehen sollen, denn das liegt sicherlich an der zusätzlichen Restriktion von Manitu (https://wiki.ubuntuusers.de/Rechte/#Sonderrechte), so dass man dort Berechtigungen eventuell in oktaler Form setzen, a la 0770, 1770 oder 2770, oder das Sticky Bit verwenden muss, je nachdem, oder überhaupt... UND warum das für den web Ordner der Haupt Domain ohne weiteres geht, aber scheinbar nicht für Subdomains.

Das ist eine eher unangebrachte Scham an dieser Stelle.
Ein System wie Serendipity muss im Laufe seines Lebens in der Lage sein auch mal Dinge zu löschen, damit es einigermaßen up to date bleibt. Dazu gibt es im Normalfall Ordner wie "templates_c" oder "uploads" für deren täglichen Betrieb das sogar unerläßlich ist. Ebenso aber auch für plugins, bundled libs oder templates; Ordner, die normalerweise nur normale Rechte bekommen. Aber auch hier muss hier und da eine library ausgetauscht oder ersetzt werden - alles in allem müssen sie writable für den Webserver sein. Soviel allgemein dazu. Dass das auch bei Manitu ohne vorherige Verrenkungen klappt sieht man ja am Hauptblog, lt deiner Aussage.

Den web/ Ordner hat Manitu dir ja schon von vorneherein estellt. darin liegen jetzt dein beatsblog direkt, nehme ich an. Den styx Ordner, oder wie er auch immer heißt, hast du erstellt, um darin das andere test blog zu betreiben und hast diesen dann als subdomain mit dem root Pfad web/styx/ in deiner Administration angelegt. Wieso verhält dich dieser also anders als dein normaler bezüglich der Rechte? Und was musst du demzufolge beachten lernen. Das kann dir immer nur derjenige am besten beantworten der es auch erfunden hat.

? 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! ?

... ? ...