Also, the free hosting servers do have a 99.9% uptime rating (I’ve verified this myself), so although some servers do have occasional issues, they only affect a small portion of the overall user base.
If I want to attract PAYING Customers in order to make MONEY, than i would take care of every Customer. Right now, I do not have the confidence that even IF I PAID, the Service would be any better.
Right now, I am experiencing a 100% Downtime with no Solution in sight, no feedback, no recourse, no action item, NOTHING.
And what I am looking for is a working site, not nice words that are not resolving the issue.
I’m not sure what to tell you, except for the fact that we cannot do anything about a suspended account. We have no control over them, we can’t reactivate them. It is literally impossible for us to do anything. Ask the support team, they are the only ones that can do anything.
The lessons learned before we upgraded to PHP 8.2 was that the way we used to handle PHP installations on free hosting servers was too custom, too fragile, and too painful to update.
So, when updating to PHP 8.2, the decision was made to completely redesign how we install and manage PHP on free hosting. And also to rebuild all servers with the latest OS versions to simplify things.
Those bugs and issues are all resolved now, and we have a nice, clean, simple and maintainable PHP installation. So any upgrades from now on should be much easier.
The main reason it was so painful was because the PHP upgrade was much more than just bumping the version of PHP.
Thanks for the clarification.
True, there can be some losses when doing the OS Upgrade. I hope that this was/will be addressed with the new upgrade procedures in the respective Distributions.
As I run a Web Server and MySQL on a Laptop, but for a number of reasons have to keep that current, I am pondering checking the Version (OS or PHP or …) in the Coding to avoid surprises.
Even then, there are outside Factors that make this a tad bit difficult, thinking file_get_contents and HTTP vs HTTPS support which resulted in me using CURL.
It’s more like there: can be some losses when strained servers are on their last legs, and you want to migrate data from them while also keeping regular traffic going.
The problems arose while moving from a less maintainable to a more maintainable solution. The whole exercise was intended to reduce these kinds of unexpected issues in the future. But since we basically redesigned how we do PHP from scratch, of course you’re going to run into some unexpected things.
There were bugs in the new setup that were fixed so they won’t happen again. And this exact migration will never happen again exactly like it did, because we’d have to migrate back to an old setup (which we know is not maintainable) first to repeat this exact process.
We’re never going to have a migration exactly like that again.