Jump to content

PHP Select


ohboyatoytruck

Recommended Posts

The following code is about 10 years old and has worked perfectly until recently. Over the last 12 months the select has been producing a value of 1 instead of the value of $cost or $membercost. However it only happens intermittently: 26 times out of 3000 registrations to be exact.

 


One colleague has pointed out that $chosencost_1 is never declared which many be the issue. How can it be declared when it depends on the choice made by the select? $chosencost_1 is first declared on the page that follows the one with the web form.

What's most baffling is why has this code worked fine in the past and only recently become a problem? Could it be a browser/OS issue? Or a PHP version issue? We are using v5.5.27.

CODE

 

The following variables are passed from a previous page (cost, member cost):

 

$cost = '';

if (isset($_REQUEST['cost']) && is_numeric($_REQUEST['cost'])) {
    $cost = floatval($_REQUEST['cost']); 
}
 
$membercost = '';
if (isset($_REQUEST['membercost']) && is_numeric($_REQUEST['membercost'])) {
    $membercost = floatval($_REQUEST['membercost']); 
}
 
//etc etc there are many other cost options
 
On this page which contains a web form, browsers use an html select to choose a course cost:
 
<select name="choosecost1" size="1" value="">
     <option value=""></option>
     <?php if ($cost !='') { ?>
     <option value="<?php echo $cost; ?>" <?php if($chosencost_1 == $cost) echo 'selected="selected"'; ?>='<?php if($chosencost_1 == $cost) echo 'selected="selected"'; ?>'>Cost:<?php echo '$' . number_format($cost, 2 , '.' , ' '); ?></option>
     <?php } ?>
     <?php if ($membercost !='') { ?>
     <option value="<?php echo $membercost; ?>" <?php if($chosencost_1 == $membercost) echo 'selected="selected"'; ?>='<?php if($chosencost_1 == $membercost) echo 'selected="selected"'; ?>'>Cost to Members:<?php echo '$' . number_format($membercost, 2 , '.' , ' '); ?></option>
     <?php } ?>
 <!--etc etc there are lots of other options-->
</select>
 
choosecost1 is passed to the next page where it becomes $chosencost_1
 
eg $chosencost_1 = $_POST['choosecost1'];
 
 
Link to comment
Share on other sites

Firstly, given that this is an example of the html code generated by your script

<select name="choosecost1" size="1" value="">
     <option value=""></option>
     <option value="200" selected="selected" ='selected="selected" '="">Cost:$200.00</option>
     <option value="100" =''="">Cost to Members:$100.00</option>
</select> 

I am surprised it worked at all.

 

Secondly, php scripts each have their own individual scope. Defining a variable on page 2 does not define it for you on page 1.

 

The only thing I can think of, off the top of my head, is that it relied on register_globals being set (which was already obsolete 10 years ago)

Link to comment
Share on other sites

Where are you getting the data for the dropdown select?

 

The data is passed to the web form page from a previous page where the costs are found via a database search (FMFind) and then passed through the URL of the current page:

 

<form id="Register1" action="Registration_Form11.php?cost=<?php echo $show_found_courseData['Course_Cost'][0]; ?>&membercost=<?php echo $show_found_courseData['Course_Cost_Members'][0]; ?>" method="post" name="Register">

 

Which leads to:

 

$cost = '';

if (isset($_REQUEST['cost']) && is_numeric($_REQUEST['cost'])) {
    $cost = floatval($_REQUEST['cost']); 
}
 
$membercost = '';
if (isset($_REQUEST['membercost']) && is_numeric($_REQUEST['membercost'])) {
    $membercost = floatval($_REQUEST['membercost']); 
}
Link to comment
Share on other sites

Firstly, given that this is an example of the html code generated by your script

<select name="choosecost1" size="1" value="">
     <option value=""></option>
     <option value="200" selected="selected" ='selected="selected" '="">Cost:$200.00</option>
     <option value="100" =''="">Cost to Members:$100.00</option>
</select> 

I am surprised it worked at all.

 

Secondly, php scripts each have their own individual scope. Defining a variable on page 2 does not define it for you on page 1.

 

The only thing I can think of, off the top of my head, is that it relied on register_globals being set (which was already obsolete 10 years ago)

The code was written for us by a consultant and has worked for the most part until this year. I would be grateful if you could tell me how the code needs to be amended. Essentially I just need all cost options that have been passed to the web form to be integrated into the select.

Link to comment
Share on other sites

It has just occurred to me that that variable $chosencost_1 is being used to populate the select with previously selected data - that is if the form is not validated (which is determined by the page that follows the web form), the browser is returned to the previous page (e.g. the  webform) but any data that has already been entered or selected is displayed. So $chosencost_1 which is declared on the validation page, is being used to populate the select with whatever data was originally selected. 

However this means that issue of why the costs are reverting to $1.00 intermittently remains a mystery. 

Link to comment
Share on other sites

If you zip up all the code/files I will look at it. (everything I need to run it)

Thanks very much. I have attached the files but not included the related function files FX and PHPMailer which are used in conjunction with these files. 

 

http://www.iviking.org/FX.php/

https://github.com/PHPMailer/PHPMailer

 

The file sequence is:

 

Course_Details11.php

Registration_Form11.php

Check_Registration_Form11.php

Process_Registration11.php

Pay_by_Cheque11.php

Pay_by_Direct_Deposit11.php

registration files.zip

Link to comment
Share on other sites

Without EVERYTHING I need to run this, I cant properly help you. The files and the two downloads is not everything. You have a lot more problems than just the one you think you do. All I have is a screen FULL of errors.

 

There is LOTs and LOTs of work that should be done.

Edited by benanamen
Link to comment
Share on other sites

the most likely reason for the random failures of the code is probably due to different browsers handling markup errors differently. the html in the pages being produced needs to be valid to have a chance at working the same in all browsers/browser-versions.

 

what a mess. this code is long over due to be written from scratch, using general, data driven, DRY, programming. there's a ton of hard-coding (i even saw a 2015 year being used in a path that would need to be manually changed each new year, and i'm guessing this is what the 11 in the file names are there for, to distinguish different hard-coded instances of the site) and repetition of form/form-processing code between main and included files. of the 6800+ lines present in the .zip, there's probably only about 2000 lines needed to do this task.

Link to comment
Share on other sites

went through the code trying to figure out the program flow. here's some notes -

 

Course_Details11.php -

 

this page receives an id as an input, uses that id to retrieve and display the information for the course the id corresponds to. if the visitor chooses to register for the course, about 40 pieces of course information are passed to the next page as get parameters in the form's action='....' attribute. the only post data is the submit button.

 

 

Registration_Form11.php -

 

this page copies/validates/casts the data from the course_details page (18-19 items out of the 40 that are put into the url), puts this data (~11 items) into hidden form fields (without any html encoding, which may be why some form values don't work, if the values/upstream-values contain any quotes, breaking the html syntax), displays the user form fields, with any validation errors (see the check_registration_form notes next), and submits to the Check_Registration_Form11.php page.

 

 

Check_Registration_Form11.php -

 

this page copies/validates/casts ALL (hopefully, didn't bother to count the hard-coded line after line of code) the data from the registration form page. if there are validation errors, it includes the registration form page (which is a complete html document itself, giving two nested documents at this point) so that the form and any errors can be displayed. since there is no specific form processing conditional statement in any of this code, doing the include, causes all form processing/form display logic in the registration page to run again.

 

if there are no validation errors, some/all of the data is saved in a 'Online_Activity' database/table, but this isn't used by the code to save on passing data to the next step.

 

the user data is displayed as a conformation check and ALL the $_POST data (this time with html encoding, though not with all quote types encoded, which is amazing because the display section is using html encoding with all quote types encoded) is put into hidden form fields for the next page. to correct any data, you must use the browser's back button. this page submits to the process registration page.

 

 

Process_Registration11.php -

 

this page validates JUST the original course_details data (19 items). it doesn't validate the user entered data. it finally saves the data to a 'Web Registration Information' database/table. then sends some emails, and updates some more database information.

 

:facewall:

 

@ the OP, if this is something that is actually being used for registration at a school, and it is beyond your abilities to find and fix the problem among the wall of 6800+ lines of uncommented code, you should expect to hire someone to fix this for you, rather than to get free programming services on a programming help forum.

Edited by mac_gyver
Link to comment
Share on other sites

based on what i learned about the code, i finally figured out what the OP is referring to in this thread. this is the reason why you need to write applications without it taking a wall of repetitive code and why you need to put comments in your code to document what it is doing, so that anyone looking at the code can figure it out.

 

the select/option menu in question is letting the visitor select among the different costs, with the value='....' attribute being the actual cost. the missing $chosencost_1 variable is actually present, after the registration form has been submitted, because the form code is being included back into the Check_Registration_Form11.php page, which is where the $chosencost_1 variable is at.

 

the reason you are likely getting a 1 for a cost value, is because whoever/a-bot-script that is submitting the form, has figured out that you are using the submitted cost, so they are trying to get a $1 bargain on a course.

 

this code is completely flawed in how it is operating. the most direct fix would be to do the following -

 

1) only the course id, the value in $recid on the Course_Details page, should be submitted between steps (your course registration data structure should actually only store the course id, student id (the unique information about a student should be stored in a user/student table, not in the course registration table), and any unique information about each registration, but i doubt you are going to change your data to do it this way.)

 

2) any page that needs to use or display the course data should use the submitted $recid value (after validating it) to query for the course information on that page.

 

3) any cost section should use a type value that identifies a choice among the available different costs, not the actual cost value. the actual cost the code uses should take the submitted type and get the actual cost from wherever it is stored. you should also validate that the type that was submitted is available/valid for the user, using whatever rules you have. which begs the question - why is the user even picking what price he gets? shouldn't that be an administrative choice, not a user accessible choice?

 

4) you should pass a minimum of information between pages in the form and any information you do pass through a form must be validated at each step. you may want to consider using a session variable to hold an array of the validated data so that you don't need to re-validate the data at each step.

Edited by mac_gyver
Link to comment
Share on other sites

based on what i learned about the code, i finally figured out what the OP is referring to in this thread. this is the reason why you need to write applications without it taking a wall of repetitive code and why you need to put comments in your code to document what it is doing, so that anyone looking at the code can figure it out.

 

the select/option menu in question is letting the visitor select among the different costs, with the value='....' attribute being the actual cost. the missing $chosencost_1 variable is actually present, after the registration form has been submitted, because the form code is being included back into the Check_Registration_Form11.php page, which is where the $chosencost_1 variable is at.

 

the reason you are likely getting a 1 for a cost value, is because whoever/a-bot-script that is submitting the form, has figured out that you are using the submitted cost, so they are trying to get a $1 bargain on a course.

 

this code is completely flawed in how it is operating. the most direct fix would be to do the following -

 

1) only the course id, the value in $recid on the Course_Details page, should be submitted between steps (your course registration data structure should actually only store the course id, student id (the unique information about a student should be stored in a user/student table, not in the course registration table), and any unique information about each registration, but i doubt you are going to change your data to do it this way.)

 

2) any page that needs to use or display the course data should use the submitted $recid value (after validating it) to query for the course information on that page.

 

3) any cost section should use a type value that identifies a choice among the available different costs, not the actual cost value. the actual cost the code uses should take the submitted type and get the actual cost from wherever it is stored. you should also validate that the type that was submitted is available/valid for the user, using whatever rules you have. which begs the question - why is the user even picking what price he gets? shouldn't that be an administrative choice, not a user accessible choice?

 

4) you should pass a minimum of information between pages in the form and any information you do pass through a form must be validated at each step. you may want to consider using a session variable to hold an array of the validated data so that you don't need to re-validate the data at each step.

Thanks for your kind response. I am bringing a developer in this week to look at the code but I wanted to see how bad the problem was beforehand.

 

The company i represent is a charity/NGO and when we first developed this website in 2006 we had no budget and I cobbled together the registration system learning PHP as I went and getting the assistance of a series of consultants.

 

Thanks again.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • 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.