Long live miniBB! It's been about 2 years since the latest stable release came to this world, and now I'm happy to announce, that miniBB project is still being supported with new featured and updates. This time, the major changes include:

— Migration to SVG icons (incl. miniBB logo) — in the ascetic graphic terms, miniBB will go scalable, and at this stage I've worked out the most common parts of icons, which are included in default miniBB layout and most of add-ons. This affect the new BB-buttons (now they are possible to customize via CSS, that means you could change their background color, borders and size) and forum-wise icons. Some of updated add-ons will also include the new vector-base icons, the news release about it will come soon.

— «Dark mode» implementation, and introduction to the set of CSS variables — for those who prefers the dark mode in their browser, after switching it on the miniBB forum should immediately adopt to it with no reload; this also should work in the Mobile layout. CSS variables suppose more easier implementation of customized CSS, and are planned for the miniBB dynamic skin maker kept for further development.

— Functionality: Login form on top of each page — a long-awaited and most requested feature up to date, which allows to login from any section of the forum, and staying in this section after being logged in. Various login displaying options are implemented — locate the new setting named $signInEachPage, which is descibed in the updated miniBB Manual.

— Functionality: Important update of Watched topics — if an author's post from this topic (A) moved to another topic (B), then (B) could be optionally added to the Watch list of this member.

— Canonical URLs implementation — trying to be even more Google-SEO oriented, miniBB core version by default will include canonical URLs for indexed pages. This feature will be also gradually added to some add-ons at later time.

— Various minor bugfixes and improvements also provided in this release.

Find out the new miniBB package and get it for free in Downloads, make sure you backup your forum's files and database before proceeding to upgrade, and follow all files to replace or modify in the Updates history, scrolling to the bottom of the file (it's headed Changes comparision: 3.6.1 — 3.7 — zipped version is available, too).

Welcome to test the updated version via the Compiler or miniBB demo, which have been updated, too.

Feel free to post any comments or found bugs in this thread.

Have great holidays everyone! 😎

Congrats on the new release, Paul; and thank you for continuing to support the software after all these years!

With Christmas coming up, best wishes and many thanks,
marsbar

marsbar
Thank you very much!

Have big luck and power in new year everyone, as me :)

Hi, Paul.

Happy New Year!

Is miniBB is compatible with PHP 8.5? Just thought I'd double check before upgrading PHP.

With thanks,
marsbar

marsbar
Happy New Year to you as well, thanks!

I found a couple of suspicious deprecations in PHP 8.5.0:
I need to check them more deeply before I could answer your question precisely. Hope to do it in a couple of days. While the first could affect only some add-ons which use image generation, like Captcha or File Attachments, the second may affect most of miniBB core and add-ons. At the moment, I'm just not sure what it means.

marsbar
Happy New Year to you as well, thanks!

I found a couple of critical deprecations in PHP 8.5.0 and so, later versions:
I have checked miniBB add-ons and the core regarding these issues, and my doubts were confirmed. Current downloadable packages are not compatible with PHP 8.5.x, but they could be easily fixed these ways:

• Add-ons like Captcha, File Upload, File Bank and Photo Album — if you search in their .php files for imagedestroy, then all code lines containing this function just could be removed.
• There are lot more scripts having (integer) cast names in the code, both add-ons and the core (it's a way to convert the value of the variable to the integer and that way to secure up the processes), so if you search by that and replace it to (int) then you will make the scripts compatible with PHP 8.5.x. That's more serious issue, and it could screw up a lot of the things.

I have the next post-release of miniBB and add-ons in development regarding SVG graphics, and will at once make this stuff compatible with PHP 8.5.x like described above (with additional issues I already worked on).

I hope it all could come in about two weeks or even earlier.

Thanks for bringing this issue up!

I read something about it — so is it good to just completely remove all references to this imagedestroy() function OR maybe it should null the value instead, eg.

OLD

NEW

?

That's a good remark.

Obviously this function has no sense to keep in scripts, which use just one image to generate, and will close shortly after that. No matter if memory resource is cleaned up or not, it will be cleaned as the script ends, in a piece of second after that. So, in add-ons like Captcha or File Bank removing the code line(s) with the imagedestroy() function is absolutely strong enough.

However in the scripts like File Upload and Photo Album the script deals with loops when processing multiple images, and imagedestroy() is used as a part of another function (resp., createThumbnail or createPicsThumbnail) which could be called multiple times per script execution. But I'm pretty sure the image resource used within one function is not kept in global scope. As soon as the script refers to this function to generate a new image, this resource will be nulled/replaced by a new reference. So, in this case — but it's the only miniBB case — there would be enough to remove these code line(s), too.

It should be mentioned that imagedestroy() is related to the GD library only, and this library uses objects instead of resources since 8.0.0, that's why this function has no effect — objects could not be explicitly closed. The File Upload add-on of miniBB could be configured to use Imagick library — in this case, codes like

should be kept.

If you have scripts which generate multiple images in a loop but not within a standalone function, yet in a straight PHP loop/cycle, then nulling the resource should be a must, I suppose. But to clear the memory efficiently, you could set this instead of just nulling the resource: