Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About garyed

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  1. Thanks for the ideas, I'll look into them & see if it would be more practical than what i was doing to get rid of the errors. I started thinking that even though everything is working fine now, that down the road when my web host changes to another version of PHP or anything in their settings that I have no control over, those errors could come back & bite me. So I think you guys are right that I should take the time to clean the code up now & not just leave it alone because it's working. I'm in the HVAC business & a lot of times you can get something working temporarily even though it's not right. If you don't go back with the right part or whatever it takes to get it right then down the road it causes a problem. I'm starting to look at my php code the same way, that it needs to be error free or it can hurt you in the future. Thanks again to everyone for the advice
  2. You are absolutely correct. All the errors I'm getting is from using empty strings in my calculations. I started fixing them by putting some of them in an array & then using array_sum which gets rid of the errors when empty strings are added together. Also zeroing out some worked too depending on the calculation but there are so many to do it was getting a little frustrating. I wanted to see if it was feasible to just not show the errors & by doing so everything is working just fine. Since the only errors are from using empty strings, I'm really just trying to find out what the down side is to using an empty string in a calculation other than displaying the error. I am already totally convinced that it is wrong to do but I'm just not convinced of the necessity to fix anything if its working.
  3. The problem is that I don't have any fires that I know of. The same code has been running smoothly for quite a few years. If I was having problems then it would make more sense to me. I may end up changing the code to get rid of the errors anyways but what harm does it do to have a non numeric value that is not being used? That's my question & if I hear a good reason to get rid of those non numeric values that wopuld help me make up my mind. I just don't want to throw in 50 or 100 if statements & arrays that don't help anything except keep errors from being displayed when i can accomplish the same thing with two words in an ini file. I'll know better in the future to be more careful with unused fields but I don't want to rewrite something that's already working & not get any better results..
  4. I found the answer & it was pretty simple. All i had to do was add the line "display_errors = Off" in php.ini & everything works just fine. Now I have to decide if I really want to do the work to correct all those non-numerical values or not. Other than not being notified of errors, does anyone see it causing a problem with functionality?
  5. If I didn't have so many errors I would agree but after spending an hour or two fixing some of those errors & seeing how long it was going to take to fix all of them I figured there's got to be an easier way. The program has been running fine for years on the same server & what is being called errors now have never had any effect on the functionality. I'm not saying it's the right way or the best way but I just don't see a need to fix anything if I can just get rid of the messages. Remember the error messages only appear when I add a two line php.ini file to the server to extend the session time. So I'm assuming it has just as much to do with the .ini file than the coding. It also runs fine on my server & I'm running PHP 7.2.24 where my web host is running PHP 7.2.33 so I assume there is a way to do something in the ini file. I just don't want to spend a couple days fixing errors for no reason if I can fix everything with a single line.
  6. Is there any way to disable the "A non-numeric value encountered" warning in the php.ini file? I don't get that warning on my Apache server but I do when I use the same code on my web host's server. I never got the warning until I uploaded a two line php.ini file to my web host so that I could keep my sessions longer than the default 24 minutes. This is the same online program related to my earlier post about too many inputs. I wanted to try sessions for a 24 hr. period but I'm getting tons of errors for any field that is not used which can be in the hundreds. If I delete my php.ini file from my web host & just let things default to whatever they are using then I don't get those errors,
  7. Very interesting. That seems like something to look into but I do move at a pretty slow pace. I really do appreciate the ideas.
  8. I started the project about seven years ago so I have been learning as i go. I may not have known how to put the state & cities on the same page at the time but that might be a good idea to cut it down to three pages instead of four. I know i wanted the last page & the page before it on separate pages. I didn't want things to look cluttered. The last page is going to have up to 20 rooms instead of just the one you see, so I wouldn't want anything else on it.
  9. Why don't I just give you guys a link to my site so it will be a little clearer what i'm doing. It's a load calculation program for home Heating & AC systems. https://www.loadcalc.net That site runs off a default 24 minute session & none of the data entered is anything I have any interest in at all. Now imagine that instead of calculating one room , doing 15 or 20 rooms the same way. That's what I'm working on. It can take some time do a full load calculation & almost the same amount of data needs to be entered into every separate room. I think I'm going to try keeping sessions but set my session.gc_maxlifetime to a higher number & see how things work out.
  10. I guess so, I have a basic shared server hosting package that includes (supposedly) unlimited mysql databases. I have heard that if you use more than expected whether it be traffic or load on the databases, that most web hosts will make you go to a private server.
  11. I guess I'm kinda stuck because all the things I need to do to make a session act similar to a cookie is going to put a lot more load on the server than I wanted to. I just don't know if I have any other options. I was hoping there was something I'm not aware of since i'm not very good at this stuff. I just learn as I go & I didn't even know that browsers had a limitation on cookies until after almost finishing my program. I do appreciate you telling me like it is, so I can get out of dreamland & face reality.
  12. I guess I can use sessions but I'm on a shared server & I don't know if it will be too much for my web hosting package. Also the problem with sessions is the user loses everything once they close their browser.
  13. I'm working on an online php program that can have a few hundred form inputs. Mainly just numbers from 1 to 50,000 depending on the field. I wanted to use cookies so the user can keep the data entered on their browser but i found out the hard way that the browsers have a limitation that I've exceeded. Does anyone have any ideas?
  14. Maybe what I'm trying to do can't be done in php but I would think it could be done. All I'm trying to do is be alerted in some way on my computer which is the Apache server, whenever someone accesses a particular web page on that server. Whether it's playing a wav file or sending a pop up on the screen it doesn't matter as long as it shows up on my computer. So far everything I've been able to do only creates an action on the client's computer that is accessing the web page but I can't get the client to create an action on the server(my computer).
  15. I actually tried all the steps you mentioned. I issued the same command I used in the exec() command on the php page through the terminal & the .wav file plays perfectly. I even echoed the " ls -l" command in the php file & got the correct results to make sure the path worked to the .wav file.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.