Any idea why this would stop working? Do you need more information from me to fix this? I assume it’s a simple fix (I already had to fix a few other things) but just not sure here.
Agreed, and a copy of the DB in SQL (small sample) so we can setup and see whats happening might help.
I removed the queries to check and commented some stuff, the person name is picked up so the POST is working. I have a hunch that your not collecting the user to edit after the form is first submitted. But I can’t check without seeing the whole code and seeing the DB.
I added error_reporting(E_ALL); to the top of the page, but nothing displayed.
I tried switching
* from ".CLIENT." where
to
* from CLIENT where
but again no luck.
How can I go about getting a sample of the database that you need without exposing the data within (don’t want to include actual person’s data)?
And when I said “simplified” all I did was take out some of the form fields from the HTML. Didn’t edit the PHP code at all. There are some additional variables that aren’t being pulled in addition to varResName (varEmail1, varEmail2, etc.).
The “CLIENT” is a constant, so leave that as it was. It most probably contain the name of the table with a prefix as mentioned above.
I saw this variable: $sessionadminId and it makes me wonder if the script uses the deprecated function “session_register()” instead of accessing the session array through $_SESSION. So check how that variable is set, and if it is indeed a session you need to change it to the new system to use sessions.
In addition check if register_globals are turned on or off, if its off try to turn it on and see if it works then. If it works, it means you got a problem with POST, GET, COOKIE, SESSION variables being used as a plain variable.
Yes, session_register() was being used, but I already caught that. In my first round of edits to the script I changed a bunch of files to the new $_SESSION.
register_globals is off. My first idea was to turn them on so I wouldn’t have to edit any of the script, but that doesn’t appear to be an option at this point (hosting restrictions). Thanks for taking a look.
What you need to do is manually go over every file of the script and fix the references that rely on register global, if you look at this file just by taking another look I can see that these variables are never set before they are used:
$sessionadminId
$email1
$varemail1
$boss1
Not to mention that the script is wide open for SQL injection. So you should make certain that all the values inserted into the database is either cast to int or wrapped with mysql_real_escape_string().
With other words, you have a few hours with work ahead of you doing normal “search and replace” tasks to fix the script to be able to work without register_globals turned on
It looks like you are catching the errors but they are not being displayed which accounts for the blank page.
Try this:
<?php
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
$i2= hockeykid(' if the function does_not_exist then an error will be shown');
# Also maybe set default $_POST values:
if(!empty($_POST['submit']))
{
$status = 'Active';
$intResId = isset($_POST['intResId']) ? $_POST['intResId'] : 'intResId NOT SET';
# repeat for remaining $_POST items
?>
Hmmm. Don’t take this the wrong way but I don’t think this is quite accurate. The code you posted does not show any include files so there is no place where CLIENT can be defined neither is there a place where your mysql connection can be set or where sessionadminId could be set . It could not possibly have worked under PHP4 unless your php.ini file was setup to automatically include a file on each request which seems unlikely on a shared host.
Are you sure you are looking at the correct file? I have seen plenty of projects where there are a gazillion files many of which are not used. How many files are we talking about here? If it is a big app then you should probably take the time to setup a local development machine and maybe use a source code control system. Otherwise, you may end up chasing your tail for a long long time.
While considered ‘bad practise’ as it leads to this type of lack of clarity, perhaps the files shown is included into another page that sets the constant value prior to the inclusion?
See if it runs. If it does, your problem is the older script is expecting the post variables to be registered into the global scope - similar to calling extrace($_REQUEST) at the start of the file. (The reason this might work is register_globals is turned off by default in PHP 5)
DO NOT LEAVE THE CODE IN THIS STATE. That setting was deprecated, with good reason, as of PHP 4.3. It has been removed in PHP 5.4 and the script will not run under PHP 5.4 until you go in, find all the references to the variables that are expected to be global and edit them (this could take awhile for a large program).
Again, I’d like to thank everyone for their input. As I said, just trying to fix up someone else’s mess without enough knowledge to do so.
By adding php_flag register_globals on to my site’s .htaccess file I was able to get this page to work. What exactly do I need to change throughout the script in order to ensure it works without leaving register_globals on?
I do have access to edit the .htaccess but I think for security-sake and future considerations I’d like to know how to edit the script to work with register_globals off. Thanks.
I do think that this is a good start on your part. This actually happened to me a while back too, but i changed hosts, then all of a sudden things didnt work. It’s what brought me to this thread infact
But all you really need to wrap your head around in this regard, is that you need to define each variable as it is… ie
