0

I migrated to godaddy for a perma-host. Now much of my code is not working. For years I have used the following code in my gaming site. but now I want to move it to a more permanent host. I've been using php v5 with no issues, never had a reason to change. However I did finally migrate to PDO. With that said, here is the .ini file I use:(keep in mind, it is a giagantic ini file, but the following are what is important that is NOT working..

SQL_TYPE=mysql
HOST=localhost
USER=incognito
PASS=topsecret
DATABASE=mycooldb

to pull it for defines:

$defines = parse_ini_file('defines.ini');
    foreach($defines as $field=>$data)
        define($field, $data);

Now there is an error when I use godaddy (which i believe is up to v7 php). If I run

die('host = '.HOST) // gives HOST

On my local server

die('host = '.HOST) // gives localhost - as it should

Why is this happening? I supposed I could line by line the defines, but they have worked for years the way I have it.

Thanks for any input.

Charlie Macintyre
  • 13
  • 2
  • 3
    Anything reproducible or some example? Ensure the values correct? – Script47 Sep 30 '17 at 22:01
  • 1
    What do you get if you do `var_dump($defines);`? Have you checked the error log to see if there are any errors? – Magnus Eriksson Sep 30 '17 at 22:12
  • pretty sure your ini file is not parsed at all on your web host, for some reason we can't guess by just the code you posted here. Add a lot of `var_dump()`s to confirm and check the errors carefully to spot the problem. – Calimero Sep 30 '17 at 22:14
  • I called up godaddy, we changed the version to 5.6 and all worked fine. Then as a test we put it back to 7.0 and 7.1, and it went blank again. So I will leave this comment as is in hopes that someone can point out the difference. Neither of us could figure out why it would not read. I personally would like to find out why, as eventually 5.6 will fade way. (sorta like Mysql to PDO/MySqli. Thanks! – Charlie Macintyre Sep 30 '17 at 22:43
  • @MagnusEriksson, the dumps come up blank screen. Even if you check the page source, it is blank as well. – Charlie Macintyre Sep 30 '17 at 22:49
  • 1
    That's a typical "White screen of death" that happens when there are some errors on the page and you have display errors disabled. If you have access to the servers error logm check it. A good idea is also to turn `display_errors` on in your local PHP environment. Read more here: [How do I get PHP errors to display?](http://stackoverflow.com/questions/1053424/how-do-i-get-php-errors-to-display) – Magnus Eriksson Sep 30 '17 at 22:51
  • OK that cleared a few things, for instances - the ini files no longer accepts "#" for comments, it now uses ";". I put it back to v7 and its (sorta) working, but now there is a lot of "localhost" text all over the place, but no more errors. Not sure why this code is still not working on a remote server, but fine on my home server. Any idea why I see things like "localhostlocalhostlocalhostlocalhostlocalhostlocalhost" (for a slider for example) but the code has no reference to localhost anywhere. I used to be able to up load my code to godaddy, and POOF everything works fine, – Charlie Macintyre Sep 30 '17 at 23:31

1 Answers1

0

Since it appears I have 2 problems, I will answer what addresses my first issue for this topic and close it:

There was not a problem with the DEFINES, but instead, my .ini files that stored the information for the variables that create the DEFINES.

In this ini file, I originally had "#" for comments as was accepted at the time, (which was what I was used to see: https://en.wikipedia.org/wiki/INI_file#Format) However, not catching some of the "depreciation errors" I got over the years from PHP v5.3 - as I was stubborn changing - "#" was among those warnings. When PHP 7 finally came, the "#" no longer worked as comments, and thus my DEFINES variable ceased to work, as the script was stuck at the first commented line.

Conclusion: As far as my error, there is NO difference in the defines between PHP: v7 and v5, however the use of "#" as comments caused the error. Thank you @Magnus Eriksson and @Calimero for the tip to display errors to catch it.

Charlie Macintyre
  • 13
  • 2