Remove PHP Errors

[[TM1]Dave]

Hello S2 Team.

When you want to view the match stats of a player in a certain game (view a player > then click on the stats icon at the left of a specific match), you are able to view a php error.
Either fix this or remove it with display_errors = 0 in your php.ini or via ini_set, as this is a security issue - your visitors should not be able to know the file and folder hiearchy of your webpage.



Regards,

Dave

[Manhim]

Or just build error and exceptions handlers that changes the page to something like error 404 ("Oops, something went wrong") when there's a Warning or more and hide Notices and such (Which is probably already done since it's the default when installing PHP from source).

[[S2]Vinthian]

You should know that most of the code is in beta and is being worked on very frequently. It'd be a pain to not have display_errors on because they need to debug. Now, after release is a different story.

[Manhim]

Well they could do like I said in my earlier post, simply handle the errors your way. This would be doable:

ob_start()
set_error_handler("yourfunction", E_ALL ^ E_NOTICE);

and in yourfunction you have:

ob_end_clean();
ob_start();
(Show the PHP error page)
(Add the error to a database, maybe even the whole page using ob_get_content())
exit();

and then you have an "administration panel" so you can get the most seen errors using the database.

[[TM1]Dave]

Or basically, what you can do is: make them only visible for s2games members, just a usergroup check (providing that there are usergroups - if not then member ids)

[Manhim]

It wouldn't be that useful since usually it's the users that are having problems with the errors and hiding them would just let the idea that this part of the website isn't done while there was only a PHP error.

[Shzzzir]

Hiding errors from users? No.

We are beta testers, we are supposed to report this stuff. How can we report errors that we can't see?

This is a beta testing phase, not a ****ing Trial, stop acting like it

[Manhim]

Only 1% of the errors get reported, if there would be an error handler like that 100% of the errors would be reported with output code, exact point of failure and every informations required.

[Shzzzir]

And what is your statistics based on? Could you provide me with the research? Oh, what's that you say... you can't, well then don't pull fictional numbers out of your sleave to back up your arguments.

Adding the errors to a database is not a viable option, bugs that occur often get reported often, usually starting several threads/bug reports about the same subject.

If they don't occur often, and don't get reported since the magnitude of the bug isn't big, then there's no real problem(debug priority).

[Manhim]

Exactly what I'm talking about, debug priority. With a database they could locate bugs way easier and by experience by making PHP web site users don't report any bugs and I often get 0% bug reports even if it happened for more then 1000 ips. Sometimes I hit less then 1% with 2 or 3 reports for more then 3000 ips.

The bugs that get less reported are the ones which don't stop someone from browsing the website but rather "small" bugs, but these still need to be fixed and since nobody is reporting it then who (in the staff) is going to find it?

It's just easier to make a database and it doesn't even take that much time to setup.


Also don't forget that in the "Oops something went wrong" page there could be debugging informations to repeat the process, so less try and guess time wasted.