MiniSlides - replacement for MiniSlider

[hgs]

I have just tested it and did not have these problems with Firefox. The module was downloaded and installed by Ruud, images inserted and edited with the pencil
WB version 2.13.6
PHP version 8.3.12
Sliders version 1.0.4

[masju]

I changed the version in the backend from 1.9.1 to 3.6.0, no difference, even on another computer.
Firefox 131.0.1.
Chrome and Edge are fine!

Might be an interference with other JavaScripts von the site. I'll keep on exploring.

[sternchen8875]

do you have some more sections on this special page?

[masju]

do you have some more sections on this special page?

Yes, two WYSIWYG and one MiniSlides-Module.

[masju]

I just found another issue, same module, PHP 8.2, when I upload pictures:
Error-Log:

Code: [Select]

Wed, 23 Oct 2024 15:19:14 +0000 [E_DEPRECATED] /modules/minislides/functions.php:[170] from /modules/minislides/functions.php:[170] imagecopyresampled "Implicit conversion from float 843.75 to int loses precision""

[sternchen8875]

a typical PHP 8.1 (and higher) message, currently only a hint (E_DEPRECATED) to the soon invalid function. At this point it is specifically about the size calculation of the thumbs or generally about the size changes after cropping, enlarging or reducing. According to the method used in the module, decimal places would be lost in the calculation, hence the note.

Ideally, notify the module author and wait for an update.

 

[german]
eine typische PHP 8.1 (und höher)-Meldung, aktuell nur ein Hinweis (E_DEPRECATED) auf die demnächst ungültige Funktion. Im Speziellen geht es an dieser Stelle um die Größenberechnung der Thumbs bzw allgemein um die Größenänderungen nach Zuschnitt, Vergrößern oder Verkleinern. Nach der im Modul angewandten Methode würden Nachkommastellen bei der Berechnung verloren gehen, darum der Hinweis.

Idealerweise den Modulautor benachrichtigen und ein Update abwarten.

[masju]

PHP8.2: I had suspected that. I try to contact Ruud.

[German]
PHP8.2: Das hatte ich schon vermutet. Ich schreibe Ruud mal an, danke für den Tipp.

[sternchen8875]

I quote an explanation from php.de on the subject

PHP is a dynamically typed language. As such, there are many cases where type coercion occurs naturally. Most of these coercions are harmless and super-practical.

However, when a float number is converted to an integer, this is often associated with data loss. For example, if the float number 3.14 is converted to an integer number 3, it loses its decimal value.

The same happens if the float is outside the platform integer range, or if a float string is converted to an integer.

PHP 8.1 corrects this behavior and brings dynamic type coercion more in line with most modern programming languages. The goal is to make such constraints predictable and intuitive.

In PHP 8.1, you will see a deprecation note when a non-compatible float is implicitly converted to an int. But what is an integer-compatible float? The RFC answers this:

A float is said to be integer-compatible if it has the following properties:

    Is a number (i.e. not NaN or Infinity)
    Is in the range of a PHP integer (platform-dependent)
    Does not have a decimal part


This hint will be converted to a TypeError in the next PHP version (i.e. PHP 9.0).

So, now the practical part
When resizing an image, e.g. for thumbs, cropping or regenerating, there are fixed values, firstly that of the original image, which is read in from the image info - with getimagesize() - and then a target value for the new image, either the target width or the target height. In the case of the Minislides module, it is specifically about the thumbs, then about a general size limit for the maxi images in the slider (if so set)

Various mathematical functions now run during image creation, e.g. to calculate the aspect ratio from the length and width of the original or to calculate the exact image height from a known target width, taking the aspect ratio into account. In your case (the error message), a value of 843.75 was calculated, which is called a float value. In the further course, however, the calculation continues with whole numbers and the 0.75 would be lost. In the case of an image with a width of 843 pixels, this is a barely visible loss, which is why, in the context of image processing, such a result is converted directly to an integer. What is a rather bearable loss for images of this size would be something significant in the context of other calculations in math, physics or chemistry, which is why PHP points out the loss of precision in the calculation.
Back to the module
originalcode

Code: [Select]

$crop_h = $orig_h*($size/$orig_w);
change to

Code: [Select]

$crop_h = intval($orig_h*($size/$orig_w));only a example

The error message in your post refers to this line 170

Code: [Select]

ImageCopyResampled($result, $image, 0, 0, $x, $y, $size[0], $size[1], $width, $height);
This means that every floating point number used here must be converted into an integer before further use. WebsiteBaker uses this entire image calculation e.g. in the media management or for the captcha and indirectly also for the group image in the news module, which again works via the global function make_thumb().
The method shown here with intval() is only one possibility, the values could also be rounded up with ceil() or down with round(), which may be more accurate.

PHP 9 was supposed to be released at the end of the year, but I can't find any new information about it at the moment. The web is already full of requests of a similar nature and I think that many module authors, especially outside of WB, still have a lot of work to do. In the case of the mini-slider, the upload of images would no longer work.
However, the slide could still work if you manually fill the corresponding folders under /media.




[german]
Ich zitiere mal eine Erklärung von php.de zur Thematik

PHP ist eine dynamisch typisierte Sprache. Als solche gibt es viele Fälle, in denen Typenzwang natürlich vorkommt. Die meisten dieser Zwänge sind harmlos und superpraktisch.

Wenn jedoch eine Float-Zahl in eine Integer-Zahl umgewandelt wird, ist dies oft mit Datenverlust verbunden. Wenn zum Beispiel die Float-Zahl 3,14 in eine Integer-Zahl 3 umgewandelt wird, verliert sie ihren Nachkommawert.

Das Gleiche passiert, wenn der Float außerhalb des Plattform-Integer-Bereichs liegt, oder wenn ein Float-String in einen Integer konvertiert wird.

PHP 8.1 korrigiert dieses Verhalten und bringt die dynamische Typenzwangssteuerun g mehr in Einklang mit den meisten modernen Programmiersprachen . Das Ziel ist es, solche Zwänge vorhersehbar und intuitiv zu machen.

In PHP 8.1 wirst du eine Deprecation-Notiz sehen, wenn ein nicht kompatibler Float implizit in einen Int umgewandelt wird. Aber was ist ein integer-kompatibler Float? Der RFC beantwortet dies:

Ein Float wird als integer-kompatibel bezeichnet, wenn er die folgenden Eigenschaften besitzt:

    Ist eine Zahl (d.h. nicht NaN oder Infinity)
    Liegt im Bereich eines PHP Integers (plattformabhängig)
    Hat keinen Nachkommaanteil


Dieser Hinweis wird in der nächsten PHP Version (d.h. PHP 9.0) in einen TypeError umgewandelt.

So, nun der praktische Teil
Bei der Größenveränderung eines Bildes zur Größenveränderung z.b. bei Thumbs, Zuschnitte oder Neugenerierung gibt es fixe Werte, einmal die des Originalbildes, die aus der Bildinfo eingelesen wird - mit getimagesize() - und dann ein Zielwert des neuen Bildes, entweder die Zielbreite oder die Zielhöhe. Im Falle des Minislides-Moduls geht es speziell um die Thumbs, dann um eine allgemeine Größenbegrenzung der Maxibilder im Slider (falls so eingestellt)

Im Laufe der Bilderstellung laufen nun diverse mathematische Funktionen ab, z.b. um aus Länge und Breite des Original das Seitenverhältnis zu berechnen oder um bei einer bekannten Zielbreite die exakte Bildhöhe unter Berücksichtigung des Seitenverhältnisses zu errechnen. In deinem Fall(die Fehlermeldung) wurde ein Wert von 843,75 errechnet, das nennt man Float-Wert. Im weiteren Verlauf wird dann aber mit ganzen Zahlen weiter gerechnet und die 0.75 wären verloren. Im Falle eines Bildes mit 843 Pixel Breite ein kaum sichtbarer Verlust, darum ist man im Rahmen der Bildbearbeitung dazu übergegangen, ein solches Ergebnis direkt zu einem Integer zu machen. Was bei Bilder dieser Größenordnung eher ein verschmerzbarer Verlust ist, wäre im Rahmen anderer Berechnungen in Mathe, Physik oder Chemie schon etwas wesentliches, darum von PHP-Seite der Hinweis auf die verlorene Präzision in der Berechnung.
Zurück zum Modul
Aus

Code: [Select]

$crop_h = $orig_h*($size/$orig_w);
wird dann z.b. ein

Code: [Select]

$crop_h = intval($orig_h*($size/$orig_w));
Gemeint ist in der Fehlermeldung diese Zeile 170

Code: [Select]

ImageCopyResampled($result, $image, 0, 0, $x, $y, $size[0], $size[1], $width, $height);
Bedeutet, jede hier verwendete Fließkommazahl muß vor der Weiterverwendung in eine Ganzzahl konvertiert werden. WebsiteBaker verwendet diese ganze Bildberechnung z.b. in der Mediaverwaltung oder beim Captcha und indirekt auch beim Gruppenbild im News-Modul, die aber wieder über die globale Funktion make_thumb() arbeitet.
Die hier aufgezeigte Methode mit intval() ist nur eine Möglichkeit, die Werte ließen sich auch mit ceil() auf - oder mit round() abrunden, was u.U. genauer ist.

Eigentlich sollte PHP 9 zum Ende des Jahres erscheinen, ich finde aber aktuell keine neuen Infos darüber. Das Web ist jetzt schon voll von Anfragen ähnlicher Natur und ich denke, da müssen viele Modulautoren, auch und vorallem außerhalb von WB, noch viel Arbeit leisten. Im Falle des Minisliders wäre es halt so, das der Upload von Bildern nicht mehr funktioniert.
Der Slide könnte aber noch funktionieren, wenn man die entsprechenden Order unter /media manuell befüllt.

[masju]

The lax handling of variable types has always been a strength (or weakness) of PHP. Some will welcome the fact that the reins are now being tightened a little, for others it involves a lot of reprogramming work. And whether the code becomes more readable with lots of intval calls is something I'll leave open
I searched the module code for the ImageCopyResampled function and found nothing until I found out that it is a standard PHP function .
https://www.php.net/manual/en/function.imagecopyresampled.php
I changed line 170 in /modules/minislides/functions.php to

Code: [Select]

ImageCopyResampled($result, $image, 0, 0, intval($x), intval($y), intval($size[0]), intval($size[1]), intval($width), intval($height));and lo and behold: everything is OK!
Thanks for your help!

[Deutsch]

Der laxe Umgang mit Variablentypen war ja schon immer eine Stärke (oder auch Schwäche) von PHP. Manche werden es begrüßen, dass hier nun die Zügel ein wenig angezogen werden, für andere ist damit viel Umprogrammierungsar beit verbunden. Und ober der Code mit vielen intval-Aufrufen lesbarer wird, lasse ich mal offen
Ich habe den Modul-Code durchsucht nach der Funktion ImageCopyResampled und nichts gefunden, bis ich herausfand, dass das eine Standard-PHP-Funktion ist .
https://www.php.net/manual/en/function.imagecopyresampled.php
Ich habe Zeile 170 in /modules/minislides/functions.php geändert in

Code: [Select]

ImageCopyResampled($result, $image, 0, 0, intval($x), intval($y), intval($size[0]), intval($size[1]), intval($width), intval($height));und sieheda: Alles okay!
Danke für Deine Hilfe!

[hgs]

Have you also informed Ruud?


German
Hast du auch Ruud informiert?

[masju]

Ja, er hat noch nicht geantwortet. Ich schicke ihm auch noch den Fix-Vorschlag.

[sternchen8875]

And whether the code becomes more readable with lots of intval calls is something I'll leave open

It would be, if you declare the type where it is calculated, see example

Code: [Select]

$crop_h = intval($orig_h*($size/$orig_w));
In the function ImageCopyResampled() in this case only 3 of the values are floating point numbers, the rest are integers without decimal places, in exactly this case (functions.php, Z 170) the height is calculated, i.e. $y, $size[1] and $height. However, you can also calculate the width or nothing at all if you specify fixed values.
Specifying the type directly where it is declared improves readability and comprehension.

In the end, however, every programmer has their own style and preferred methods

[Deutsch]

Und ober der Code mit vielen intval-Aufrufen lesbarer wird, lasse ich mal offen

Das wäre er, wenn man den Typ da deklariert, wo er berechnet wird, siehe Beispiel

Code: [Select]

$crop_h = intval($orig_h*($size/$orig_w));
In der Funktion ImageCopyResampled() sind in diesem Fall nur 3 der Werte Fließkommazahlen, der Rest sind Ganzzahlen ohne Nachkommastellen, in genau diesem Fall (functions.php, Z 170) wird jeweils die Höhe berechnet, d.h. $y, $size[1] und $height. Allerdings kann man auch die Breite berechnen oder auch garnichts, wenn man fixe Werte vorgibt.
Die direkte Angabe des Typs da, wo er deklariert wird, verbessert die Lesbarkeit und das Verständnis. 

Am Ende hat aber jeder Programmierer seinen Stil und seine bevorzugten Methoden