Weblog Kommentare
Styx-Stand: 3.0.1 (18.06.2020)
Beat Post author am |
Habe (fast) alle Styx-Installationen auf 3.0.1 upgedatet. Dabei ist mir auf www.styx.dokumenzi.ch aufgefallen, dass es ein Problem mit den Seitenleisten zu geben scheint (in PURE-Theme). Diese werden nämlich nur eingeblendet, wenn beidseitig Seitenleisten-Plugins installiert sind. Nur links oder nur rechts funktioniert nicht. Das heisst, es wird dann überhaupt keine Seitenleiste angezeigt.
Dieses Problem kann ich hier, mit PURE-BEAT-Therme, reproduzieren.
Beat Post author am |
Auf www.styx.beatsblog.ch (ebenfalls 3.0.1) zeigt mir der Altlastenmanager folgende Themes an:
- blue
- 2styx
- kubrik
- competition
- default-rtl
- carl_contest
- default-xml
- idea
- contest
Der Button "Lösche gewählte Themes" scheint nicht zu funktionieren. Egal, ob ich ein Theme oder mehrere Theme anwähle. Sie werden mir immer wieder angezeigt. Alle Verzeichnisse haben eine 755-Berechtigung. Mir ist auch nicht klar, weshalb diese Themes angemäkelt werden. Die gehören doch zu den Kern-Themes?
Für mich ist das kein wirkliches Problem. Ich wollte es nur kommuniziert haben. Die übrigen Installationen zeigen diese Themes im Altlastenmanager nicht an.
Ian Styx am |
Dies ist weil dein theme noch keine neue index.tpl hat - es fehlt das section grid mit den enstprechenden smarty conditions der seitenleisten. Ich glaube nicht das das wirklich das original pure theme ist.
Ian Styx am |
Sie gibt es aber alle nicht mehr, bzw sind kein Teil der Auslieferung mehr und müssen weg. Diejenigen die neu in additional_themes gelandet sind, sind auch potentiell neuer. Also muss etwas mit den Berechtigungen nicht stimmen, was zu den anderen Berechtigungssachen (zb local) bei Manitu passt. Setzte sie mal rekursiv auf 770 dann müsste es gehen oder frage mal nach was zu tun wäre damit deine Wartung das machen darf.
Beat Post author am |
Oder ich lösche die entsprechenden Template-Verzeichnisse einfach per FTP?
Ja. Erledigt. ✔ Der Altlastenmanager ist nun auch happy.
Beat Post author am |
Ich glaube nicht das das wirklich das original pure theme ist.
Hast Du das bei Dir getestet? Auf www.styx.dokumenzi.ch ist nämlich PURE-BEAT gar nicht installiert.
Ian Styx am |
Ja natürlich geht das, aber eigentlich sollte das erlaubt sein. Denn wenn das nicht geht ,geht es auch an anderen Stellen nicht..
Ian Styx am |
Natürlich ohne test geht hier nix raus.
Ich habe einfach in deinen ausgegebenen Quelltext geschaut. Da fehlt eindeutig das Beschriebene.
Ian Styx am |
? 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.
Ian Styx am |
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.
Beat Post author am |
Habe die Änderung in der /pure/style.css vorgenommen und nach www.styx.dokumenzi.ch hochgeladen. Dadurch wird nun wieder die Seitenleiste rechts angezeigt. Weiter getestet habe ich noch nicht und auch hier habe ich das Original-File nicht überschrieben.
So hat die styx.dokumenzi.ch-Installation doch noch einen Nutzen. Denn überall sonst habe ich 2 Seitenleisten im Einsatz und dabei ist der "Fehler" ja nicht aufgetreten.
Beat Post author am |
? Die Testinstallation auf dem Manitu-Server ist ein einziges, riesiges Berechtiguns-Ärgernis. ? . Ich konnte dort noch nie autoudaten. Es werden mir unzählige Berechtigungsfehler aufgelistet (die ich grösstenteils selbst auch nicht ändern kann). Deshalb update ich dort per FTP und wohl auch deshalb waren diese alten Templates noch vorhanden. Ich habe via FTP ja nur vorhandene Dateien überschrieben und nichts gelöscht.
- Habe jetzt ein "Lebowski" Template per FTP hochgeladen.
- Der Altlastenmanager erkennt dieses.
- Ich klicke es an und wähle: "Lösche gewählte Themes"
- Die Backendseite refresht. Klicke ich wieder auf den Altlastenmanager, wird mir wieder Lebowski angezeigt.
- Es ändert auch nichts, wenn ich alle Lebowski-Vereichnisse auf 777 berechtige (das Templates-Verzeichnis hat 775)
Es scheint, als ob der Befehl "Lösche gewählte Themes" nicht funktioniert.
Wenn ich genau das Gleiche hier, auf dem Hosttech-Server mache, dann funktionert es, ich erhalte die Meldung "Gut gemacht! Themes erfolgreich gelöscht!" und auch physisch wurde das Verzeichnis vom Server gelöscht. Es handelt sich hier also nicht um eine Styx-Fehlfunktion, sondern es liegt an dieser fucking Manitu-Konfiguration. ?
Zum Glück habe ich diesen ? nicht auf www.beatsblog.ch (Woher jedoch diese Probleme auf www.styx.beatsblog.ch kommen, ist mir unerklärlich).
Für Dich heisst das: Alles bestens! ? Du musst nichts unternehmen.
Ian Styx am |
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.
Ian Styx am |
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?
Beat Post author am |
Beide, Live-Blog sowie auch der Testblog, liegen direkt im /web-Verzeichnis (also nebeneinander) und haben beide Berechtigung 770.
Wie sie kreiert wurden? per FTP- > FileZilla -> Verzeichnis erstellen.
Beat Post author am |
Wie gewünscht.
www.blog.dokumenzi.ch und www.styx.dokumenzi.ch haben nun das überarbeitete /pure/styles.css und das PURE-Theme. Hier mit 2 Seitenleisten, auf www.styx.dokumenzi.ch mit nur 1 Seitenleiste.
Ian Styx am |
Das pure theme braucht es nicht, also ab damit, nur die pure style.css musste gleich gesetzt sein.
Ian Styx am |
Habe das noch mal überarbeitet und bereits commitet. Wäre schön wenn wir das bei dir nochmal überprüfen könnten.
Ian Styx am |
Es muss heißen: webp und openssl v.1.1.1d, also mindestens Debian 10 ( Buster), alike.
Wie auch immer: Löse dein Permission Problem(e). Es könnte u.a. das kleine delay zumindest etwas lösen helfen auch wenn man nicht an die Proxy Geschwindigkeit von hosttech herankommt. Auf Dauer wäre Manitu alleine auch billiger.
Ian Styx am |
Kannst du wieder löschen. Danke. Das sagt leider nix aus, außer das ich den März Überschlag vom hier kenne (vielleicht wg Sizilien). Warum der Juli so abging, keine Ahnung.
Ich hatte das eigentlich geschrieben, um einen größeren Vergleich zu bekommen, ob sich durch die starke Erweiterung der Spider/Bot Liste etwas wesentliches geändert hat. Und zuviel draufschauen macht mitunter blind für die Betrachtung eines "unbeleckten" Users. Das geht mir leider immer öfter so...?
Beat Post author am |
Also webp funktioniert mit GDLib, jedoch nicht mit ImageMagick.
Wäre da also noch die OpenSSL-Geschichte. Was ist denn jetzt hier (hosttech) schlechter als bei Manitu? Das habe ich immer noch nicht wirklich verstanden. Meine letzte Information von hosttech ist, dass hier OpenSSL v. 1.0.2 im Einsatz ist.
Ian Styx am |
Doch. WebP in Styx ist ja so komponiert, dass es mit beiden arbeiten kann, vorzugsweise ImageMagick.
Dein IM ist - wenn es dort nicht arbeitet - dann einfach noch zu alt, also nicht Debian Buster (10) alike.
Das gespeicherte LOGIN benötigt mindesten OpenSSL 1.1.1d + für die starke Verschlüsselung, ansonsten kann man nur mit session basierten Logins arbeiten und hat soetwas wie den Wartungsmodus nicht, oder dass man immer als identifizierter Autor kommentieren kann, etc.
Nervt dich das mit dem entrypaging Delay so? (Dann arbeite mit Manitu an den Permissions! ?) Ich bin immer noch der Meinung, dass es eigentlich an dem Plugin selbst nicht wirklich liegen kann. Selbst Firefox zeigt in den DevTolls inzwischen eine Schildkröte an (wie lustig) und meint, dass man eigentlich 500ms statt 1.500ms erwarten sollte.
Beat Post author am |
Schau, ich bin ein einfaches und harmoniesüchtiges Gemüth ?. Ich scheue die Diskussionen mit Manitu, weil ich mich dem nicht gewachsen fühle.
Hinzu kommt, dass ich die Hosting-Oberfläche von hosttech (PLESK) besser kenne und einiges komfortabler empfinde als diejenige von Manitu. Und ja, der Geschwindigkeitsunterschied zwischen dieser Installation und beatsblog.ch auf dem Manitu-Server ist einfach frappant (bei Einzelseiten gegen die 2 Sekunden).
Und letztendlich sind die Hosttech-Server in der Schweiz und als Schweizer sollte ich doch wohl die hiesige Wirtschaft unterstützen, auch wenn ich die gleiche Leistung im EU-Raum günstiger kriegen kann. Und, sobald ich eines der Hostings kündige, wird es für mich günstiger. Egal für welche Seite ich mich entscheide.
Beide Verträge laufen bis in den Januar 2021. Also bis Ende November will ich mich entschieden haben, wo und mit wem ich weiterfahre. Es handelt sich letztendlich nicht nur um den privaten Blog. Ich hoste noch an einer dritten Stelle, für sündhaft viel Geld, die www.bikebutler.ch-Homepage. Idealerweise würde ich das alles in einem einzigen Hosting-Paket abfackeln.
Ian Styx am |
Es ist mir völlig klar, dass du wieder zurückwechselst und zwar zu demjenigen mit dem schnellsten, größten und kompaktesten Angebot. Ich maule mit den Permissions auch nur rum, weil man soetwas nicht lassen sollte, ob nun hier oder da oder dort (und eventuell auch unsere Diskurse vereinfachen könnten). Ich habe mit Manitu nix zu schaffen, also auch keine Preferenzen in diese Richtung. Scheuen muss man da eher weniger, denn man ist ja Laie (und kann somit nicht abschätzen was die bisherigen Versuche in ihrer Gesamtheit eventuell verstellt haben) und bittet um professionelle Hilfe (da man ja auch bereits viel Geld dort hinterlassen hat).
Das einzige was an dem hosttech Nginx Proxy zu monieren wäre, dass er, außer der Vorspiegelung falscher Tatschen (bezüglich echter Requests) - selten genug - auch so seine kleinen Macken hat. Für die Auffindung von Styx Macken ist eine ehrliche ud direktere Interaktion natürlich zu wünschen, sonst bemerkt man sie vielleicht gar nicht.
Und na klar - absolutamente - 3 Stellen die nur dein Bestes wollen sind mindestens 2 zuvie!
Mache ihnen einfach Beine dass die ihre Serverumstellung bis zum Ende des Jahres gebacken kriegen. 2021 kommt schon das nächste Debian raus. Und diese Distro ist wirklich konservativ! ?