issue performing routine maintenance- deleting old threads

[jangofett]

www.greencoffeebuyingclub.com [nofollow] when I perfrom the maintenance task to remove topics that haven't been posted in for 30 days, it removes all the topics including the stickied threads. when i post in that forum nothing shows up. Then if I repair boards all the old posts come back including any of my new ones? Has anyone experienced this? 2.0.15

[Bob Perry of Web Presence Consulting]

www.greencoffeebuyingclub.com when I perfrom the maintenance task to remove topics that haven't been posted in for 30 days, it removes all the topics including the stickied threads. when i post in that forum nothing shows up. Then if I repair boards all the old posts come back including any of my new ones? Has anyone experienced this? 2.0.15

hmm, there's a problem with the database somewhere I think, go check and make sure that all the scheduled tasks in the maintenance menu are enabled, especially the ones that update the database.... after you perform the file removals, do you jump over to the database section and do the optimize function?

[Kindred]

does your host have caching enabled?

[jangofett]

does your host have caching enabled?

im not sure

[shawnb61]

Sounds more like some db corruption to me.

I'd backup everything first.

Next, I'd run the "Find & and repair any errors" function in the maint menu.  If that has issues, try the equivalent in phpmyadmin.

I think that will fix it.

If oddities return at some point, I'd consider cutting over to InnoDB as your engine.

[jangofett]

Sounds more like some db corruption to me.

I'd backup everything first.

Next, I'd run the "Find & and repair any errors" function in the maint menu.  If that has issues, try the equivalent in phpmyadmin.

I think that will fix it.

If oddities return at some point, I'd consider cutting over to InnoDB as your engine.

I did the find and repair in admin that actually brings back all the old posts even though it says no issues found. I have to check the phpmyadmin is that in cpanel?

[shawnb61]

Find & repair will attempt to fix db-level issues.  Hopefully, whatever issues there were got fixed.   (Still my suspicion here.) 

So, now that db was hopefully fixed, next I would re-try the pruning function to see if it is working OK. 

Yes, you should find phpmyadmin somewhere in cpanel.  I'd suggest re-trying the pruning function first. 

[jangofett]

I did all that it behaves the same. Found the phpmyadmin and ran the checks. everything checks out but when I go to even delete the board I get an error 500 that my site can't handle the request. So I can't prune it without it timing out and removing all the threads. When I perform a recount it all comes back, and I can't delete the board... ugh

[Kindred]

if it is triggering an 500 error, that's a server side problem and the server should record something in the error logs about it

[jangofett]

Ok i'll ask and see what they say. This all started happening when we switched to bluehost. I think the php version is good enough but we have had some real wierd issues. some of the problems are fixed but its like paying whack a mole. I noticed some discrepancies on the installed packages listed 2.0.15 isn't showing a green dot etc. but the forum is showing as 2.0.15...

[jangofett]

if it is triggering an 500 error, that's a server side problem and the server should record something in the error logs about it

they said they don't see anything... 

[Kindred]

Then they suck as a host... seriously,  anything that triggers a 500 error should leave some sort of trace entry in the logs

[shawnb61]

A few places to look:

Sometimes, in cPanel, there is an entry for "Errors!".   If you see something like that, look at it!

Browse around in File Manager, looking for error logs.  They are usually named something really obvious like error_log...

Look in:
  - Your root folder, the highest level folder you can see in File Manager
  - Your web root folder, usually called public_html or something similar, which is the highest level folder you have exposed to the web
  - Your smf folder.  This is the same folder where your forum's Settings.php file is.   Sometimes it's in a subfolder of your web root folder.

The cause of a 500 error is usually in a flat error log in one of those locations.  Poke around & search for it. 

Hope this helps,

[jangofett]

Then they suck as a host... seriously,  anything that triggers a 500 error should leave some sort of trace entry in the logs

from what i hear all hosts suck. I switched from godaddy--a small orange--now bluehost. I'm not impressed.

[jangofett]

A few places to look:

Sometimes, in cPanel, there is an entry for "Errors!".   If you see something like that, look at it!

Browse around in File Manager, looking for error logs.  They are usually named something really obvious like error_log...

Look in:
  - Your root folder, the highest level folder you can see in File Manager
  - Your web root folder, usually called public_html or something similar, which is the highest level folder you have exposed to the web
  - Your smf folder.  This is the same folder where your forum's Settings.php file is.   Sometimes it's in a subfolder of your web root folder.

The cause of a 500 error is usually in a flat error log in one of those locations.  Poke around & search for it. 

Hope this helps,

i started doing some of that the errors! in cpanel was clear but i'll check that file manager deal.

[Arantor]

Not all hosts suck, but the adage that you get what you pay for tends to hold true. Mind you, I'm biased, I work for a company that does big scale hosting (where the hosting bill can be $5000 a month for a single site and that's just the pure AWS hosting cost without any of our time on top) but the odds are that we know the site is down before a ticket even hits our tracking system...

If you pay under $5 a month for a site, remember that that has to cover the costs associated with running your account - and paying the wages of the people who run it. Imagine how many sites each person has to be responsible for to pay the bills.

But there's levels of poor attached; a server owner who doesn't make logs available is usually not so good.

[jangofett]

Not all hosts suck, but the adage that you get what you pay for tends to hold true. Mind you, I'm biased, I work for a company that does big scale hosting (where the hosting bill can be $5000 a month for a single site and that's just the pure AWS hosting cost without any of our time on top) but the odds are that we know the site is down before a ticket even hits our tracking system...

If you pay under $5 a month for a site, remember that that has to cover the costs associated with running your account - and paying the wages of the people who run it. Imagine how many sites each person has to be responsible for to pay the bills.

But there's levels of poor attached; a server owner who doesn't make logs available is usually not so good.

i found some errors but they didn't look related. It looked like people were querying php that doesn't exist or something. I agree if I paid $5k a month I would want a much higher level of service than i am getting for sure. But i bet the sites that get that hosting have much higher needs than my simple green coffee sharing site

I am wondering if my 2.0.15 got some how wrecked on the host transfer and now I need to just do a reinstall of 2.0.15 what is the proceedure to just reinstall the update or go back to 2.0.14?

[Kindred]

ok....  please don't assume that errors are unrelated -- and we're not talking about the SMF error log - we are talking about the SERVER error log.

If you have a server error log.
Clear it.
do your set of actions that results in the error...
check the error log.

if there is anything in there, please post it here.

(and, incidentally, I pay under $10 a month for my hosting and I have never had a service ticket go unanswered (with a useful answer or solution) in over 10 minutes - the host (ICDSoft) also has a cheaper plan, with the same level of service from the helpdesk. IN 10 years with them, I have never had a complaint that was not instantly addressed - even to the level of helping me debug a script.