free account:
http://tukdam.epizy.com/
(please specify the website or account you are asking about)
HTTP error 500
(please share the FULL error message you see)
(other information and details relevant to your question)
it’s gone since at least last sunday
everything else (cpanel, FTP access) works
Could anyone please provide some help or information what’s going on here?
–Michael
Please read this article to troubleshoot and fix HTTP ERROR 500:
That won’t help me. I didn’t change anything of my website, neither code, nor database, nor htaccess config. My site has been running just fine all the time before the 500 came. Therefore the problem is not at my end.
Read this article means Please Read this article, and do whatever it says It won’t damage your site, just will show what’s going on behind error 500.
If it was, as you say, A server issue, then it would be as below;
The freehosting works on a group of clustered ‘node’ computers, each one has a job, e.g;
→ MySQL Databse
→ PHP My Admin
→ File Manager
→ User Nodes.
All these are bound together in a network to make it act like one supercomputer, If there are, say 100,000 People, then that would be divided between all the nodes, leaving say, 1000 people a-node, In this sense, If you say it was the server’s fault, Everyone on your ‘node’ would also have 500 Errors.
Basically, It’s not the server (Edit. But it could be the code)
(Disclaimer - All numbers, user numbers and server numbers are random and do not reflect the IRL statistics.)
It may be on your end, it may be on our end, it may be on another end entirely. All we know is that your website crashes, and nobody knows how or why.
The first step is to figure out what exactly crashes your website. Since it’s your website that’s crashing, it’s up to you to debug it. The article shared by Ergastolator1 is a good place to start.
If you have the full error message, and either need help in making sense of it, or suspect it may be a server issue, please share the error here so we can have a look at it.
It is logically entailed the problem must lie in a changed runtime environment because, as I already said, I dind’t change ANYTHING. So it is only logical to assume it’s your end which causes my site to crash.
This bein said, could you please at least point me to information regarding recent changes in your runtime environment, most likely PHP installtion? Or am I supposed to guesswork my way through changes I didn’t do and I have no way being aware of?
I enabled the error messages, to fix this stuff I would have to change my scripts That’s not what I want.
To be clear: My script did not crash because I changed it, it now crashes because you changed something on the server, most likely the PHP runtime environment. I haven’t even been made aware that there were changes, that’s not a very friendly thing to do. And it’s not ok, to have users change their scripts when they didn’t cause the trouble. Let me repeat: I did NOT change ANYTHING, you did.
What I need now is a way to go back to the PHP environment BEFORE the 500 occured, back to the environment my unchanged scripts had been working on flawlessly.
There are providers offering a way to switch PHP versions…do you offer a similar possibility?
Because that would be the only acceptable way, otherwise unfortunately I would be forced to delete my account and go elsewhere. It’s just not feasible and practical for me to change my scripts al the time every time the server changes, just saying.
btw:
errors:
Deprecated : Array and string offset access syntax with curly braces is deprecated in /home/vol9_6/epizy.com/epiz_25310290/htdocs/…rest cut for privacy
other errors can’t be posted in public because of security and privacy issues (I don’t want that)
PS: If you offer a way to switch back to a legacy PHP version, please could you state what version was running before you updated/changed your server? So I can select the version that my scripts formerly worked fine with.
We replaced PHP 7.3 with PHP 7.4 recently, and had to disable some functions on old PHP versions. Both of these were caused by security issues identified in these PHP versions. Our goal is to keep PHP 7 updated to the latest stable version. At this time, that’s PHP 7.4.
It’s very likely that your issues are caused by your website not being compatible with PHP 7.4. Unfortunately, there is only one solution I can offer you: fix your website so it works with the latest PHP version.
This is why I want to get debugging info for your site to be sure. Because “can’t help you, just fix your software” isn’t a nice answer to give, so I want to be sure that it really is a PHP version compatibility issue before giving an answer like that. Because if my guess is wrong (because guessing is all I can do without debugging info), then I may be denying you a simpler solution.
A quick way to test this would be to switch back to PHP 7.3. Unfortunately, PHP 7.3 was completely replaced with PHP 7.4, so there is no way to go back to PHP 7.3.
We have the responsibility to provide a modern and secure PHP runtime environment. Part of that is that we update PHP to newer versions once in a while. We see a lot of script that “are working just fine for many years” that have not been updated in that time and are filled to the core with unfixed security issues waiting to be exploited by an opportunistic hacker. We hate both seeing customer websites defaced and hate seeing hackers get into our systems, which is why we have to keep our PHP environment up to date.
As for making the site compatible with PHP 7.4, that’s up to you to do. If you use off the shelf software, please check if there are any new versions available for the software which works with PHP 7.4. If you have built the software yourself, please review the error messages and make the changes.
If you need help in figuring out what to do, we’re happy to point you in the right direction. But again, we need that debugging info to do so.
Thanks for your reply. I just found out you can switch back to ancient PHP 5.4 as a temporary workaround until I find the time to fix outdated parts in my code. I fully respect your concern about safety regarding hackers and fixing vulnerabilities by upgrades (I used to be a sw developer myself and know such concerns). I was just missing information about such a change in runtime environment, any form of anouncement raising awareness. That’s indeed a point on your side I criticize tbh. You really should consider to inform users next time a certain period of time before you do the actual change, and tell users in adcance what’s going to happen and when, so users will have the time to react and fix stuff prior to facing downtime all of a sudden. I see the point, it’s a free account and you have limited resources to support that. I do get that. But a little information in advance shouldn’t be so heavy on your resources, at least I guess so. Anyway thanks for the info.
Downgrading is an option, at least as a temporary solution. Although, if your script supported PHP 7.3 before, I would highly recommend to use PHP 5.6 instead of PHP 5.4, simply because it’s a lot less ancient.
The lack of an announcement beforehand is indeed not good and not the way we would like to do things. Unfortunately, we didn’t get any heads-up about the upgrade until after it had already started, without any information about duration, consequences and so on.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.