Was bewirkt Bildgrösse berechnen

[bautti]

im Admin kann man unter Konfiguration/Bild Optionen "Bildgrösse berechnen" auf  ja oder nein setzen. Ich habe beides probiert und jeweils neue Artikel mit den selben Bildern angelegt. Ich merke aber keinen Unterschied. Sowohl die gespeicherten Bilder im den diversen product_images Ordnern sind identisch als auch im Frontend bemerke ich keine Unterschiede, auch nicht wenn ich mir die Bilddetails anzeigen lasse. Ich habe auch die Bilder in den jeweiligen Ordnern gegen größere Bilder ausgetauscht, auch hier macht es keinen Unterschied ob Bildgrösse berechnen auf ja oder nein eingestellt ist.

Mich würde interessieren was die Auswirkungen von "Bildgrösse berechnen" sind. Mit der Forumsuche habe ich nichts gefunden. Kann es sein dass die Funktion nicht bei allen Templates verwendet wird?

Linkback: https://www.modified-shop.org/forum/index.php?topic=40963.0

[noRiddle (revilonetz)]

Die Funktion steht immer zur Verfügung, egal welches Template verwendet wird.
Man muß aber auch den Imageprozessor laufen lassen (Module => System Module => "Imageprocessing - Produktbilder").
Wenn du keine Unterschiede siehst kann das daran liegen, daß der Browser die Bilder aufgrund von CSS-Befehlen skaliert, was als nicht gut gilt, da Bilder die, z.B. bei den Thumbnails im Produkt-Listing, größer sind als angezeigt wird
- wie gesagt durch CSS -
längere Ladezeiten und mehr Prozessor-Resourcen verbrauchen, denn die Bilder sind ja eigtl. größer.
Hochskalieren ist noch schlechter weil darunter die Bildqualität leidet,

Die Wahrscheinlichkeit, daß CSS die Bilder sklaiert ist bei responsive Templates hoch, ja so gut wie sicher, weil Bilder mit CSS adaptiv gestylt sind, d.h. sich an diverse Bildschirmgrößen automatisch anpassen. In der größt-möglichen Ansicht sollten die eingestellten und somit durch den Imageprozessor generierten Bilder allerdinsg genau den CSS-Angaben entsprechen.

Überprüfe mal wie die wahren Bildgrößen sind (mit Browser-Tools wie Rechte Maustaste => "Element untersuchen").

Gruß,
noRiddle

[bautti]

Also ganz blicke ich nicht durch. Das Modul Imageprozessor ist doch dafür da wenn man die Größe der bereits gespeicherten Bilder abändern will. Oder wenn noch keine popup, thumbnails oder info Bilder vorhanden sind. Wenn man neue Produkte anlegt muss man da nichts installieren, das funktioniert auch so (im Hintergtund läuft das wahrscheinlich schon, aber man muss nichts einstellen)

Vielleicht habe ich mich auch nicht ganz gut ausgedrückt. Die Bilder werden in den jeweiligen Ordnern auf die richtige Größe Skaliert, aber eben egal ob ich Bildgröße berechnen aktiviert habe oder nicht....

Ich habe jetzt auch mal die ganzen Fotos im Ordner thumbnail_images gelöscht und dann den Imageprozessor mit aktivierter Funktion "Bildgrösse berechnen" gestartet. Dann habe ich die Fotos nochmals gelöscht und die Funktion "Bildgrösse berechnen" deaktiviert und nochmals gestartet. Das Ergebnis war beide mael das selbe, die Bilder wurden auf die richtige Größe skaliert. Das habe ich mit WinSCP überprüft, es kann als nicht daran liegen dass der Browser irgendwas an den Bildern ändert. Der 2.05 Shop ist neu aufgesetzt. Und gestern habe ich es auch beim neu erstellen von Produkten getestet mit dem selben Ergebnis.

Ich glaube dass die Einstellung "Bildgrösse berechnen" einfach keine Funktion mehr hat.

[noRiddle (revilonetz)]

Du hast Recht.
Kann man mal sehen, ich ging immer davon aus, daß das so ist wie ich beschrieben habe, habe es aber nie überprüft.

Die Einstellung "Bildgrösse berechnen" wird lediglich dort benutzt wo die Funktion xtc_image() aus /inc/xtc_image.inc.php benutzt wird, was bei Artikelbildern nicht der Fall ist. Sie wird lediglich im Frontend bei einigen Icons benutzt (z.B. Sprach-Icons, Bewertungs-Icons) und berechnet bei im Code nicht angegebenen width und/oder height-Werten die genannten Werte.

Die Bezeichnung "Bildgrösse berechnen" ist völlig unzureichend und irreführend, wie so manche Bezeichnungen und Beschreibungen im Backend es schon lange sind. irgednwie will sich darum jedoch niemand kümmern.

Bei der Recherche habe ich auch noch eine nicht verwendete Konstante namens IMAGE_REQUIRED in o.g. Funktion gefunden die rausfliegen kann.

Wärst du so nett ein Ticket anzulegen zu dem Thema ?
Entweder muß die Funktion xtc_image() angepasst werden wie sie im Backend ist, ohne Abfrage von CONFIG_CALCULATE_IMAGE_SIZE (= "Bildgröße berechnen"), oder die Konfiguration bleibt bestehen und muß verständlicher bezeichnet und beschrieben werden.

Gruß,
noRiddle

[bautti]

Danke für deine Recherche. Vielleicht war es bei früheren Versionen ja mal so wie du und ich ursprünglich vermutet hätten.

Ich habe Ticket #1793 diesbezüglich erstellt.

[snocer]

Ticket ist ja angeblich gelöst. Nur zeigt der Updatecheck keine neue Version an. Was ist zu tun das auch die neuesten Updates verarbeitet bzw. eingelesen werden? Und ich war bisher auch der Meinung, das der imageProcessor die Bildgrößen berechnet. Ich lade hochauflösende *.png hoch mit ca. 2MB Größe diese haben danach eine Größe von ca. 120-300KB bei den Artikelbildern. Also scheint doch etwas zu funktionieren außer das nur die Bilder auf Vorgabewerte verkleinert werden. Bei nur einer Verkleinerung von wenigen Pixeln sollte ja nicht solche Abweichungen bei den Bildgrößen geben.

Bin da auch eventuell jahrelang auf einem Holzweg gewesen, weil die Beschreibung im Backend dann doch recht irreführend ist und im Handbuch Hilfe dazu auch nichts steht.

cu snocer

[noRiddle (revilonetz)]

Was genau meinst du mit "die neuesten Updates verarbeitet bzw. eingelesen werden" ?
Welche Updates denn ?

Der Imageprozessor berechnet ja auch die Bildgrößen (px-Größen), wer hat etwas anderes gesagt ?
Daß diese Bilder beim Hochladen über das Backend bei der Produktbearbeitung allerdings bereits durch den Prozessor laufen und man diesen also nicht extra starten muß wenn man alle Bilder so hochlädt war das Thema.

Außerdem gibt es ja noch die Kompressionsrate (im Backend = "Bildqualität") und diese sorgt evtl. ja auch für eine geringere Dateigröße (= KB oder MB).

Gruß,
noRiddle

[snocer]

Habe beim Ticket gelesen das es in der Version 2.0.5.1 behoben wurde. Diese Version steht nicht zur Verfügung. Bisher ist immer noch 2.0.5.0 aktuell. Das mit den Bildern wollte ich nur bestätigen. War da auch auf dem Holzweg.

[noRiddle (revilonetz)]

Und ?
Es ist für und nicht in 2.0.5.1 behoben. Denkst du, daß für jeden kleinen Fix gleich eine neue Version rauskommt ?

Gruß,
noRiddle

[snocer]

Neue Version? Wir sind immer noch bei 2.x.x. Natürlich gehe ich davon aus, dass ein Hotfix erst Recht wenn ein Ticket als gelöst markiert wurde auch in den aktuellen Build einfließt. Bei uns und auch bei uns bekannten Software Firmen ist das jedenfalls so. Auch MS, Datev etc. stellt die Hotfixes sofort zur Verfügung ohne das eine neue Hauptversion erschienen ist. Einer muss das Problem ja hier angefasst haben und gelöst haben.

Du beschwerst Dich hier öfter mal über ein nicht verstehen von Schreibweisen und Zusammenhängen bei diversen Schreibern. Deine Antworten ohne Erklärung was Du nun wirklich sagen willst, sind aber häufig auch nicht anders.

Beispiel: Und? Brötchen, Wurst oder Leberkäswecken verstehe ich zum Beispiel auch nicht. Wie Du selbst schon angemahnt hast,  wer nicht in allgemein verständlichen deutschen Sätzen Antworten möchte oder will, sollte eine Antwort weglassen.

Danke, für Deine Antwort.

[Gulliver72]

Hallo snocer,

da ich auch mit den genannten Programmen arbeite und nicht für jede kleine Änderung einen extra Hotfix bekomme, scheint bei dir ein grundsätzliches Mißverständnis in Bezug auf Updates zu bestehen. 

Da dies kein sicherheitsrelevanter Fix ist, wird dieser nicht außer der Reihe veröffentlicht. Vielmehr werden die Korrekturen als Updatepaket 2.0.5.1 zu gegebener Zeit vom modified-Team zusammengefasst.

Bis dahin müssen wir uns alle gedulden.

Und das du noRiddle derart angehst, ist unnötig.
Er mag zwar seine Eigenarten haben      , aber er ist immer hilfsbereit und eine große Bereicherung der Community.

VG Gulliver

[Timm]

@snocer
Für wichtige Tickets kann man sich die Änderungen im Bugtracker als changeset herunterladen und muss nicht auf die Veröffentlichung der nächsten Shopversion warten.

Und natürlich ist der Fix im aktuellen Build enthalten. Kannst du unter dev.modified-shop.org sehen. Nur wird nicht jeder Build einzeln veröffentlicht, sondern als Paket mit mehreren gelösten Tickets irgendwann als neue Shopversion veröffentlicht. Nicht anders ist es doch bei iOS und Android zum Beispiel.

Dass man übers Backend des Shops auf Update klicken kann und automatisch die neueste Shopversion erhält ist gar nicht machbar, da man auch eigene Änderungen in Dateien haben kann, die damit überschrieben würden. Das würde nur funktionieren, wenn man sämtliche eigene Änderungen updatesicher außerhalb von Shop Coredateien machen könnte. Was aber noch unmöglich ist.

Gruß Timm

[snocer]

Danke hier erst einmal an alle die sich die Mühe machen auch hier zu Antworten.
Es war auf keinen Fall meine Absicht hier einem wirklich aktiven Mitglied auf die Füße zu treten.
Bin nur nicht, bzw. noch nicht über die Gepflogenheiten der Update Politik vollständig im Bilde.
Daher auch an Euch noch einmal Danke für die Aufklärung. Ich war und bin da vielleicht zu verwöhnt.
2. = Version, 0 = Update, 5x = Hotfix etc. war so mein Verständnis.
Ich hatte auch das Problem mit dem CSV Import, habe das aber auch vorab mit dem manuellen hochladen gelöst gehabt und konnte nun aber feststellen, das das Problem bereits in der aktualisierten Version 2.0.51 als gelöst markiert ist. Dazu noch viele andere Sachen die mir ebenfalls aufgefallen waren. Laut dem aktuellen Trunk sind ja alle 61 Bugs etc. als gelöst markiert. Also sollte ja einer aktualisierten Version nichts im Wege stehen.
Und das eigene Funktionen etc. Update sicher ohne Core Änderungen funktionieren sollten ist für mich eine Selbstverständlichkeit.

Möchte hier noch einmal ausdrücklich betonen, dass das Team hier wirklich eine gute Arbeit macht und das System das macht was es sollte. Bin sehr zufrieden mit der Lösung. Und @noRiddle ist wirklich sehr aktiv und hilfsbereit. Spezial Dank auch an Ihn.

Grüße Mathias (Alias snocer)

[Timm]

Laut dem aktuellen Trunk sind ja alle 61 Bugs etc. als gelöst markiert. Also sollte ja einer aktualisierten Version nichts im Wege stehen.

100% gelöste Tickets der 2.0.5.1 gab es schon mehrfach in den letzten Monaten. Da kann man nichts draus schließen. Kann morgen kommen aber auch erst in ein paar Monaten. Es gab sogar mal eine Aussage vom Team das die Version vermutlich innerhalb einer Woche kommt. Seit dem sind Monate vergangen.

Und das eigene Funktionen etc. Update sicher ohne Core Änderungen funktionieren sollten ist für mich eine Selbstverständlichkeit.

Dein Shop kann nicht stark modifiziert sein. Um etwas updatesicher zu machen, müssen auch die entsprechenden Hookpoints vorhanden sein. Und das ist in vielen Fällen nicht der Fall. Ich hab vermutlich mindestens eine hohe zweistellige Anzahl an angepassten Core Dateien, für meine extra Module, weil es nicht anders geht.

Bsp: Amazon Pay 3 Shop Core Dateien die zig Templatedateien zählen ja nicht für Updatesicherheit.

Das würde nur gehen, wenn sämtliche externen Module in der modified Version enthalten wären, was nie passieren wird. Oder wenn es für jede Eventualität einen Hookpoint gibt und die Entwickler externer Module diese dann darauf anpassen. Wird aber auch nicht so schnell passieren. Ich vermute auch, dass jeder zusätzliche Hookpoint den Shop langsamer macht, weil erst geprüft wird, ob in einem bestimmten Verzeichnis eine extra Datei liegt und wenn ja, diese eingebunden wird.

Insofern find ich die Aussage etwas realitätsfremd. Nenn doch mal ein Shopsystem, wo alles updatesicher eingebaut werden kann, wenn du das als selbstverständlich ansiehst?

Gruß Timm

[noRiddle (revilonetz)]

Die Hooks machen sich kaum bemerkbar. Man könnte evtl. darüber diskutieren ob man anstatt glob() die php-interne Class DirectoryIterator benutzt. Nach Recherchen im I-Net soll Zweitgenanntes ein wenigs schneller sein (wir reden über /inc/auto_include.inc.php).

Was man vielleicht machen könnte wenn man in /includes/extra/... -Directories mehrere Dateien von mehreren Erweiterungen hat, diese in einer einzigen Datei zusammenzufassen, dann geht das Loopen durch das Directory schneller und es gibt lediglich ein File zu includen.

*NACHTRAG*
Außerdem ist, wenn die mom. noch fehlerbehaftete Cache-Funktion korrigiert wurde, der Cache ein ernormer Beschleuniger.

Gruß,
noRiddle