PLEASE help with this php error

hello guys
I uploaded a PHP landing page to my hosting
and it gives me this long error and at the end of this page there is the landing page working perfectly fine
please help with that if you got any idea

 

They are not errors, they are just warnings. On a live server, you should disable display_errors.

To disable it, put this line of code on top of your PHP script:

ini_set('display_errors', 'Off');

Or

Find the following line in your php.ini file
display_errors = On

and change it to:
display_errors = Off

That should hide the warnings

 

THank you sooo much that really helps, really appreciate it ❤

 

Great. Glad I could help

 

I'm with @sarahk on this in that suppressing warnings/errors is NOT the answer. That's sweeping potential problems under the rug instead of FIXING THINGS. The problem is still there, all you're doing is hiding it, and that's a half-assed idiotic dipshit way of working on anything.

Now that said, to tell you how to fix it, we'd need to see the actual code. Without that we can't tell you what to fix.

 

4 Words: KISS.
Keep It Simple Stupid.

The OP Said This:

Of course I know about fixing the warnings or errors that's why I made it clear that the code HIDES the Warnings.

Secondly, this is a live server. The OP needs to turn off display_errors regardless. You don't turn on display_errors on live servers.

Also that's why I did not suggest to disable error_reporting. Ideally, you want the warnings to be reported but you certainly do not want to show your end users these warnings.

So to the OP, they are right, you should fix these warnings, but you should leave display_errors Off

 

Just beware the dangers of oversimplification; the trap of false simplicity and complexity mismatch. It's possible to oversimplify to the point you're no longer able to do the job properly, simply, or easily. Just as many things people label as "easier" -- like the mind numbing dumbass asshat dipshittery that are HTML/CSS frameworks -- actually aren't. They "simplify" by pissing on why HTML is separate from CSS, what HTML is even for, and slop their own crap atop the basics one SHOULD be learning before even thinking about a "framework".

Turning off errors being one of those traps. You should at least install a mechanism to tell the user something went wrong. Instead of supresing errors, in anyplace that might bleed information useful to hackers add try/catch, or add your own error handler.

setting it to do nothing but go to the logs gives the user no information to even let them know something is awry. In that way disabling it on deployment is STUPID... well, not so much disabling it, as not trapping it to provide user feedback. set_exception_handler and set_error_handler are your friend! And anything those can't catch you probably SHOULD be displaying. That way the user can provide you meaningful feedback to help you dig through your error.log

 

@deathshadow

I agree with some of what you said. But are you really encouraging developers to display errors in a production environment? Really! Really!!...?

If yes, then I have nothing more to say....

Adding your own handler is the best option and I would have fully agreed with you if you had stopped there...

We use a reporting system that reports all errors to developers via email and displays a simple user friendly page of an error to users... But you don't expect me to write the process of all that in a question this simple, do you?

 

I do the same except when I am logged in as Admin. That way I can also add some notes about this or that function (in case I forget what this or that thing is for sometime down the road).

 

Not necessarily the actual error message, but are you REALLY encouraging developers to not give users SOME form of feedback when something goes wrong? Could be what they tried to do didn't happen, are you just going to leave them hanging in the wind, pretending nothing went wrong? That's utter shite from a UX perspective!

Mind you, it's shite I've seen on more and more sites. Take hashnode or "DEV" where if something goes wrong, you get an endless CSS animated circle and zero indication what went wrong with either their server-side code or their client-side scriptttardery. You'd think they'd both gone full Gungan by using "fetch"

Oh noes, shuwin teh uzer n errrr massage wen n teres n errrr, teh horrurs!

Do you not see how utterly dumbass providing ZERO user information when things go bits-up face-down are? Things go pear-shaped you don't cock it sideways.

I'm not saying don't suppress or hide the actual error if it's something that contains security related data, but for the majority of errors suppressing them without any plan of what to show the user when you do so is pretty much a developer being a lazy douchebag.

 

@OP
If your landing page was working perfectly fine you wouldn't have received the notices. HTML and PHP are two totally different languages. Your page showed up because it was written to the browser. The php posted notices because it guessed at what you were trying to achieve ("Use of undefined constant - ASSUMED - WILL THROW AN ERROR in future versions of php") so fix the problem by defining the constant correctly. Another thing is that judging by the way you have multiple notices of "Undefined offset: 4" it probably got stuck in the loop because of the original offset.

Warning: if your script gets stuck in a loop and begins pulling down host resources, the Host WILL disable all the php scripts in your hosting account at the click of a single button! That could mean years of hard work disabled and open to the public within a millisecond. That could also mean days or weeks to get everything operational again. (Happened to me several times)


@Efetobor
The OP's page may be on a live server, but that does not mean it's an active page for the viewing public. It could be in a development area. I also believe in the KISS method, have for years, but deathshodow is right, you can't leave users hanging. When your contact form is submitted, you show a success notice. If the fields aren't filled in correctly, you notify the user of what needs to be fixed. But if your contact form doesn't get submitted for some odd processing reason then what?

That's all deathshadow is trying to say. Remember, every action has an equal and opposite reaction. That's where the "what if's" come in.

Just like all those cascade failures that happen when fetching information from a database. There's no error when the request works, because the actual success notice is the display of the information. But if the fetch request fails...everything function, string, variable etc. based on the success of that request fails! Cascading downward. The simple answer, check if the request failed first. If so notify user there was a problem and you're looking into it, but email any errors to your self or the development team. If successful simply display results.


Tip: php variables begin with "$" but javascript variables can too.

 

This is very similar to what I'm saying and I agree with this

 

ABSOLUTELY NOT.
Note that I wrote this earlier:

I'm sorry, maybe I was not clear enough but we are basically saying the same thing at this point.