I recently installed:

  • RedHat Linux 7.1
  • PHP 4.2.2 (this was installed from source, using the install script, not by RPM)
  • thttpd-2.21b
  • IRCG-2.7
  • st-1.3

using the IRCG install script at:

http://schumann.cx/ircg/install_ircg.sh

I immediately noted an issue with not being able to receive posted data (via HTTP POST). I have reason to believe the solution may be in a "global variables" setting in PHP.INI, only I no longer know where to find it (it's normally under "/etc/php.ini"). There seem to be several others in various locations and I can't tell which is being used.

Can anyone tell me where it would be located under the installatin described above? Or what it would be named, if different from "php.ini"...

Thanks in advance.

    Also save the following as a info.php and run it:

    <?php
    phpinfo();
    ?>
    

    ;

    The location that PHP is looking for the .ini will be somewhere near the top of the page. If there's no file there, copy the default .ini (should be in the php source directory somwhere) to that location.

      You da' man! That was exactly what I was looking for. I just have one more problem I could use your help with.

      When I used phpinfo(), I saw, as expected that register_globals was set to "off". This is the root of my data-passing problems. When I checked the path of the php.ini file (given in phpinfo), it pointed to a directory that had no file named "php.ini" in it (or anything close). Just a lot of "libst" files.

      Do I need to add a php.ini file and then edit it? Any additional help finding the file would be greatly appreciated.

        Yeah, there should be a php.ini file in the original PHP source directory, just copy that across and edit it.

          Have you tried accessing your form data using $GET[whatever] or $POST[whatever]?

            Yes, I am able to access everything using the $POST, $SESSION approach, and that works fine. The only problem is that I have code that uses the other approach and it's more difficult to keep editing it than make the change. I know the security implications. but it's ok in this instance.

            I also tried editing the php.ini file and placing where the phpinfo told me it should be and restarting thttpd. It didn't work.

            Any thoughts?

              In the php.ini, edit this variable register_globals to On mode. By default it will in Off mode. So whenever there is a submit form, or session. When is on, we can get teh form variable via $formfiledvalue.

              Last time I think this register_globals is always On, don't know since when it become Off in newer PHP version.

              I also encounter the same problem recently and get the answer from here. Thanks buddies..

              😃

              Louis

                Thank you. Enterume, I am already aware of the setting you're talking about and I know, from viewing phpinfo(), that it is currently set to "Off". My question is where the file php.ini can be found in my particular installation (Please refer to the posts above for details).

                Under normal circumstances, with an installation of PHP under Apache, I would know where the file is and be able to edit it (after restarting the Apache daemon, it would be set to "On"). My challenge now is to find php.ini (or its equivalent) under my installation of HTTPD.

                Do you know where it is?

                Please help. I'm having no luck so far.

                  Hi Masser,

                  Normally what I do is, after compile the php with the binary source, I copy the php.ini-dist from the tar folder, to /usr/local/lib/php.ini . So everytime if you want to change your php setting, just edit this file /usr/local/lib/php.ini, and restart the apache, it will work with your new php setting.

                  Hope it help.

                  Thanks
                  Louis

                    Thank you. I tried using that file vefore and placing it in the directory that phpinfo() told me was the path of php.ini (then restarting thttpd), but it didn't work.

                    Apparently, I wasn't actually restarting the daemon properly, because this time it worked. Thanks to all who helped.

                      Write a Reply...