Camelot-Hosting down?

Wyvern Creations:

Im sorry, but I pay for my ".com" to work. Not to have to have my customers jump thru geeky hoops and try to find ".com/index.php" This is NOT "my" problem, its Camelots and they need to fix this so my ".com" works they way its supposed to.

I do appreciate the help though...just getting VERY frustrated at this point as I am sure a lot of people are and Im sure Camelot is losing their minds as well..

My site is still down... I've cleared cache, tried three browsers. Can log into my Admin page for my site, but the site is down as far as any customers can see.

I'm getting the same as some others have noted "WARNING: An Error occurred, please refresh the page and try again."

Can anyone out there please try to access my site? vtstuff.com or https://www.vtstuff.com

Thanks.

To add to my previous post, trying to access my site via FTP (Filezilla), it will not list any files from my public_html folder. I get:

Error: Connection timed out after 20 seconds of inactivity
Error: Failed to retrieve directory listing

vtstuff:

To add to my previous post, trying to access my site via FTP (Filezilla), it will not list any files from my public_html folder. I get:

Error: Connection timed out after 20 seconds of inactivity
Error: Failed to retrieve directory listing

Yes I'm getting the error warning you had posted. Even with a dns flush.

Wyvern Creations:

That only works for the ones I can reach...
Now I am by NO means computer literate but I don't understand if you have a page bookmarked or even went to look for it on a search engine, and hit it and its down/shows an error message why when the site comes back up you cant see the fixed site without having to do all these skips and jumps to fix an issue that had nothing to do with the computer my customers are using. Its bad enough Ive lost I don't know how many sales over this being down at all not to mention SE position and all sorts of other things but now I have to hope that someone I may not know and may not be able to get in touch with will understand if they try to see my page again if and when its fixed that they cant just type in the URL???? Im sorry but that's pretty hard to swallow. IMO Camelot needs to do a re-direct or something on everyones page that will bring it to the sight or whatever so we don't have to worry about losing all the sales/customers who think we are now closed due to this and will not be able to see our site once its back up..

Wyvern Creations:

Im sorry, but I pay for my ".com" to work. Not to have to have my customers jump thru geeky hoops and try to find ".com/index.php" This is NOT "my" problem, its Camelots and they need to fix this so my ".com" works they way its supposed to.

Yup. I understand: "It should just work", and "it's not my fault; I don't understand it; so I've gotta point the finger at someone, to justify that I'm losing sales".

You're right: It's not your fault that the server went down. That's on some piece of metal and silicon that spins 9,000 times per second for several years, and we expect it to never wear out or overheat. But it did.

And, yes, It's not your fault that customers' browsers are left confused. Nor is that really Camelot's fault.

Lemme explain: every time you visit a website in your browser, your browser goes out and fetches a copy of that site page. It ALSO remembers that copy so that the NEXT time you visit that same page it can look to itself and just display what it got last time, instead of going out and fetching it again. This is all to speed things up. This action of storing what it last saw on the page is known as "caching" (pronounced like "cashing"). Most browsers nowadays insulate you from the word "cache", and simply call it "history".
Now, you'll find that sometimes a page will specify that it should not be cached ... such as your shopping-cart/checkout page: you definitely don't want to see an "old" version of that! So, a special flag (called a "header") is set in the page data that comes back from the server, to tell your browser to either not cache it, or to only "keep" it for maybe 30 seconds, instead of forever.

What's happened during the Camelot outage is that your customers visited your example.com website, and got a "sorry, there's been a problem; maybe the DNS has changed; please clear your DNS and cache ... or maybe the IP has changed, please contact the site owner" message.
And, THAT message has gotten cached in their computers.

(I would say that the WHM/cPanel software that displayed that "down" message should have set a flag in that page to tell computers NOT to cache the page. But, again, that's not Camelot's fault.)

For people who have bookmarked your site and have gotten the "down" page cached, there's NOTHING Camelot can do about that, because those customers have the "down" page stored as the last response from your site. And, therefore their computers won't even "try" to hit the live server. Unless they clear their browser cache/history.
Or if they use a different browser that doesn't have a cached copy of the "down" page. Tell them to try Firefox instead, or Chrome instead. Those are way better than Internet Explorer anyway. Use one they haven't been using.

Okay, I've just taken a bunch of my time to write this out. For what? I get nothing for it. You're probably still gonna say "it should just work: I'm paying for it".

Also, you can do what (you or others) said earlier that you wished Camelot would have done: post on Facebook or twitter or somewhere that your customers can find it, telling them what they can do to regain access to your site.

OK, then why when mine and other sites I go to go down when they come back up again I can just click on them in my favorites and not do all the other crap you just listed???? Sites go down all the time, they don't "stay down" for those people, they come back up and their customers can go right in and find them without having to clear history or switch browsers or any of that other crap. I understand what you are saying but what is so special about Camelots issue that makes it so 11 years worth of customers that not all are on FB cant find me now????? Im sorry, but it most certainly IS Camelots problem, NOT mine!!

vtstuff, I get "WARNING: An Error occurred, please refresh the page and try again." when I try to go to your site. That is normally a database error. If you can get into cPanel, and then phpmyadmin, run a repair on your database and see if it clears that issue up. I suspect the sessions table crashed...

DrByte:

What's happened during the Camelot outage is that your customers visited your example.com website, and got a "sorry, there's been a problem; maybe the DNS has changed; please clear your DNS and cache ... or maybe the IP has changed, please contact the site owner" message. And, THAT message has gotten cached in their computers.

Have to disagree on this.

Why? You'll notice in this case, when "your-domain.com" is entered as the URL there is a redirect going on and showing this URL: your-domain.com/cgi-sys/defaultwebpage.cgi <- this is a cPanel 404 page showing a problem at the server level

Such is the case at the moment with http://hdworkgear.com

If somebody later on types in or uses a Bookmark for "your-domain.com" or http://hdworkgear.com and the site is working properly, it will not be redirected and show the site as it is currently working. And it may not be working correctly such as http://vtstuff.com/ -- which is not working correctly but displaying an error msg. in this case.

For those of you in this situation it is best to walk away for awhile. There is nothing you can do.

Although your Hoster is working on fixing the problem(s), it will take as long as it takes. No sense beating yourself up by constantly checking your site to see where things are. If you cannot contact your Hoster then hopefully they will reach out to you with an update or timeline to help alleviate frustration.

Rob, yes, a redirect is occurring.

But also, the browser is remembering that the last visit to the site resulted in the redirect.

I agree: it should NOT cache it.

... but it is.

I've seen it with a dozen of the sites affected with this outage. Clearing browser history for the time period during which those redirects were happening is the only thing that's fixed it.
I blame something with the way cPanel is doing that redirect. (IMO it'd be better if a 500-series error were thrown, and just a blank screen .... that'd avoid being cached, and avoid all SEO-related damage. A 404 is death when it comes to SEO.)

DrByte:

Okay, I've just taken 10 minutes to write this out. For what? I get nothing for it. You're probably still gonna say "it should just work: I'm paying for it". 10mins? hmmm

Anyways, this isn't or has been fun or anyone. Camelot, us, our customers, you and your customers or anyone. No matter how you color it it simply s*cks! It is what it is though regardless of who's hd fried.

Clearing the cache or doing a dns flush only works if things are correct up stream, like the server or dns. If up stream is having problems then we will continue to have problems. There has been some improvements since last night but not nearly enough to jump for joy or even relax.

I've learned over the years that pointing fingers, jumping up n down, stomping my feet won't make anything better any faster. It's something we all have to live with whom ever the hosting company is. Another thing, imagine the stress camelot is facing knowing we are all waiting as patiently... oh hell, knowing we are all frustrated!!!

So yes, we are all losing money but it still can't get fixed until it's fixed.

yd29999:

Clearing the cache or doing a dns flush only works if things are correct up stream, like the server or dns. If up stream is having problems then we will continue to have problems.

That I would agree with.

It is quite possible that new IPs have been assigned, to the server(s) and/or Hosting accounts and DNS propagation is in effect. I would still argue though that entering just the Domain name will suffice as PHP pages are not usually cached and if I remember correctly, Zen Cart uses a no-cache directive either in a PHP file or .htaccess file.

Website Rob:

I remember correctly, Zen Cart uses a no-cache directive either in a PHP file or .htaccess file.

Zen Cart does, yes.

But the cPanel redirects for your-domain.com/cgi-sys/defaultwebpage.cgi do NOT.

barco57:

vtstuff, I get "WARNING: An Error occurred, please refresh the page and try again." when I try to go to your site. That is normally a database error. If you can get into cPanel, and then phpmyadmin, run a repair on your database and see if it clears that issue up. I suspect the sessions table crashed...

Database repair didn't fix it. Time for a support ticket into Camlelot, I guess...

vtstuff:

My site is still down... I've cleared cache, tried three browsers. Can log into my Admin page for my site, but the site is down as far as any customers can see.

I'm getting the same as some others have noted "WARNING: An Error occurred, please refresh the page and try again."

Can anyone out there please try to access my site? vtstuff.com or https://www.vtstuff.com

Thanks.

vtstuff:

To add to my previous post, trying to access my site via FTP (Filezilla), it will not list any files from my public_html folder. I get:

Error: Connection timed out after 20 seconds of inactivity
Error: Failed to retrieve directory listing

barco57:

vtstuff, I get "WARNING: An Error occurred, please refresh the page and try again." when I try to go to your site. That is normally a database error. If you can get into cPanel, and then phpmyadmin, run a repair on your database and see if it clears that issue up. I suspect the sessions table crashed...

When this message is displayed, this FAQ may provide additional assistance. It is just maybe possible that in the likely millions of files restored, that at least one could have a minor issue in it. The information obtained from the below FAQ may relate to a specific issue or it may relate to the overall "network", but it provides directions and explanations that should help: https://www.zen-cart.com/content.php?311-warning-an-error-occurred-please-refresh-the-page-and-try-again

mc12345678:

When this message is displayed, this FAQ may provide additional assistance. It is just maybe possible that in the likely millions of files restored, that at least one could have a minor issue in it. The information obtained from the below FAQ may relate to a specific issue or it may relate to the overall "network", but it provides directions and explanations that should help: https://www.zen-cart.com/content.php?311-warning-an-error-occurred-please-refresh-the-page-and-try-again

Apparently, some of my site did not come back completely from the restoration... my SuperTracker was broken during this, along with my Backup Utility (Backup ZC).

I'm not yet sure if anything else is not working, but Tony got my site back up temporarily, by commenting out an offending line in the code. I'm glad the site is up, but not too thrilled that I have to rebuild some of the tools that I had installed in the past.

Well it looks like things are smoothing out. No issues with our site for the past few hours and most of the sites I saw on here are back up. Tony seems to be going through the tickets. So if anyone is still having problems I would recommend they put a ticket in.

Im going to bed now

One of my clients is having trouble with curl on the rebuilt platform. If you're getting an error like this:

[10-Jul-2017 04:18:49 America/Chicago] PHP Fatal error: Call to undefined function curl_init() in /home/YOUR_SITE/public_html/includes/functions/plugin_support.php on line 40

a patch was posted by DrByte today, at: https://github.com/zencart/zencart/raw/c74c5325243c27ccbc3b105f893d00f5ab80838b/includes/functions/plugin_support.php

I'm getting many PHP errors since the restoration. It seems like maybe a different version of PHP is on the server, or some INI file settings may be different.

We've had to comment out a line in SuperTracker, and I just did a couple test orders. The first order was using a PO (temporarily enabled for testing the order), and that was fine.

The second order was with my credit card, and the order went fine, however, when I went to try to delete the order from my Zen Cart, I got this:

[10-Jul-2017 16:10:43 UTC] PHP Fatal error: 1292:Incorrect datetime value: '' for column 'last_modified' at row 1 :: insert into so_payments (orders_id, payment_number, payment_name, payment_amount, payment_type, date_posted, last_modified) values ('4704', '4704-', 'My Name', '8.24', '', '2017-07-10 16:09:33', '') ==> (as called by) /home/xxxxxxxx/public_html/MY_ADMIN/includes/functions/database.php on line 53 <== in /home/xxxxxxxx/public_html/includes/classes/db/mysql/query_factory.php on line 155

The previous error I got with SuperTracker was VERY similar, crashing again in "query_factory.php", and was this:

[10-Jul-2017 15:46:29 UTC] PHP Fatal error: 1364:Field 'cart_contents' doesn't have a default value :: INSERT INTO supertracker (ip_address, browser_string, country_code, referrer, referrer_query_string, landing_page, landing_page_name, exit_page, exit_page_name, time_arrived, last_click, products_viewed) VALUES ('nnn.nnn.nnn.nnn', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36', 'us', '', '', '/', 'Home', '/', 'Home', NOW(), NOW(), '') ==> (as called by) /home/xxxxxxxx/public_html/includes/classes/supertracker.php on line 231 <== in /home/xxxxxxxx/public_html/includes/classes/db/mysql/query_factory.php on line 155

(Note: I've changed some info above for security, such as "MY_ADMIN" and directory name to "xxxxxxxx")

Anyone know why this could be happening? It was all OK before the crash. Seems to me like a PHP setting or some defaults that are no longer what they used to be.

Thanks.

vtstuff:

I'm getting many PHP errors since the restoration. It seems like maybe a different version of PHP is on the server, or some INI file settings may be different.

We've had to comment out a line in SuperTracker, and I just did a couple test orders. The first order was using a PO (temporarily enabled for testing the order), and that was fine.

The second order was with my credit card, and the order went fine, however, when I went to try to delete the order from my Zen Cart, I got this:

[10-Jul-2017 16:10:43 UTC] PHP Fatal error: 1292:Incorrect datetime value: '' for column 'last_modified' at row 1 :: insert into so_payments (orders_id, payment_number, payment_name, payment_amount, payment_type, date_posted, last_modified) values ('4704', '4704-', 'My Name', '8.24', '', '2017-07-10 16:09:33', '') ==> (as called by) /home/xxxxxxxx/public_html/MY_ADMIN/includes/functions/database.php on line 53 <== in /home/xxxxxxxx/public_html/includes/classes/db/mysql/query_factory.php on line 155

The previous error I got with SuperTracker was VERY similar, crashing again in "query_factory.php", and was this:

[10-Jul-2017 15:46:29 UTC] PHP Fatal error: 1364:Field 'cart_contents' doesn't have a default value :: INSERT INTO supertracker (ip_address, browser_string, country_code, referrer, referrer_query_string, landing_page, landing_page_name, exit_page, exit_page_name, time_arrived, last_click, products_viewed) VALUES ('nnn.nnn.nnn.nnn', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36', 'us', '', '', '/', 'Home', '/', 'Home', NOW(), NOW(), '') ==> (as called by) /home/xxxxxxxx/public_html/includes/classes/supertracker.php on line 231 <== in /home/xxxxxxxx/public_html/includes/classes/db/mysql/query_factory.php on line 155

(Note: I've changed some info above for security, such as "MY_ADMIN" and directory name to "xxxxxxxx")

Anyone know why this could be happening? It was all OK before the crash. Seems to me like a PHP setting or some defaults that are no longer what they used to be.

Thanks.
Those all sound like a newer MySQL version is installed. Newer versions have been getting progressively more "strict" in certain rules. It could be that the MySQL version is the exact same but hasn't had the stricter rules relaxed by changing its master configuration.

If the MySQL configuration can't be made less strict, you have 2 options:
a) If you're using Zen Cart v1.5.5 or newer, you could force the less-strict rules by adding a define for DB_MYSQL_MODE in your configure.php file and setting it to the combination of modes that relaxes things to suit your plugins' old expectations, per https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html

b) The best solution is to upgrade your old plugins by changing them to comply with newer MySQL strict rules (such as certain fields need a default value if they're set to "not null", and date-related fields can't have a "blank" value, etc). This involves both changing the definition of those fields in the database, and also in some cases the PHP code that's generating the queries/data to store into those fields.