hide errors on version upgrade

[garyed]

My webhost has upgraded from php 7.4 to 8.0 & I have quite a few pages on different sites that just will not work with the upgrade. 

 I've been masking all my errors in 7.4 by using "display_errors = Off " in my php.ini & that's done the job until now but the pages will not work in 8.0 

I guess all the bad code is catching up to me but we're talking about thousands of lines of code that I wrote years ago & it's going to take a long time to correct.

I don't want my sites to be down so I'm paying a monthly fee to my webhost (1and1) to keep supporting php7.4 & I don't know how long that will last.

I've also tried putting this in my pages to no avail:       

error_reporting(E_ALL ^ E_NOTICE);

I'm just trying to buy time until I can get things right so I'm wondering if anyone has any ideas for me in the mean time.

I do test all my new code for errors as I'm going along but all my old code was never tested for errors. 

This reminds me of what I was told about people who use computers a while back. There are two types, those who backup & those who will backup

[requinix]

What errors? What's not working? 7.4 to 8.0 wasn't a huge upgrade but there were a number of breaking changes...

[mac_gyver]

is there an actual question in this?

[garyed]

I've got about a thousand of them :

Undefined array key ... 

Trying to access array offset on value of type null
 mysqli_real_escape_string(): Passing null to parameter #2 ($string) of type string is deprecated 
Undefined variable ....
Fatal error: Uncaught TypeError: Unsupported operand types: 

Then it gets even worse because all of those errors can go away by turning off errors but then when you go further into the site it will lock up completely & go blank.

If I keep the errors turned on then I can't get to the part of the site where it locks up to see what error is causing the lockup. 

It's actually a very involved load calculation sight with a lot of inputs & a lot of people use it & I want to keep it going.  

[garyed]

2 minutes ago, mac_gyver said:

is there an actual question in this?

Yes, since my site works under php 7.4 by turning off errors, is there a stronger way to turn off errors that might allow it to still work under php 8.0?  

[requinix]

23 minutes ago, garyed said:

Yes, since my site works under php 7.4 by turning off errors,

Your site does not work by turning off errors. The problems are there and need to be fixed regardless of whether you can see error messages about it or not.

The only thing that the PHP 8 upgrade did was change error display settings. These problems, like "trying to access array offset on value of type null" and "undefined variable", have been there for a while. You just didn't know about it until now.

Frankly, "thousands of lines of code" is not that much. Each error message tells you where the problem is - all you have to do is go to the code on that line and, most likely, make a small change.

[garyed]

35 minutes ago, requinix said:

Your site does not work by turning off errors. The problems are there and need to be fixed regardless of whether you can see error messages about it or not.

The only thing that the PHP 8 upgrade did was change error display settings. These problems, like "trying to access array offset on value of type null" and "undefined variable", have been there for a while. You just didn't know about it until now.

Frankly, "thousands of lines of code" is not that much. Each error message tells you where the problem is - all you have to do is go to the code on that line and, most likely, make a small change.

I understand what you're saying & I definitely want to straighten the code out & get rid of all the errors properly. 

I had the same problem about a year ago,when my webhost upgraded the php version to 7.4. 

I turned off the errors to keep the site up & running & started trying to fix things but I just gave up after a couple days. 

I got lazy since everything was still working & just forgot about doing anything about the errors.

I should have fixed things while I had the time but now I'm paying the price for procrastinating.

 

[ginerjm]

How do you think I feel?  I haven't had to use my site since Covid and now I am and finding a whole bunch of errors that I have to fix to be able to run the app.  Including some plain old JS xmlhttrequest that don't work anymore.  I don't even remember why I have them!

[maxxd]

garyed - honestly, it's not as bad as it could be. I first read your post and assumed you were still using the mysql_* functions, at which point you'd be kinda hosed. From your posted error messages, it seems like that's not the case so that's awesome. As requinix said, you're gonna have to just work through it - the nice thing is it doesn't sound like you'll have to completely rewrite most if not all of your code. There were several things that moved up from notice between 7.4 and 8.0; it's just going to be a case of finding those and making sure they don't throw errors.

[garyed]

Thanks for the encouragement, 

I know I'll get it done but it's just going to take time. I just do this as a hobby & the code on the site in question I wrote about 10 years ago. When you don't do it everyday, it's easy to forget how you did something that far back.  

 I was just hoping I could fool php8.0 like i did 7.2 for a little while longer  

[garyed]

Follow up with code:

I didn't know if i should post this as a separate thread or not since the question is about fixing errors instead of covering them up.

I'm trying to figure out how to get rid of the errors in this code because it's very similar to my site with a lot more inputs & I'm stumped.

 

<!DOCTYPE html>
<html>
<head> </head>
<body>
<?php 
error_reporting(E_ALL);
ini_set('display_errors', '1');
session_start(); // Starts session & uses function to keep data  */
function get_value($var)
{
// this will check your session if it's not empty and you send an empty post
if ($_POST[$var]!="" || (!empty($_SESSION[$var]) && $_POST[$var] === '')) { 
   $_SESSION[$var]=$_POST[$var];   }
if (isset($_SESSION[$var])){ return $_SESSION[$var];}else{ return $_POST[$var];} 
}
?>
<form name="test" action="" method="post"> 
<input type="text" style="width:255px;" name="owner" value="<?php echo get_value('owner'); ?> "> <br>
<input type="submit" value="submit"> &nbsp; &nbsp; <input name="submitter" type="submit" value="clear session"><br>
</form>
<?php
if ($_POST['submitter']=="clear session") { session_destroy(); }
print_r($_SESSION);
?>
</body>
</html>

 

[mac_gyver]

code for any page should be laid out in this general order -

1. initialization.
2. post method form processing.
3. get method business logic - get/produce data needed to display the page.
4. html document.

the post method form processing should -

1. detect if a post method form has been submitted before referencing any of the form data.
2. keep the form data as a set in a php array variable, then operate on elements in this array variable throughout the rest of the code.
3. trim all the input data, mainly so that you can detect if it consists of all white-space characters.
4. validate inputs, storing validation errors in an array using the field name as the array index.
5. after the end of the validation logic, if there are no errors, use the form data.
6. after using the form data, if there are no errors, perform a redirect to the exact same url of the current page to cause a get request for that page.
7. any redirect needs an exit/die statement after it to stop code execution.
8. to display a one-time success message, store it in a session variable, then test, display, and clear the session variable at the appropriate location in the html document.
9. if there are errors at step #5 or #6 on this list, the code would continue on to display the html document, where you would display any errors and redisplay the form, populating the form field values with any existing data.
10. since there won't be any existing data values the first time the form is displayed, you need to address this at the point of using the values in the form. php's null coalescing operator ?? is a good choice to use here.
11. any external, dynamic, unknown value output in a html context should have htmlentities() applied to it to help prevent cross site scripting.

once you have detected that a post method form has been submitted, except for unchecked checkbox/radio fields, all form fields will be set and won't produce php errors. for checkbox/radio fields, you need to use isset() statements to test if they are set before referencing them in the form processing code. since the posted code isn't detecting if a post method form has been submitted at all before referencing the form data and isn't doing anything for item #10 on this list, you are getting unnecessary php errors.

btw - if you have more than 2-3 form fields, you should use a data-driven design, where you have a data structure (database table,  array) that defines the expected form fields, validation rules, and processing for each field, then dynamically validate and process the form data, rather than to write out bespoke logic for each field.

[garyed]

Thanks for the ideas, 

I can get rid of the errors by initiating $_POST['submitter'] & testing if $_POST['owner'] is initiated but then my session variable gets lost when leaving the page. 

Keeping the session variable is where my problem is.

if(!isset($_POST['submitter'])) {$_POST['submitter']="hello"; } // insert before using $_POST['submitter']
// change value of input to this:
value="<?php if(isset($_POST['owner'])) {echo get_value('owner'); }?> " 

The session variable is really not lost but it doesn't appear in the input field after leaving the page & coming back to it which is the problem especially if I'm dealing with a lot of inputs.  

 

Edited November 13, 2022 by garyed

[garyed]

This seems like a hard way to do it but it looks like it works OK.   Any suggestions ?

value="<?php if(isset($_POST['owner'])) {echo get_value('owner'); } else { if(isset($_SESSION['owner'])){ echo $_SESSION['owner'];} }  ?> "

 

[phppup]

I'm not exactly sure of your question, but I know that getting help can sometimes be tough on the weekend, so I'll try.

Ahhhh, you posted as I'm typing.

If this solved your problem, then good.

Personally, I've had issues with ISSET and prefer something like

if($_SESSION['owner'] != "")

In this case, it does not become active alongside your validation if a required field is left empty.

[Barand]

16 minutes ago, phppup said:

Personally, I've had issues with ISSET and prefer something like

if($_SESSION['owner'] != "")

 

@phppup if you think that code is a substitute for isset(), then it's time to RTFM again

[phppup]

@Barand I think I'm more concerned that I deciphered RTFM so quickly. LMAO

But I've found that empty inputs are SET as such, and can trip up the intentions of my code.

Checking for NOT BLANK seems more effective.

Am I mistaking something here?

Edited November 13, 2022 by phppup
Typos

[maxxd]

A variable not being set and being empty are two completely different things. You'll get errors checking for $_SESSION['owner'] == '' if the 'owner' index of the $_SESSION array isn't set (doesn't exist at all). So technically you should be checking with isset() and testing for empty; personally I have a tendency to use the empty(), but it's important to realize that this function comes with its own baggage. For instance, a false-y value will return true from empty(), so you'll need to plan for that as well.

[garyed]

 I thought about marking this thread as solved but I would be lying because I still am in the process of trying to solve all my errors. 

It seems rather ridiculous that one version of php will work with errors turned off while a newer version won't. 

I've already fixed over a hundred errors in php 8.x & things are looking worse than before I started. 

I can go back to php 7.4 & the program will work flawlessly. If it's not an undefined variable error, it's a  string & int error or something else. 

It's frustrating because I spent years writing this program & just learned as I was going along.  It's been working fine for 10 years & now the upgrade to php 8.x has killed it.   

I've got over 1000 variables I'm dealing with & hundreds of calculations so it's not a simple task.  

 

[mac_gyver]

it would probably be better if you continued any posting about this subject in the Nov 15th thread -  https://forums.phpfreaks.com/topic/315539-is-anything-wrong-with-this-code/ that came after the last Nov 13th post above.

the outline of code for the form/form processing that i gave in that thread produces no errors when it runs. this should have eliminated much of the work of getting to the point of having all the input data ready to use in the calculations.

i also see though looking at your previous threads that several of the suggestions recently given were previously given but never used.