Previous Thread
Next Thread
Print Thread
Hop To
Joined: Dec 2018
Posts: 10
Likes: 1
K
Stranger
Stranger
K Offline
Joined: Dec 2018
Posts: 10
Likes: 1
I'll start right off by saying I know I broke something (with the help of BlueHost tech support), I'm thinking it's a simple fix - after all, it was easy to break smile But I'm at a loss as to what to fix.

The problem:
When a user goes into a particular forum, any threads with new posts are highlighted correctly. However, when a user goes into a thread, it doesn't take them to the newest unread post. Instead, it takes them to the first post in the thread, even if they've read that post already. Next, when the user goes back to that particular forum, any other threads with unread posts are no longer highlighted.

The history:
We started getting the "max_input_vars too low" error prior to this problem. So I contacted BlueHost support, and they walked me through the simple task of using "MultiPHP INI Editor" to update "max_input_vars" from 1000 to 3000. The "too low" error went away.

Later, I noticed none of the attachments to any posts would appear or could be downloaded. I contacted BlueHost again, and their solution was to rename the .HTACCESS file to .HTACCESS1 to effectively disable it. That worked, but the "too low" error message was back. And, in looking through the HTACCESS1 file, I noticed a "max_input_time" variable in addition to "max_input_vars" which surprised me, since I didn't intentionally change the value from the default of 60 to 600. So I used "MultiPHP INI Editor" again, entered 3000 for max_input_vars, 60 for max_input_time, and saved the results. Now the attachments were working again, and the "too low" error message was gone.

But, I now have the new problem with unread post tracking. I suspect the PHP.INI and .HTACCESS files were changed to 'standard/generic' files and are missing some key entry (or entries). Unfortunately, I didn't save a copy of either one prior to making these changes.

The Environment
UBBThreads version 7.7.3, no modifications from stock install.
PHP 5.6.40
Hosted by BlueHost

Any suggestions on how to fix this?

Last edited by KirkW; 06/16/2020 12:34 AM.
Joined: Dec 2003
Posts: 6,560
Likes: 78
Joined: Dec 2003
Posts: 6,560
Likes: 78
This might be part of a long standing bug.
For example in the forum summary page there is a indicator image that something is unread.
I open that forum.
Then I see several topics highlighted that they are unread.
without opening a Topic I go directly back to the forum summary and the indicator is gone.
But I open the forum again and all the topics show they are still unread.

Then again in the forum summary(different Forum) I see the unread image.
I open the forum and I don't see any unread topics I back out to the summary and the indicator is gone.

I believe this has been the behavior for a long long time not that it is correct but nobody has brought it up before.

Also in both cases you need to refresh the browser to see the unread indicator has been deleted.

Also on this board it has the same behavior.

Maybe you just noticed it because you were looking for something.wrong?

As far as going to the wrong post I am not sure.
I know in v7.7.4 there is a image that appears in the timestamp that shows new if unread.

Last edited by Ruben; 06/16/2020 5:01 PM. Reason: Added Comment

Blue Man Group
There is no such thing as stupid questions. Just stupid answers
Joined: Dec 2003
Posts: 6,560
Likes: 78
Joined: Dec 2003
Posts: 6,560
Likes: 78
Oh and thanks for the Bluehost info on renaming the htaccess file.
I have a client that it happened to at bluehost and we argued who renamed the file to htaccess1.


Blue Man Group
There is no such thing as stupid questions. Just stupid answers
Joined: Apr 2004
Posts: 1,945
Likes: 145
UBB.threads Developer
UBB.threads Developer
Joined: Apr 2004
Posts: 1,945
Likes: 145
NEW POST and NEW IN FORUM indicators are controlled by timestamps within the FORUM_LAST_VISIT database.

If you recently upgraded from a version of UBB.threads 7.5.9 and older, to version 7.6.0 and newer, then you are probably dealing with the change made in how we deal with times.

Version 7.5.9 and older, UBB.threads used TIME OFFSETS.
Starting with version 7.6.0, UBB.threads uses real real world TIME ZONES.

Because of this change, your entire forum may experience a one-time 24 hour lag in new post indicators while the database catches up to to the time stored within your profile.

NOTE: If your website is telling the browser to cache everything, and your browser is using default settings, you may experience multiple inconsistent results with the new post indicators.

Look for "Header set" in your .htaccess file for information on that setting.

A Cloudflair CDN May also affect stale cached web pages to be displayed. Are you using "BlueHost Cloud Hosting" -- which is basically Cloudflair CDN. Have you customized its Cloudflair settings?

Needless to be said, browser caching and ISP caching could also be part of the issue, but is unlikely in your case, since you mentioned this is a recent issue you just started having


you can request that browsers NOT cache your forum data by inserting the following code to /forums/.htaccess
Code
<IfModule mod_headers.c>
  Header set Cache-Control "no-cache, no-store, must-revalidate"
  Header set Pragma "no-cache"
  Header set Expires 0
</IfModule>


Current developer of UBB.threads PHP Forum Software
Current Release: UBBT 7.7.5 // Preview: UBBT 8.0.0
isaac @ id242.com // my forum @ CelicaHobby.com
Joined: Dec 2018
Posts: 10
Likes: 1
K
Stranger
Stranger
K Offline
Joined: Dec 2018
Posts: 10
Likes: 1
Although we did upgrade from an older forum, that was a year ago and this behavior started last week, coincident with the changes to PHP.INI and/or .HTACCESS. We also have another forum running version 7.7.1 and hosted by GoDaddy. It has not been worked on and it still behaves as we expected. I do recall noticing the change from TIME OFFSETS to TIME ZONES when we upgraded. But that shortly sorted itself out as you described. In short, this current problem is not something we just noticed.

I checked the current .HTACCESS file and it doesn't have a "Header Set" entry (or even the word "header" in it anywhere). Could that be the problem?

This BlueHost account is one we inherited from another group. It was set up over ten years ago, then handed over to another admin who touched nothing other than adding or deleting members. So if there are any changes to CloudFair or BlueHost I'm not aware of them and predate me.

As for myself - I started off as a machine-level programmer back in the 1980s, and most of my experience since then has been in the Windows world. So I'm familiar with the general concepts but I lack specific experience with PHP, MySQL and web-hosting and so I'm trying to tread gingerly.

Thanks for your help so far!

Last edited by KirkW; 06/16/2020 8:04 PM.
1 member likes this: isaac
Joined: Dec 2018
Posts: 10
Likes: 1
K
Stranger
Stranger
K Offline
Joined: Dec 2018
Posts: 10
Likes: 1
Before adding the "Header Set" code to HTACCESS, I decided to simulate the effect by doing a force-refresh with my browser. At first glance it made no difference, and possibly worse. In my random sample of one, doing a Ctrl-Refresh in Chrome caused the Unread flags for the threads to disappear without first reading them. I'm going to experiment more tomorrow as new posts appear.

Joined: Dec 2018
Posts: 10
Likes: 1
K
Stranger
Stranger
K Offline
Joined: Dec 2018
Posts: 10
Likes: 1
Did some further testing. If I go into a sub-forum I'll see any threads with unread posts highlighted and flagged. If I do a force-refresh of the browser, those flags go away, even though I didn't go into any thread and read any of the posts.

By comparison, I can go to our other working forum, perform the same test, and the threads remain highlighted and flagged (as expected). I have to go into each thread to read the posts before that thread is un-flagged. If I go back to the forum, only that thread is un-flagged. Any other threads with unread posts still remain flagged as expected. This is the way the first forum used to be until the recent changes.

So, the act of refreshing the browser while viewing the list of threads seems to falsely trigger the software into thinking all of the threads have been read.

What's baffling to me is what in PHP.INI or HTACESS was cause (or prevent) this behavior. Are there default settings that UBBThreads requires to be present in either of those files?

Last edited by KirkW; 06/17/2020 8:50 AM.
Joined: Apr 2004
Posts: 1,945
Likes: 145
UBB.threads Developer
UBB.threads Developer
Joined: Apr 2004
Posts: 1,945
Likes: 145
Originally Posted by KirkW
What's baffling to me is what in PHP.INI or HTACESS was cause (or prevent) this behavior. Are there default settings that UBBThreads requires to be present in either of those files?

Default php settings. nothing special. Works as expected on fresh install of apache and php 5.6 - php 7.4. Windows server or Linux server, does not matter.

NEW POST and NEW IN FORUM indicators are controlled by timestamps within the FORUM_LAST_VISIT database.

Confirm that the date and time on your computer is correct. You may also want to turn on debugging and confirm that your forum server time, forum timezones are as expected, by reviewing them in the forum footer debug summary.


Current developer of UBB.threads PHP Forum Software
Current Release: UBBT 7.7.5 // Preview: UBBT 8.0.0
isaac @ id242.com // my forum @ CelicaHobby.com
Joined: Dec 2018
Posts: 10
Likes: 1
K
Stranger
Stranger
K Offline
Joined: Dec 2018
Posts: 10
Likes: 1
The problem occurs across multiple browsers on multiple platforms across multiple time zones from multiple users. I have tested it myself on both a Mac and Windows PC running Safari, Chrome, and Firefox, so it's not a client-side issue.

And I don't think it's a time/date problem. When connecting to the forum it shows the correct unread posts since the user last checked in, so the forum is correctly calculating which posts have changed since the user's last session. If the time/date were wrong or mismatched, I would expect the wrong posts to be flagged as 'new'. That is not happening.

However, when the browser is refreshed, either by clicking on an unread post or by doing a force-refresh, then all of the new post flags disappear. If I had to guess, it would appear the FORUM_LAST_VISIT is being set to the current time as soon as the user browser refreshes, effectively zero-ing out all the NEW POST indicators.

Joined: Apr 2004
Posts: 1,945
Likes: 145
UBB.threads Developer
UBB.threads Developer
Joined: Apr 2004
Posts: 1,945
Likes: 145
FORUM_LAST_VISIT is the unix time stamp of each forum last visit. iirc, the posts are marked as visited based on the time freshness of that FORIM_LAST_VISIT date.

You could manually trigger a "mark all read" by following the said named link in the sites footer. Thay will mark all forums in all categories as being read and current.

Im not near a dev computer setup since two weeks ago, and will return next week when my business travels complete. I wish I could assist more now, but im out of "simple solution ideas" atm.

Last edited by isaac; 06/17/2020 11:12 PM. Reason: fixed words. thabks android.

Current developer of UBB.threads PHP Forum Software
Current Release: UBBT 7.7.5 // Preview: UBBT 8.0.0
isaac @ id242.com // my forum @ CelicaHobby.com
Joined: Dec 2003
Posts: 6,560
Likes: 78
Joined: Dec 2003
Posts: 6,560
Likes: 78
I thought about this a bit.
One possibility is your session files could be the issue. Not knowing what all Bluehost did.
Couple things to check.
One goto the ubb cp and check Permission Checks
Make sure all show ok. Pay attention to sessions.
Two ftp to your site.
Goto your designated sessions folder.
There should be a bunch of session files like
sess_upfjjpmohd3l4epj5kc84409j0
plus one file named
test.file
If the test.file file is missing just create it with your ftp program is is a empty file.
Then check/edit includes/include.inc.php
Make sure you have a valid path to your sessions folder.
It will not be a http path.
It will be like
SESSION_PATH' => '/home/blabla/public_html/sessions
or
SESSION_PATH' => '/home/blabla/public_html/forum/sessions
It all depends on where you installed UBB

Third in ubb cp run php info
look for all the values that start with sessions.
They will be in a group.
Make sure the local value has the correct path for your sessions as verified before.
Plus make sure you are running the correct php version. It will be at the top of the page.

Maybe a url to your forum might help to see the issue.

Last edited by Ruben; 06/23/2020 3:50 PM. Reason: Added Comment

Blue Man Group
There is no such thing as stupid questions. Just stupid answers
Joined: Dec 2018
Posts: 10
Likes: 1
K
Stranger
Stranger
K Offline
Joined: Dec 2018
Posts: 10
Likes: 1
I think you are on to something. The "Sessions" folder is present, with the files as you described. However, the last modification date for all of them is 06/13/20 at 5:19, the time I was working with BlueHost, and the last time the forum behaved as expected. So it appears something broke that day that is preventing the session files from being updated. So far as I know, then only thing we (BlueHost and me) changed where .HTACCESS and PHP.INI.

There was no "test.file" in the Sessions folder so I created it.

Where do I find the "includes.inc.php" file? I'm not seeing it in the "Includes" folder.

I checked the "Absolute PATH to Sessions Directory" in the UBB Control Panel and it still points to "/home/cessnaon/public_html/forum/sessions" (which is the correct location). And the "Permissions Check" comes up with "OK" for everything. And checking "PHP Info" shows the "session.save_path" set to "/home/cessnaon/public_html/forum/sessions"

Here's a link to the forum: https://www.cessna150152.com/forum/ubbthreads.php/forum_summary.html

Last edited by KirkW; 06/24/2020 12:05 PM.
Joined: Dec 2003
Posts: 6,560
Likes: 78
Joined: Dec 2003
Posts: 6,560
Likes: 78
I am sorry the file is named config.inc.php
Not includes.inc.php.
Typo on my part. eek

Last edited by Ruben; 06/24/2020 5:23 PM.

Blue Man Group
There is no such thing as stupid questions. Just stupid answers
Joined: Dec 2018
Posts: 10
Likes: 1
K
Stranger
Stranger
K Offline
Joined: Dec 2018
Posts: 10
Likes: 1
Ok, checked the config.inc.php file. The SESSION_PATH is correct and mirrors what's found in the UBB Control Panel "Paths & Database".

Joined: Dec 2018
Posts: 10
Likes: 1
K
Stranger
Stranger
K Offline
Joined: Dec 2018
Posts: 10
Likes: 1
And it looks like the problem is solved. Ruben was correct - the Sessions files were not being updated. The Control Panel had the correct folder location in "Paths and Database", as well as the [Sessions] section of the PHP.INI file.

However, there was also a .USER.INI file created at the same date/time that the problem started. As I mentioned, BlueHost had me use the "MultiPHP INI Editor" to update the PHP.INI file. It also appears to update .USER.INI, and even create it if it doesn't exist. It also populates it with a lot of extraneous, default values.

Worse, it seems to create mistakes in the process. It appears to be pulling in default values from somewhere, and then puts quotes around the value and the adjoining comment. This makes the comment part of the value despite the semi-colon. For example, this is one line as it originally appeared:

session.save_path = "/tmp ; argument passed to save_handler"

Checking PHP Info showed the value for "session.save_path" as "/tmp ; argument passed to save_handler". Not only is it pointing to the wrong folder (/tmp), it also thinks the comment is part of the folder name. When I put in the correct folder path name and moved the close quote from the end of the comment to the end of the path name, resulting in this:

session.save_path = "/home/cessnaon/public_html/forum/sessions" ; argument passed to save_handler

...the forum immediately started working again as before.

Now the post-mortem begins. I'm reminded of the following joke:

“Six Stages of Debugging”:
1) That can't happen.
2) That doesn't happen on my machine.
3) That shouldn't happen.
4) Why does that happen?
5) Oh, I see.
6) How did that ever work?

Right now I'm at Stage Six. Does .USER.INI override PHP.INI values? Where did .USER.INI (or its defaults) come from? If it was always present, how did it ever work before? What's really confusing me is the original problem I was trying to solve that precipitated this whole thread - namely, how to update max_input_vars from 1000 to 3000. I have that entry in every PHP.INI file I can find. Yet, the only one that matters is the one in .USER.INI.

In the end it's working, but I don't fully understand how which leaves me with the vaguely uncomfortable feeling I'm overlooking something.

In any event - thank you all for your help. Especially Ruben - if you're ever in Connecticut I owe you a beer (or other beverage of choice). Or a sight-seeing flight over NYC. Your choice. smile

Last edited by KirkW; 06/26/2020 10:28 AM. Reason: spelling error
Joined: Jun 2006
Posts: 16,292
Likes: 116
UBB.threads Developer
UBB.threads Developer
Joined: Jun 2006
Posts: 16,292
Likes: 116
UBB.threads is a web script; our support is geared towards our own script operating on a standard web server that we assume is operating properly (we test it to do so with every new release of PHP and MySQL). System web server configurations are out of the scope of user to user support as we always assume your web server is in working order (problems with your hosting environment are issues your host should be managing). The test script and control panel notices are designed to inform you of potential problems with your environment (max_input_vars for example can wipe your UBB.threads configuration file in some rare circumstances, because all of the variables cannot be passed to the back-end systems if the value is too low).

This forum is also a user to user support forum (the vendor, UBBSystems, does not regularly view this forum (as member support is obtained through the member system).

That being said, here are some links from Google:
MultiPHP INI Editor
PHP.INI
.USER.INI (suPHP)

Managing your max_input_vars you could try manually editing the existing php.ini and inserting the values, or asking BlueHost to manage them for you (while indicating that the system editor is causing instability in your web script).

The MultiPHP manager is a part of the cPanel Webhosting Control Panel, docs can be found here.


I am a Web Development Contractor, I do not work for UBBCentral. I have provided free User to User Support since the beginning of these support forums.
Do you need Forum Install or Upgrade Services?
Forums: A Gardeners Forum, Scouters World
UBB.threads: UBBWiki, UBB Styles, UBB.Sitemaps
Longtime Supporter & Resident Post-A-Holic
VNC Web Services: Code Modifications, Upgrades, Styling, Coding Services, Disaster Recovery, and more!
Joined: Dec 2018
Posts: 10
Likes: 1
K
Stranger
Stranger
K Offline
Joined: Dec 2018
Posts: 10
Likes: 1
I'm reminded of another joke, this one decades old:

Q: How many programmers does it take to change a light bulb?
A: None - that's a hardware problem.

Joined: Apr 2004
Posts: 1,945
Likes: 145
UBB.threads Developer
UBB.threads Developer
Joined: Apr 2004
Posts: 1,945
Likes: 145
customer: i need help. i may have broke something.

webhost tech support: i fixed the problem, boss.

[Linked Image]


Link Copied to Clipboard
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Recent Topics
spam issues
by ECNet - 03/19/2024 11:45 PM
Looking for a forum
by azr - 03/15/2024 11:26 PM
Editing Links in Post
by Outdoorking - 03/15/2024 9:31 AM
Question on barkrowler and the like
by Mors - 02/29/2024 6:51 PM
Member Permissions Help
by domspeak - 02/27/2024 6:31 PM
Who's Online Now
3 members (rootman, Gizmo, Nightcrawler), 562 guests, and 186 robots.
Key: Admin, Global Mod, Mod
Random Gallery Image
Latest Gallery Images
Los Angeles
Los Angeles
by isaac, August 6
3D Creations
3D Creations
by JAISP, December 30
Artistic structures
Artistic structures
by isaac, August 29
Stones
Stones
by isaac, August 19
Powered by UBB.threads™ PHP Forum Software 8.0.0
(Preview build 20230217)