That being the case, I wouldn’t expect it to get fixed any time soon. If you are storing whether threads are read/unread in a database that is server-side and not based on cookies - using the “database thread marking limit” means you have also set the thread/forum read marking type to database instead of cookie based. At least that’s what I can gather from the manual.
If it is a problem on the server side I can only guess as to the cause. For the future IT support should it ever materialize, I can consistently reproduce the problem by logging out, viewing the main page, and logging back in. If I close the browser (which I have set to discard all cookies) or manually delete all cookies, then navigate directly to the subscriptions list/User CP (https://boards.straightdope.com/sdmb/usercp.php) and log in there, the unread posts are preserved.
ETA: I think you meant “custom”, not “cracked”. As far as I know, “cracked” software refers to software that has been stripped of copyright or licensing protections, as if you were literally cracking open a padlock.
In the earlier days of vB even they referred to it as “cracks.” These were generally user written plugins and scripts and vB had them in a forum and it was “use at your own risk.” They were for functions vB did not offer in their standard package at that time.
Some of them may have been incorporated in future versions of vBulletin but since ours is approximately circa 2009, we do not have the benefit of whatever may have come after.
Over the years we added several of these options to the site – I’ve forgotten exactly which ones – and there was a software project a few years back where the program was extensively worked over by an outside team.
What I mean by “cracked” is that it’s not a vBulletin approved 100% authorized situation here. If that description of the situation is inaccurate, I apologize, but like I said, this goes way back.
Was this bug corrected in later versions? One would hope so. Perhaps sometime we will get to find out. In the meantime, all we can do is commiserate. I do wish I had more to offer you.
We are in Google’s good books in terms of compliance to what they consider proper for a website and have been for a while now. Ads are only one of the deciding factors in the algorithm, though i do suspect it’s weighed towards more punitive action to sites that are just click bait, as this site is not.
Adding the “https” probably did us more good than anything else lately.
That’s not the case with me. I never browse before logging in, just pull up the page and log in. Still happens fairly often, but I don’t bother to report it much anymore.