WebsiteBaker Community Forum
WebsiteBaker Support (2.13.x) => Modules => Topic started by: Ruud on February 10, 2022, 04:14:01 PM
-
Hello community,
I just released v 1.0 of my new MiniSlides module.
It is meant to be a replacement for the old MiniSlider module.
Download: https://dev4me.com/modules-snippets/opensource/minislides/
Demo's: https://dev4me.com/modules-snippets/opensource/minislides/demo/
Have fun with it.
-
Thanks for sharing
Short test with WB 2.13.0 php 7.4
Install = ok
setting fronthem = ok
Upload images = ok
FE test = ok
Delete images one by one = ok
ErrorLog = empty; Setting to development
php 8.0 = ok for all tests
-
Works (Y)
Again a super module by Ruud. Thanks man!
For the left/right arrows i had to add data: to the CSP default-src.
This module is now also in our Addons Repo: miniSlides
(https://addon.WebsiteBaker.org/pages/en/browse-add-ons.php?id=06041A95)Thanks to Harald (hgs)
-
If you choose Create square thumbnails: "none"
a error occours in "Current Images" (after upload and Refresh images);
"Cropping /var/www/.../media/slides/1252/thumbs/bild1.jpg > none
There was an uncatched exception
Division by zero
in line (124) of (/modules/minislides/functions.php):"
-
If you choose Create square thumbnails: "none"
a error occours in "Current Images" (after upload and Refresh images);
Thanks for reporting:
The problem is fixed in v1.0.1. (https://dev4me.com/modules-snippets/opensource/minislides/)
-
Fixed (Y) :)
-
current version also in our Addons Repo: miniSlides (https://addon.WebsiteBaker.org/pages/en/browse-add-ons.php?id=06041A95)
-
Thank you SO much again Ruud! It is really great that you keep creating modules to make WB even better every time. I love the cover flow :-) Business is slow right now, but the next project with your modules will mean another donation for sure!
-
Hi Ruud,
and thank you very much for this module.
However, when I try to add a MiniSlides-section, I get this error message:
"There was an uncatched exception
Class 'Template' not found
in line (30) of (/modules/minislides/modify.php)"
Any idea, what's causing this?
I'm running WebsiteBaker 2.13.2.
Thanks in advance and best regards,
VSG
-
This is a WB 2.13 thing.
Add to modify.php as first line (below the comment area):
use vendor\phplib\Template;
-
This is a WB 2.13 thing.
Add to modify.php as first line (below the comment area):
use vendor\phplib\Template;
Perfect, thanks!
-
Hi Ruud,
now that I've been able to test the module, I have to say I love the simplicity and and the design!
But I don't understand how captions are supposed to work. The Text I put in the "Description"-field is displayed above the slider (all lines at once). Is that what it is supposed to do?
With MiniSlider it was possible to add a caption for each image (one line for each image).
Am I doing something wrong or is such a feature possible or planned for the future?
Thanks for your effort and best regards,
VSG
-
The title and description are used as text/content output above the slider..
The captions are set in the "Current Images".
Click the green pencil icon to set the captions.
(https://dev4me.com/media/minigal2/364/current.png)
Use CSS (frontend.css) to position/style the captions as you like.
-
Updated the module (v1.0.3) with a fix for the Template problems. Working on WB2.13 but also on previous versions.
https://dev4me.com/modules-snippets/opensource/minislides/
-
This is a WB 2.13 thing.
Add to modify.php as first line (below the comment area):
use vendor\phplib\Template;
The better solution, and thus also compatible with the fork, is what Ruud might be willing to implement like this
Insert the following line before the new template
if (!class_exists('Template')){require WB_PATH.'/include/phplib/template.inc';}
This should also work for other 3 part modules if the error occurs.
our template.inc is quasi an adaptor to our php lib class
And sorry for the late information about the changes in WB 2.13.2
Translated with www.DeepL.com/Translator (http://www.DeepL.com/Translator) (free version)
-
The title and description are used as text/content output above the slider..
The captions are set in the "Current Images".
Click the green pencil icon to set the captions.
(https://dev4me.com/media/minigal2/364/current.png)
Use CSS (frontend.css) to position/style the captions as you like.
An error has popped up when editing the captions on images. Here's what I did:
Clicked on the green pencil to add a caption, and clicked on Save' in the pop-up.
Decided now to remove the captions in the same way, but when clicking 'Save', the captions remain.
I can edit the captions and the new description saves.
Deleting the caption completely (leaving an empty caption field) is not working.
Regards,
Seanie.
-
Confirmed.
Try to replace your text with a hyphen and save that. For me the caption was gone.
-
Confirmed.
Try to replace your text with a hyphen and save that. For me the caption was gone.
The hyphen worked! I tried fullstop '.' and other symbols, but not the hyphen. The hyphen works.
Many thanks!
Seanie.
-
Fun fact, the hyphen was my first try. ;D
-
Sorry about not telling this anywhere.
I now added this as a tip on my website :-)
-
Thank you Ruud
Is a fix planned?
-
Is a fix planned?
No, not really.
If I remember correctly the (sweetalert) popup script also sends an empty input value when the cancel is clicked. So in effect cancel would clear the caption.
This workaround at least allows to clear it only when you want to do that.
-
Hi! I have an issue with that module. When I click on the green pencil, the console says:
Uncaught TypeError: $() is null
textarea https://aaaaaaa.com/modules/minislides/backend.js:2060
textarea https://aaaaaaa.com/modules/minislides/backend.js:2060
Et https://aaaaaaa.com/modules/minislides/backend.js:2060
qt https://aaaaaaa.com/modules/minislides/backend.js:2060
Rt https://aaaaaaa.com/modules/minislides/backend.js:2060
_main https://aaaaaaa.com/modules/minislides/backend.js:2060
r https://aaaaaaa.com/modules/minislides/backend.js:2060
i https://aaaaaaa.com/modules/minislides/backend.js:2060
fire https://aaaaaaa.com/modules/minislides/backend.js:2060
doPrompt https://aaaaaaa.com/admin/pages/modify.php?page_id=5:559
init198 https://aaaaaaa.com/admin/pages/modify.php?page_id=5:511
jQuery 2
dispatch
handle
A popup keeps blinking, and I can't edit the foto.
Could you help, please?
masju
-
I just found out, that this problem only appears in firefox.
-
cannot confirm this - do you use a older jquery-version?
-
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
-
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.
-
do you have some more sections on this special page?
-
do you have some more sections on this special page?
Yes, two WYSIWYG and one MiniSlides-Module.
-
I just found another issue, same module, PHP 8.2, when I upload pictures:
Error-Log:
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""
-
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.
-
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.
-
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
$crop_h = $orig_h*($size/$orig_w);
change to
$crop_h = intval($orig_h*($size/$orig_w));
only a example
The error message in your post refers to this line 170
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
$crop_h = $orig_h*($size/$orig_w);
wird dann z.b. ein
$crop_h = intval($orig_h*($size/$orig_w));
Gemeint ist in der Fehlermeldung diese Zeile 170
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.
-
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 :roll:.
https://www.php.net/manual/en/function.imagecopyresampled.php
I changed line 170 in /modules/minislides/functions.php to
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 :roll:.
https://www.php.net/manual/en/function.imagecopyresampled.php
Ich habe Zeile 170 in /modules/minislides/functions.php geändert in
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!
-
Have you also informed Ruud?
German
Hast du auch Ruud informiert?
-
Ja, er hat noch nicht geantwortet. Ich schicke ihm auch noch den Fix-Vorschlag.
-
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
$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. :wink:
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
$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. :wink:
Am Ende hat aber jeder Programmierer seinen Stil und seine bevorzugten Methoden