Donnerstag, 2. Januar 2020
Stand: 01.01.2020, 14:18
Die neusten Änderungen betrafen auch das Styling des Banners (vor allem für das mobilemenu). Nun ist mir aufgefallen, dass wenn ich das Browserfenster langsam im der Breite verkleinere (von Voll-Desktop bis zu kleines Mobile), dass die Menüzeile unterschiedlich umbricht. Die zweite Menüzeile wird zeitweise zentriert und zeitweise rechtsbündig dargestellt.
Damit man besser vergleichen kann, habe ich die Menütexte auf styx.dokumenzi identisch wie hier gestaltet (ohne verknüpfte Links). Hier ist das pure-beat-Theme im Einsatz, auf syx.dokumenzi das originale Pure-Standard-Theme.
Dieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2604-Stand-01.01.2020,-1418.html«
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Beat Post author am :
Ian Styx am :
Der Unterschied ist ja folgender: Benutzername ist gleich Loginname, von dem man eigentlich nicht möchte, dass er jedem "Hacker" des Loginforms schon so einfach im Frontend bekannt gemacht ist.
Wahrend der "full name" derjenige ist, mit dem du überall in der Öffentlichkeit ausgewiesen wirst.
Die entries Tabelle hält eben den Loginnamen - wahrscheinlich um einfacher das multi-user System zu unterstützen - und weil man wohl damals annahm, dass der Loginname auch die kürzere Variante wäre.
Das wiederum führte dann 2008 zur Verwechslung des entryauthor(s) mit dem Frontendnamen zur Verifizierung des comment_author_self = Post Authors. Ich bin immer noch am Überlegen, ob ich das nicht sogar für Styx 2.9.x backporten muss, weil es ja wirklich ein Fehler ist. Allerdings hat dies ja definitiv vielfache Auswirkungen auf alle existierenden Themes die eine comments.tpl, bzw pcomments.tpl enthalten.
Erst Styx 3.0 ist da ja vollkommen unabhängig mit seinem eigenen und überarbeiteten additional_themes repository, so dass es eigentlich erst hier richtig Sinn macht.
Beat Post author am :
Login-Name = Benutzername = Author in der entries-DB-Tabelle.
Voller Name = Bedingung für "Post author"-Kennzeichnung.
Wenn ich also nicht mit "Beat Menzi" als "Post author" gekennzeichnet werden will, dann muss ich die Eingabe im Feld "Voller Name" in der Benutzerkonfiguration umstellen (was ich ja getan habe). Identischer "Benutzername" und "Voller Name" ist aber blöd (habe ich mir schon gedacht), weil man so gar nicht mehr wirklich nachvollziehen kann, was woher kommt.
Technisch besser wäre wohl, den Benutzernamen zu ändern, weil (siehe oben: Benutzername = Login-Name) der bisherige Login-Name "Beat" hackermässig megasimpel zu erraten ist.
Wenn das soweit stimmt, kannst Du das hier bestätigen. Aber erst, nachdem Du in unserem gemeinsamen Artikel den neuen Login-Namen gesehen und kopiert hast. Danach wechsle ich. O.K?
Ian Styx am :
Aber ist vor allem wichtig, um zu ordnen. Beispielsweise /serendipity/authors/1-John-Styx. Das also was als $entry.author normalerweise über Smarty ausgeliefert wird, ist nicht der entry.author der Tabelle (denn das ist ja der loginname), sondern der öffentliche Name. Dasjenige, was in den footers oder headers, oder sogar als Adresszeile steht, siehe Beispiel.
Änderung gesehen und Drücke die Daumen.
Ich mag dein radlon, emoticon.
Beat Post author am :
Ian Styx am :
Ian Styx am :
Was aber nur ein eher theoretisches Problem ist, denn es gibt nur Devices mit festen Größen und kein Gerät was fluidabel auf und zu schwebt. Das machen nur Developer in ihren Browser Dev Tools. Wenn du da aber die festen definierten Device Größen testest ist alles in Ordnung, denn daraufhin wurde alles ausgerichtet.
Beat Post author am :
In diesem Zusammenhang: In der style.css finde ich über 10 verschiede Angaben für Screen-Breite. Derzeit ist es hier ja so, dass bis 768px kein Hintergrundbild angezeigt wird und darüber dann die oben dargestellte Grafik. Auf dem iPad meiner Frau ist dieses Hintergrundbild aber zu breit. Ich überlege mir nun folgendes:
Ich bin mir dabei aber nicht sicher, ob die von mir genannten Display-Grössen richtig gewählt sind, denn ich weiss nicht, was diesbezüglich gängige Werte sind. Zudem stelle ich fest, dass die jeweiligen Browser die Breite anders berechnen. So hat mein Mobile zwar eine Bildschirmauflösung von 1080x1920px, diese Webseite wird mir aber mit ca. 480px Breite dargestellt. Da findet irgendeine Umrechnung statt. Meine Frage ist also, wenn Du unterscheiden müsstest zwischen klein-mittel-gross, wo würdest Du die Grenzen ziehen?
PS: Ich frage jetzt nicht, wieso das Hintergrundbild nicht skalieren kann, wie die Bilder in Einträgen. Das wird schon seine Gründe haben.
Ian Styx am :
Ich kann mich nicht erinnern dass ich pure ein Hintergrundbild gegeben hätte...
Grob gibt es ja drei Größen: Mobile Screens, Tablet Screens und Desktop Screens, obwohl auch heute schon Geräte existieren die solche klaren Grenzen verschwimmen lassen.
Dazu muss man noch zwischen landscape und portrait modes unterscheiden.
Das geht von früheren 280px und heutigen 320px bis ca 540/640px und von einem ziemlichen Standard 768px, über 800px bis 1024px und dann eben über Laptop Größen bis hin ins Unendliche, wobei ich sagen würde bei 1920px ist Schluss mit lustig.
Dazu kommen dann noch ppi Pixeldichte (pixels per inch) und solche Sachen, also wenn Geräte Displays mit höherer Dichte anbieten, wie von dir beschrieben. Effektiv sind sie natürlich an die Geräte Zoll-Größe gebunden, zB 6 Zoll Geräte. Da aber die Pixeldichte höher ist, sind sie in der Lage HD etc darzustellen. Wie da genau die Umrechnung passiert, kann ich nicht so aus dem Stehgreif erklären.
Also würde ich sagen deine Abstufung scheint ok. Wie genau das eben auf unterschiedlichen Tablets funktioniert kann ich aus Ermangelung eines solchen nicht sagen.
Beat Post author am :
Mit "hier" meinte ich das pure-beat-Template. Habe "hier" nun insgesamt 5 Varianten eingebaut:
Ich weiss... man kann es auch übertreiben...
...dafür passt's jetzt auf meinem Android-Handy, dem iPhone 7 und iPad meiner Frau und an meinem Laptop (die Bilder sind immer 1'296px breit, wiegen aber nur zwischen 10 und 24kB) 
Ian Styx am :
Beat Post author am :
Ab und zu kriege ich eine error-Meldung, wenn ich ein Bild hochladen will. Heute habe ich nun im Server-error-log mal nachgesehen und folgende Apache-error-Meldung gefunden:
und zeitgleich, Apache-access, Error 500
Heute konnte ich im Backend gar kein Bild hochladen (und machte es dann halt per FTP). Ich glaube aber mich zu erinnern, dass dies schon funktioniert hat. Seit wann genau dieser Fehler also auftritt, kann ich nicht sagen. Sieh es als reine Information.
Auf styx.dokumenzi.ch gibt es diese Fehler nicht.
Ian Styx am :
Man könnte ja jetzt vermuten es hätte vielleicht irgendetwas mit den webP Konvertierungs Versuchen und den bei dir fehlenden Systemgrundlagen zu tun, aber....
Sieh mal unter https://board.s9y.org/viewtopic.php?t=24052
Es kann sein, dass das eine eher verunglückte/mißverständliche Meldung ist, die durch etwas "völlig" anderes ausgelöst ist. siehe die "gelöst" Erfolgsmeldung des thread authors.
Beat Post author am :
Ich habe den S9Y-Thread durchgelesen. Ich denke auch, dass ich mir das Problem mit dem Import der alten image-DB-Daten geholt habe. Ich muss diese Tabelle nocheinmal genau ansehen und mit derjenigen auf styx.dokumenzi.ch vergleichen. U.U. hilft auch leeren und neu befüllen. Mal sehen.
Ian Styx am :
Wie kann man denn beides haben?? Oder schreibt Nginx einfach in sogenannte apche log files?
Beat Post author am :
In meiner Hosting-Bedienungsoberfläche PLESK kann ich Log-Files ansehen. Da habe ich folgende Auswahl:
- Apache SSL/TLS access
- Apache access
- nginx SSL/TLS access
- Apache error
- nginx error
Die erwähnten Fehlermeldungen stehen in "Apache error". Es kann aber auch sein, dass dies nur Filterkriterien sind und alles in einem File steht. Das weiss ich nicht so genau (müsste wohl mit FTP die Error-Files suchen).
Ich bin mir mittlerweile zeimlich sicher, dass die Probleme seit dem Import der bestehenden Medien aus dem Live-Blog bestehen. Ich berichtete in diesem Blog schon am 8.12.2019 erstmals von diesem Error. Jetzt muss ich nur noch herausfinden, wo der Fehler liegt. Welche DB-Tabellen haben explizit mit der Mediathek zu tun?
- images
- mediaproperties
- ?
Ian Styx am :
Das kann also einfach eine interne PLESK Verbiegung sein. (hast DU Nginx eingestellt oder war das schon so?)
Zu den Mediathek Tabellen:
und können auch in
- accees
- references
vorkommen, je nachdem.
Beat Post author am :
Beat Post author am :
Beat Post author am :
Könnte mein Upload-Problem auch daher kommen, dass ich hier nicht alle Mediathek-Verzeichnisse habe, auf die Bilder in der images-Tabelle referenzieren (und deshalb kann die Sortierung nicht durchgeführt werden)? In welcher DB-Tabelle werden denn die Verzeichnisse der Mediathek gespeichert?
Beat Post author am :
Ne, daran liegt es auch nicht. Die Mediathek liest einfach alle Verzeichnisse von /Uploads.
Ich habe nun die über 3'000 Bilder von bbbeat hierhin kopiert. Nach "Mediathek: Vorschauen erneuern", "Behalte alle vorhandenen Vorschaubilder" werden alle Verzeichnisse in der Mediathek mit der richtigen Menge an Inhalt dargestellt.
Das Upload-Problem hat es jedoch auch nicht gelöst.
Ian Styx am :
Ich habe gerade ein Testbild hochgeladen. Kein Problem, außer das keine webP Variationen erstellt werden.
Ich habe das interne Debugging mal auf an gestellt. Vielleicht bekommen wir aussagekräftige Ausgaben in den Wartung Logfiles wenn der Fehler wieder einmal auftritt. Vielleicht aber auch gibt es an dieser Stelle nichts Erhellendes als Debugpoints, wobei ich gerade die Media handler ziemlich aufgebohrt hatte. Sonst muss du halt deine Browser Tools offen haben mit F12 und, wenn der Fehler auftritt, direkt nachschauen was im POST header als eventuell malformed vielleicht darinnen steht.
Ian Styx am :
Ich kann mich dunkel daran erinnern, dass mir das lokal einmal ziemlichen Ärger verursachte und ich das seitdem immer auf AUS stelle.
Ian Styx am :
Beat Post author am :
Danke für all die wertvollen Ratschläge.
Bis vorhin klappte es wirklich nie und ich endete immer auf der 500-Seite. Dann habe ich GZIP deaktiviert und die beiden Grössenangaben entfernt. Und siehe da: Nun kann ich wieder Bilder hochladen! Verstehe das, wer will. 
In der Zwischenzeit bin ich jedoch daran, die mediaproperties-Tabelle zu bereinigen. Da hat es unzählige Doubletten drin, was sicher auch nicht zuträglich ist.
Ian Styx am :
Ian Styx am :
Beat Post author am :
Das Problem ist gelöst.
Ursache war die Bildgrössen-Einstellung in der Konfiguration. Sobald ich ein Bild hochladen will, welches grösser als die eingestellten Werte ist, erzeugt das System diesen Fehler (ich versuchte ja die 1'296px breiten Header-Bilder hochzuladen und die konfigurierte Begrenzung lag bei 1'024px).
GZIP an oder aus spielt keine Rolle (getestet).
Zu den Doubletten in der mediaproperties-Tabelle: Ja, es waren absolut identische Datensätze. Woher die kommen/kamen kann ich nicht sagen, vielleicht habe ich die bereits so importiert. Was ich aber wirklich nicht verstehe, ist die Anzahl der Datensätze. Was entspricht dem "VALUES" in einem Datensatz? Ich habe jetzt aktuell 1'172 Datensätze, pro VALUES deren zwei. die sich nur insofern unterscheiden, dass einmal die User-ID (1) und einmal der Login-Name (Beat oder neu BeatXXXXX) erwähnt wird. Das heisst, in meiner Tabelle sind aktuell 586 VALUES (Werte zwischen 4'879 und 9'438) enthalten. Ich habe aber über 2'500 Blogeinträge und über 3'000 Bilder... da macht die Zahl 586 für mich irgendwie gar keinen Sinn.
Es ist nicht wirklich so, dass ich das verstehen muss. Ich habe einfach kein Gefühl dafür, ob 586 richtig ist, oder zuviel, oder zuwenig.
Ian Styx am :
Dann kannst du die *Log Level* Option jetzt wieder zurücksetzen.
Ich musste im Laufe der Styx Versionen verschiedentlich alte Bugs fixen, die mediaproperties betrafen. Suche mal im changelog nach "mediaprop" um davon eine Ahnung zu bekommen.
Allgemein wird mediaproperties angelaufen und geschrieben, wenn du du die media properties änderst, also über den Medien-Eigenschaften Button das media properties form aufrufst und submittest.
Beat Post author am :
Phua... Diese 4 Std. Aktion hat mich jetzt doch ermüdet... Und dann ist die Lösung so simpel... Software-Entwicklung wäre nichts für mich. Dafür gebührt Dir mein vollster
Ian Styx am :
Beat Post author am :
Ian Styx am :
Wiewohl du eine erstaunliche Ausdauer beim zusammenpuzzeln deines Blogs zeigst!
Beat Post author am :
Beat Post author am :
Eine, nein zwei Fragen hinsichtlich der mediaproperties-Tabelle habe ich noch:
1. Könnte ich die gefahrlos leeren?
2. Muss ich den (alten) Inhalt bei der Blog-Migration in die neue DB importieren? Dies vor dem Hintergrund, dass ich die Tabelle aus meinem S9Y-Live-Blog dann wohl auch erst noch auf Doubletten prüfen müsste.
Ian Styx am :
Zu 2.) Besser, Ja! Das mit den Doubletten würde ich dem Programm selbst überlassen, denn als Laie kann man oft nicht so einfach sagen welches Duplette die eigentlich Wesentliche zu behalten ist. Besser nach und nach all jene Medien, die hier verzeichnet sind, über das Media properties Form aufrufen und erneut speichern. Da das ja gefixt wurde, sollten dann die alten Doubletten auch korrekt entfernt werden.