Some of you may remember the recent PHP v8 upgrade fiasco failure indecent incident. Well.... we're back at it again, folks! Except this time we're jumping 2 minor versions future forward.

I believe I fixed the new account (n00b account) bug that crashed 8.0 on my local. There's been a few things that broke (like video of the day posting to twitter and badge pages loading), but they've been easy to fix; just upgrading the code to modern practices.

Earlier this month I started fixing a lot of silent warnings that I've been ignoring since I started building the site. My best guess is that these warnings were many and were also being logged to disk causing the site to load slower than necessary. Things seemed to be going faster but then those slowdowns started again. I've opted out of using FastCGI, using normal-sans-fast CGI instead which is meant to handle longer threads better or sumptin'?!?!?

TL;DL :: you see something you say something here

it loaded fast now - but yesterday was problematic when i was hosting a battle, those 503 error issues (i thought was because a kind of christmas traffic excess on shared narrow bandwidth, or even weather issues, not php updating and testing )

I noticed the site seems a bit groovier. And there is now light gray hover-highlighting for certain elements that didn't have it before, but this is overshadowed by the grooviness.

I've noticed that playing the advent playlist always seems to suspicously coincide w/ a bunch of Internal Server errors occuring

submissions are borked. screenshot from viraxor

screenshot of major submission by dami

alright we did some speed fixings around an XHB

there are def a bunch of warnings still being logged on the server and i'll try to nail more over the next few days

and some walks with Nitro meanwhile! ;) - thanks, @puke7 !

mp3 donload is borked on specific circumstances. returning php error in the form of a mp3. circumstances unclear but it's known to be an issue on private tabs and the duckduckgo mobile app.
screenshot here

screenshot of playback attempt

php error:
stristr(): Passing null to parameter #1 ($haystack) of type string is deprecated<p>line #<b> &nbsp; &nbsp FECES_ERROR_HANDLER('8192','stristr(): Passing null to parameter #1 ($haystack) of type string is deprecated','/home/puke7/botb/whats/player/player.php','17');
<br/></b></p>
<p>line #<b>17 &nbsp; &nbsp stristr('','https://battleofthebits.com/');
<br/></b>/home/puke7/botb/whats/player/player.php</p>
<p>line #<b>172 &nbsp; &nbsp playerCheckRef();
<br/></b>/home/puke7/botb/whats/player/player.php</p>
<p>line #<b>252 &nbsp; &nbsp require('/home/puke7/botb/whats/player/player.php');
<br/></b>/home/puke7/botb/whats/boot.php</p>
<p>line #<b>28 &nbsp; &nbsp require_once('/home/puke7/botb/whats/boot.php');
<br/></b>/home/puke7/botb/_FECES.php</p>

interesting, i wasn't able to replicate that on desktop (win10 firefox) or mobile (ios firefox), even with the OPM entry you showed in the screenshot

alright -- some more stuff went wrong and was fixed

seems like posting screen shots of error stack traces in #botb_dev on the discord server is a speedier way to communicate newly found errors

i thought i'd explain what most of these are:
Older versions of php would automatically create an undefined variable and assign it a value of null when referenced. Older versions of php would also use context to assign a "falsey" value when the variable is used in code. So if the code is doing math the null variable would return a zero; a null conditional would return false; a null string would return an empty string. This was highly convenient for the past 16 years. If a field wasn't set in the database it would be a null value and cascade through the system being defined with a "falsey" value when needed. Afaict these "errors" were only considered "notices" (non-logged errors) until php v7 when they were escalated to "warnings" (logged errors). And this is what was actually causing the site to crash on occasion: waiting for access to the log file because so many other requests were so backed up trying to write 100s and 100s of warnings to a single log file for every single page load. Fast forward to php v8 and now sending a null value to any builtin php functions that requires a different type causes a full-on error and crashes the site with the error stack trace on screen. The fix is simply to create and assign variables with their corresponding "falsey" value. Then, if the system doesn't meet necessary requirements to populate the value, php is still satisfied.

So, while this is a total pain in the arse, fixing all this stuff up is actually resulting in the site running as smoothly as it's meant to. I doubt I could have thought of and tested every event possible on my localhost, so thank you all for being so patient and helpful throughout these growing pains. It's all going to be worth it! Maybe if it actually stops routinely crashing I'll start thinking BotB is worth promoting again! :thonk:

i will agree with you that i feel like posting these on #botb-dev is more efficient than going all the way here and posting about it, linking screenshots, etc. (ironically all the screenshots here were from discord lol) i'll still post on this thread what bugs arose for me while using the site at this time mainly for the sake of posterity, as well as for the users who don't frequent the discord as much. (irc diehards and nonchatters) thank you puke for your continued leadership and bugfixing prowess at this time :]/

borked badges, for both profiles and barracks update: they're working now? apparently??? they were showing the screenshotted error for me and defmec but now they work
1

2

php 8.2 is weird

they don't work if you copy/paste the link into a new tab, but they work if you click on "badges" from the home page

hhuh, so it's basically the same as what was happening with the player in certain circumstances o ,o

there def was some potentially breaking code in there
went ahead and fixed it

i found a curious bug: (steps below)
1- when we enter https://battleofthebits.com in the url bar, the website loads fine
2- when we click on puke7's profile, https://battleofthebits.com/barracks/Profile/puke7/ , it opens fine as well
3- when we replace "puke7" with "Baron+Knoxburry" in the url bar, it opens fine as well
4- when we click on the badges button, https://battleofthebits.com/barracks/Profile/Baron+Knoxburry/Badges opens fine as well
5- but when we now replace "Baron+Knoxburry" with "puke7" in the url bar and enter, what we see is:
"
strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated

line # FECES_ERROR_HANDLER('8192','strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated','/home/puke7/botb/whats/ajax/ajax_class.php(96) : eval()'d code','3');

line #3 strpos('','Profile');
/home/puke7/botb/whats/ajax/ajax_class.php(96) : eval()'d code

line #96 eval();
/home/puke7/botb/whats/ajax/ajax_class.php

line #200 ajax::inHouse('/botbr/AjaxBadges/1/');
/home/puke7/botb/whats/barracks/barracks.php

line #30 require_once('/home/puke7/botb/whats/barracks/barracks.php');
/home/puke7/botb/_FECES.php
"

oh damn the non-ajax entry point is a fail!
i can fix this soon, but about to drive across the country rn

edit---- fixed