UBB.threads PHP Forum Software Community Forums Active Threads

Thanks, Rueben. I've already done that. But I don't understand why the purge isn't working. I used the exact same mysql query to delete the files manually. Maybe I'll try to take a closer look when I get time.

Thanks Gizmo & Isaac. That was weird, but once i understood what to look for, I was able to disable it in the Control Panel. It was our Custom Island 11, and this was the contents. (Screenshot attached) No idea how the name Custom Isalnd 11 got translated into Portal Box 39.

I opened a support ticket. Brooks looked at the site and said it was working as expected. So, I dumped all the Stovebolt data in Safari, and the dashboard worked again. Made one change in the dashboard and bam, the error was back. So, I dumped all the data again. Then I disabled debugging. We'll see if that was what was causing the issue.

we do test on all platforms that we have available to us. but when a company is constantly moving away from even the most basic of standards, and being hostile about it - see apple's take on usb-c, imessage, not displaying digital seconds (time) on mobile devices "because people dont care about seconds", not including a calculator on the ipad "because it lookss bad", and constantl intentional incompatibility with other software - there really is nothing that any amount of testing across platforms can to do keep up with them, and their anticompetitive practices.

Gizmo, you made this statement several times. Yet, the problem with my forum was the UBBThreads config file, not the web server. I don't know what was wrong with it, but replacing it fixed the problem. (Of course, then I had to change all the settings back to what we had before.)

Once I got the forum up and running, I discovered that I couldn't make global announcements or make posts sticky. That TOO turned out to be a problem with your code. (Rueben pointed out the fix to me, which I implemented and which fixed the problem.)

Now, I've discovered another problem with the text editors. (See my post about the WYSIWYG editors throwing errors.

I'm very happy with the new version and with the compatibility with PHP 8.3, but frankly, your "help" was no help at all. Not once did you (or even your support team) suggest enabling debugging, which would have saved me hours and hours of scratching my head because there were no errors in the logs. I had to discover that on my own.

I realize that you guys work hard and you have many thousands of lines of code to oversee, but the least you can do is be patient and understanding when a longtime user of your product is having issues. (We've been customers since March 19, 2005 - almost 20 years.) And for God's sake, the FIRST thing you should suggest is to enable debugging. If the forum is not working at all, you can simply edit the line in the config file to display the errors. That would have saved me two days of hair-pulling.

Again, I want to thank you for the update. I'm very pleased with it.

This is what I'd like to get a resolution to.

If you are put on moderation and make a post, great. However you shouldn't be allowed access to areas you were removed from before I approve the moderated post.

That's the issue.

Thank Toner(Bill) for finding it
I am still waiting to upgrade after the dust settles

Thank you

Thanks a lot guys. The issue resolved itself overnight. Weird.

exactly as Gizmo wrote. expanding on that -
its not so much that the cookie itself was corrupt. but more so that the data inside the cookie was corrupt. such as storing some dashboard data in the cookie file so it does not need to be regenerated at every visit. total users, new users, users last week, etc. the corruption may a ",,,,,," instead of the intended "0,0,0,0" to the cookie file. NULL or EMPTY variables instead of the count of "0"

thank you, that typo was first mentioned here, along with a quick fix
https://www.ubbcentral.com/forums/u...grade-to-php-8-1-breaks-forum#Post266227

Thanks Isaac. I'll have to give this some thought.

both I think it was around three hours to download two days upgrading UBB then three days converting to smf then it took longer to upload since I was uploading a full complete database .

I note that it took several attempts because of the duration ,the connection dropped out a few times during the upload.
Not sure if it was my isp or the host

Well, this is wonderful. We're back on 7.4.33 and the forum is working again, but now I have this error in the Control Panel.
I have set max_input_vars to 4096 in /etc/php.ini and /etc/php.ini.rpmnew.. I've restarted the server (several times). I've cleared the browser cache (several times). I even edited the binary files lipbphp7.so and libphp7-zts.so. Everything on the server is set to 4096. I even reverted to the saved php.ini file (/etc/php.ini.rpmsave), and restarted the server and cleared the cache again. Yet the error remains.

I finally got rid of the error by rebooting the server. Sheesh!

As the forum database gets bloated over the years with the size reaching several+ gigabytes (mainly thanks to the ubbt_POSTS table), could you introduce an "archive" feature that would allow the admin to move posts older than a chosen date into a separate table that is read-only?

That way the current, workable table would be smaller and easier to work with for greater server efficiency, whereas all older posts would be cordoned off in an archived posts table.

I've come across this when reading about features across various software and this is definitely something I would appreciate on my site.

To bring this back up, I don't know why adjusting

<title>{if $inputTitle}{$inputTitle|strip_tags}{/if}{if $powered} - {$powered}{else} - {$config.COMMUNITY_TITLE}{/if}</title>
to
<title>{if $inputTitle}{$inputTitle|strip_tags}{/if}{if $powered} - {$powered}{else} - {$forumTitle|strip_tags}{/if}</title>
in the header.tpl template doesn't cause our HTML <title> to show the topic (dash) forum title.

I'm guessing the string $forumTitle isn't available to the template when it runs. Is there another string that would accomplish the same thing?

Definitely a bug, thanks for the quick fix, there will be an 8.0.1 before too long with some changes including this.

Upgrade to 8.0.0 was a dream for me - forum came right back up. Going to PHP 8.2 is a different issue per my other post.

Unfortunately the vendor takes "User to User" support forums very literally and doesn't monitor these forums very often, the only official outlet for vendor support is the support desk.

PHP8 support was hinging on the ever evolving landscape of PHP8, once we'd get closer to a release there would end up being some showstoppers that had to be addressed, then we had to wait on the installer to be completed (and in the process an old PHP4 function was rejiggered and a speed increase was found with newer code).

UBB.threads 8.0.0 has been released and is now available to download in the Member Area.
Version 8.0.0 brings PHP 8 support to your forums. It has been tested to be compatible with PHP 7.2 - PHP 8.3. This release also contains added features, library and asset updates, maintenance items, and fixes.

Primary Changes In This Release

• PHP 8 support. UBB.threads now supports php 7.2 - 8.3.
• All libraries and assets updated.
• Reformatted and standardized all code.
• Cleanup of UBB scripts, templates, and CSS files.
• More bug squashing and layout updates.

Version Discussion and Changelog

Got it. I was getting server error because I had some duplicate lines.

Thx for checking me.

It's just seems weird that it only blocks those ads and not the others