PFMaBiSmAd

See this post - http://www.phpfreaks.com/forums/index.php?topic=332561.msg1565865#msg1565865

For each page of code...

You already have a query in your login code that gets the firstname from the database when there is a successful login. Use that information instead of executing an additional query. Also, session_register() was depreciated 9 years ago, finally throws a depreciated error message in php5.3, and is scheduled to be completely removed in the next major php version release. You are already setting and referencing $_SESSION variables in your code (the proper way to set and reference session variables), how did you come up with code that uses session_register?

Let me guess, you replaced your whole query statement - UPDATE thatsact_tag_clan.tag_user SET membergroupids='11' WHERE username='$vbid'; with the short fragment I posted showing how you would use CONCAT to set the membergroupids value?

id's in html are only used in the browser and have nothing to do with php.

You didn't show us the whole code for the page where you tried to "ECHO the already declared session variable".

For your existing scheme of storing a comma separated list in a field, you would use the mysql CONCAT() function in your query to concatenate the new value onto the end of the existing list. SET membergroupids=CONCAT(membergroupids, ',11') However, storing a comma separated list in a field is not efficient for finding information in and you should store this information using a table with a separate row for each value for each id that it belongs to. user_id group_id 1 1 1 2 1 3 1 11 22 4 22 11 91 5 91 6

Before the form is submitted, the $_POST variables do not exist. Use isset to test variables that might not exist - if(isset($_POST["submit"])){ You should also have the error_reporting/display_errors settings right after the first opening <?php tags so that any errors produced by any of your code will be reported and displayed. Actually, you should set the error_reporting/display_errors settings in your master php.ini so that fatal parse errors will also be reported and displayed. Then you won't need to remember to put the lines into your files during development and remember to remove them when you put your code onto a live server.

Actually, I have about the same question that phppaper's code would show. Is the header() redirect going to the thispage.php url (without the ?action=increase on the end of it)? What exactly do you see in front of you after you submit the form, but before you refresh the page? Is is a blank page or is it the form/submit button?

Have you successfully used session variables at all on the server? I suspect that either sessions don't work at all or that you have a header/session_start error on the second page. You might also be redirecting between urls that have and don't have www. on them and the session id cookie doesn't match the url of the second page and isn't being sent to the server so that the session doesn't exist on that page. Are you developing and debugging your code on a system with error_reporting set to E_ALL and display_errors set to ON so that all the php detected errors will be reported and displayed? The three possibilities I just mentioned would result in php errors that would help determine why your code is not working (assuming that output_buffering is not turned on as well so that the error messages won't show when you do a redirect.)

Assuming the code you posted is what you want to do - <?php $j = 0; while($row2 = mysqli_fetch_array ( $pollAnswersResult, MYSQL_ASSOC )) { $j++; echo "<div class='field required answers'> <label for='answer{$j}'>Answer #{$j}</label> <input type='text' class='text' name='answer{$j}' id='answer{$j}' title='Answer $j' value='{$row2['answer']}'/> <span class='required-icon tooltip' title='Required field - This field is required, it cannot be blank, and must contain something that is different from emptyness in order to be filled in. '>Required</span> </div>"; } ?>

The problem causing the error is that there are no $ on the $j variables. I think if you would not write your code using so many opening and closing php tags that it would be easier for you to see problems like this. You will also find that logically your code does not output what you expect. You would only want to increment $j once per loop so that your HTML inside the loop uses one value for the duration of each pass through the loop.

You could also put the array inline in the statement for a small number of choices - if ($row['CustomerSaas'] == 'Yes' && in_array($row['CustomerSaasPaidStatus'], array('Trial','Trial Ended'))) { Given that these values are probably coming from a query, you can probably accomplish the same by putting the conditions into a WHERE clause in the query so that only rows that match those conditions are returned by the query.

There is no such thing for logic operators (you are logically or'ing the string 'Trial' with 'Trial Ended' which produces a bool(true) if I am not mistaken and then testing if your variable is equal to a bool(true).) However, if you have one variable that you want to test if it is one of several values, you would make an array of the values and use in_array

mysql_result can be used to fetch a single value.

You are making this about four times harder than it is -

No need to loop - $_POST = array_map('mysql_real_escape_string',$_POST); If any of your form fields are arrays, you will either need to write your own recursive function to use as the first parameter in the array_map() statement or you will need to write a simple function that uses mysql_real_escape_string on each piece of data it is passed to use with array_walk_recursive

You can do this all as part of your query - SELECT DATEDIFF(DATE_ADD(CustomerSaasDateStarted, INTERVAL 60 DAY),CURDATE()) as days_remaining A negative value would indicate the current date is past the end of the trial. A positive value would indicate the trial is still in effect.

Is there some reason you are bumping a thread for Andy17?

You (always) need to test in your code if a query worked or not and in the case of an UPDATE (or INSERT) query, you should always test if the row was actually updated. Also, you should (always) form your query in a variable so that you can make use of the actual query in your error handling logic that you need to have in your code (always.) Typical code an UPDATE (and INSERT) query - <?php $query = "...your_query_statement_here..."; // form your query statement in a variable (allows using the actual query statement in your error handling logic) // execute the query and test the returned value if(mysql_query($query)){ // A TRUE was returned, the query executed without any errors. // test the number of row(s) affected by the query if(mysql_affected_rows()){ // one or more row(s) where affected by the query // the query was successful and affected one or more rows in the database table ...your_code_for_when_the_UPDATE_actually_worked... echo "Row was UPDATED"; } else { // no row was affected // the UPDATE either did not match any row (the WHERE clause was false) or did not update any of the data in the row (same data values) echo "Row NOT updated"; } } else { // A FALSE value was returned, the query failed, handle the error here... $user_message = "some user/visitor message"; $application_message = "Query failed: $query, Error: " . mysql_error(); // add other relavant information such as current file, line number, current visitor information, backtrace info,... echo $user_massage; // cause the user message to be output or returned, ... as needed to get it to be sent to the browser trigger_error($application_message); // Use php's error handling to display (during development) and/or log the application error message } If you use code like above, you will know what your query is doing and if you have error_reporting set to E_ALL and display_errors set to ON (you apparently don't because the problem that MasterACE14 pointed out would have resulted in some php errors) the trigger_error() statement will report and display the actual query and query error if the query is failing.

Variable variables take three times longer to execute, so they are a poor choice when there are other ways of accomplishing the same task. From the php.net documentation for what you are trying to do -

It's a safe bet that your code was not written over 9 years ago. Whoever wrote it should have been aware of this problem and should not have written code dependent on the setting. The reason I didn't mention the setting name is so you wouldn't be tempted to turn it on, since it is going to be removed in the next major php version release (should that ever occur.) You must eventually fix your code. Why not do that now so that your code will work on any server? For a link like page.php?mode=script, you would use $_GET['mode'] in your code to reference the value. $mode = $_GET['mode']; // set the program variable $mode from the GET parameter on the end of the url

You are making this harder than needed. Each language file should use the same array name so that after you include the correct language file, you don't need to do anything else in your code. In the en.php file you would have - $lang['mail']['letter closing'] = "regards,\n your friend!"; In the spanish.php file you would have - $lang['mail']['letter closing'] = "lo que se refiere,\n su amigo!" You would always reference $lang['mail']['letter closing'] in your code to access the correct phrase for the language file that was included.

Yes, php.net put in some brilliant lazy-way short-cuts in the early versions of php that proved brilliant (several provided security holes that hackers can use) and they have just about all been turned off by default, the setting that is likely causing your problem was turned off 9 years ago, so that they can eventually be removed from the language. However, a lot of web hosting and php programmers never updated their settings and code to match the recommendations from php.net. Your code likely thinks that program variables, i.e $var, will magically get set from the actual $_GET, $_POST, $_COOKIE, $_FILES, $_SESSION, $_SERVER, and $_ENV variable where the data is at. You need to either add code to set your program variables from the correct $_GET, $_POST, $_COOKIE, $_FILES, $_SESSION, $_SERVER, and $_ENV variables where the data is coming from or you need to use the actual $_GET, $_POST, $_COOKIE, $_FILES, $_SESSION, $_SERVER, and $_ENV variables in your code. If your form is using the POST method, your form data will be available in $_POST variables. In the case of your GET parameters on the end of the URLs, the data will be available in $_GET variables.

Wouldn't that mean that the header() IS working, but that there is a problem with the code responsible for either setting or displaying the data? You haven't posted any information telling us what IT is that didn't work (code and data.) For anyone one here to be able to help you with the problem, you would need to post enough of your code that demonstrates and reproduces the problem along with telling us exactly what data values are not always refreshed.