Kommentare von

He was für ein Spaß! 😎 Das hatte Knobelfaktor ‼

Ich habe dir was hinterlassen.

Ich wüßte gerne mal deine Meinung und ob die Berechnungen wirklich stimmen.

Hmm! Da stimmt was nicht...

Wie hast du die Änderungen eingepflegt? Einzeln per Hand oder als ganzes RAW drübergebügelt?

Es fehlt zb auch das transparente image für den Zwischenraum....

AH HALT. Es ist alles da. Ich glaube du (oder ich, beim Verlinken) hast/habe nur die beiden images verwechselt, denn gray ist transparent und vice versa, denn transparent sollte immer die voller Höhe als Separator haben. 😅

Jetzt müsste man nur noch mit etwas CSS den Farbverlauf für das Dark-Theme Backend umdrehen, damit es etwas deutlicher dargestellt wird.

Wie meinst du das?
Gerade dort sieht das doch besonders schick aus... ⁉ ( meine ich )
Das der graue Diagrammstrang von hellgrau zu dunkelgrau aufwächst ist Absicht (und kein CSS).

Hast du das auch auf deinem LIVE Blog aktiv? Kannst du bitte mal einen Screenshot von dem neuen 12 Monats Besucherdiagramm machen und hier hochladen. Du mussst es ja nicht verlinken. Ansehen kann ich mir ja im Backend. Denn über den prozenthaften Algoríthmus für die Verhältnismäßigkeit zwischen dem aktuellen Diagrammstrang und dem neuen Diagrammstrang muss ich zur Sicherheit noch ein paar mehr unterschiedliche Beispiele sehen, um mir gewisser über die korrekte Berechnung zu sein. Meine ungenügenden mathematischen Formelkenntnisse, dass diese Formel auch immer stimmt, helfen mir da leider nicht.

Ich habe es ausprobiert. Es sieht besser so aus wie es jetzt ist.

Dazu musst du nur mal das image umdrehen  (das ja ein Verlauf ist, um den metallischen Effekt zu simulieren).

Hier zum spielen:

.stats_imagecell img {
  transform: scaleY(-1);
}

Aber Achtung, das dreht alle Farben um, nicht nur das grayscale.

Wenn das allzudoll stört müsste man ein anderes gray image bereitstellen.

Ich musste das Statistic Plugin nochmal neu refactorieren, denn die Monatsanzeige ging u.U. über das gewünschte Maß hinaus, gerade bei kleinen und ungenügenden Statistik-Monats-Diagramm-Balken; so habe ich denn neu vermessen und auch die maximal Höhe neu aufgesetzt. Wenn du bei Gelegenheit nochmal einen neuen Screenshot mit deinen guten Zugriffszahlen auflädst und mich hier anpingst, wäre ich sehr verbunden. Ich hoffe das ist besser so.😇

Danke!

Scheint richtig zu rechnen. Ich muss mich aber an die um 100px erweiterte Höhe erst noch gewöhnen, sie schien mir nötig um besser kleinere Zugriffszahlen im Verhältnis zu zeigen..., denn die Darstellungs-Berechnung orientiert sich nun immer am höchsten Satz, dessen Säule dann mit der vollen Höhe angezeigt wird und 300px lassen sich (für Menschen) prozentweise auch besser rechnen...

Kann man das so lassen oder sollte es vielleicht doch etwas niedriger bzw komprimierter?🤔

Ich nehme an das war ein Versuch es an das damals beliebte Servertool Webalizer anzulehnen, das auch verschiedene Farbvarianten für seine Balkendiagramme vorsah.

Die Farben sind nur dafür da die mauen Monate/Tage, gegenüber mittleren und hohen Pegelständen optisch hervorzuheben, damit ein kurzer Blick ohne weitere genaue Zahlenanalyse reicht. Sie werden einfach als 100 durch 3 dekliniert und meinen insofern wohl eher nur soetwas wie: wenige, mittlere und gute Besucher/Zugriffe.

Ich wollte dir nicht hineinpfriemeln, deshalb habe ich ich meinen test mit deinem Entry nicht gespeichert.

Komischerweise werden ja die Bilder nicht angezeigt. Also muss man den Source untersuchen um die Ursache zu erkennen. Suche mit F3 im Editor Source nach source srcset="null", also besser nach allen Vorkommen von srcset="null" und nehme das null weg. Das darf da nicht sein! Sonst interpretiert dein Browser HTML das als Bildurl.

Damit werden die Bilder wieder angezeigt.

Die Frage ist wie hast du diesen Quellcode so erstellt, denn er ist ja offensichtlich irgendwie "bearbeitet"... ⁉

Wenn wir das geklärt haben ist eine weitere Frage ob die webp Images um die es sich da handelt größer (in Kb) sind als die original jpgs ⁉ Siehe in der Mediathek im Bild Info layer.

Es ist also die Frage zu klären wie der string "null" da hinein kommt. Das kann sehr wohl ein Bug sein, denn mit der ganzen Verschärfung der Typisierung von PHP kann mir da sehr wohl ein NULL type durchgerutscht sein, der dann in der weiteren Behandlung irgendwo zu einem STRING type wird... Die Frage ist nur WO ? oder WER ? dafür letztendlich verantwortlich ist.

Verschiedenste Klärungen sind meinerseits bereits erfolgt:

Also " bearbeitet " ist da nix. Mea culpa. Die Umbrüche etc sind der Kommentarfunktion in styx js geschuldet.

Aber all deinen Sizilien Photos fehlt die WebP-Vorschau, also das thumb. Wahrscheinlich hast du diesen image Ordner von beatblog geklaut und hier eingefügt und jene fehlten dort überhaupt oder sind auf dem Transport (FTP?) verlorengegangen. Somit existieren sie nicht und deswegen wird vom System null geworfen. Das muss natürlich korrigiert werden. Aber eigentlich sollte so ein Fall ja auch gar nicht vorkommen. Denn jeder upload produziert webP Variationen entweder ganz oder eben gar nicht.
(Aber "gibts nicht",  gibts nicht, wie man sieht! 😁)

Wie man nun genau vorgeht muss man an den Gegebenheiten abwägen. Ist es ein Fehler im System, war es ein unvorhersehbarer User Fehler beim Übertrag, wie reagiert das System auf unvollständige Variationen wenn man die Variationen neu erstellen läßt? Kann man vielleicht die große Variation löschen und dann jedes Bild einzeln per + neu erstellen lassen. Kann man auf diesem Test Blog überhaupt mit Styx Boardmitteln regieren, da womöglich noch andere versteckte Eigenarten zu finden sind? Fragen über Fragen...🙂

😂 ... hätte ja auch "on the töff" sein können...
Na dann, bis dahin!