PFMaBiSmAd

Your question actually has nothing to do with session variables, it has to do with variable scope. When you use an include statement, the content of the included file virtually becomes part of the code at the point of the include statement and inherits any existing variables in the scope where the include statement is at. An include statement in your main program's scope inherits any existing variables in your main program's scope. An include statement in a function or class inherits any existing variables in the scope of that function or class.

Are you sure about the id form field value coming from $row_Numbers['id']? That doesn't match the other $row_Numbers field name format and it doesn't match the column name the submitted id is being compared against in the update query.

Based on the filename (index.php) in the attached error output, you are apparently trying to output the dynamic image on a html page. That doesn't work. The only thing you can output for the request for an image is the content-type header followed by the image data. The src="..." attribute in your <img tag must be to the .php file that outputs the dynamic image.

Just what exactly is it you are trying to secure against? If it's to prevent links that are submitted to your script from being click-able links, you succeeded. The link is no longer a problem because it isn't a link any more.

You would have category menu/links or a type-a-head search to limit the selections to a smaller set.

See the following thread on detecting a change in a value, closing out a previous section, and starting a new section as you iterate over the rows in your result set - http://forums.phpfreaks.com/topic/271047-loop-throught-sql-results-and-dont-print-repeated-data/#entry1394613 You would detect a change in the date.

^^^ An admin for only a few minutes and cannot see the humor anymore

The post I made above that shows the change for the form field name. To iterate over the submitted data - foreach($_POST['mark'] as $id=>$value){ // $id will be the original $row2['id'] value and $value will be the selected option's value. }

Good Job

By not using an array for the form field name (suggested in one of your previous threads on this problem), which would allow you to use the id as the array key and the submitted data as the array value, your code is overly complicated. Also, your use of variable variables will allow a hacker to set any of your existing program variables to any value he wants, so it's possible to bypass things like your log in security after the point where you run that foreach(){} loop. If you are going to do it that way, you would need a list of the expected form fields and iterate over the list and only create program variables for the expected form fields.

That's not the syntax for an UPDATE query. Have you echoed the $query variable to see what it contains? The only thing that is a comma separated list in an UPDATE query is the list of column_name1 = value1, column_name2 = value2, ... that are between the SET keyword and the WHERE keyword. The following is the UPDATE query definition with the most commonly used parts in red - UPDATE [LOW_PRIORITY] [iGNORE] table_reference SET col_name1={expr1|DEFAULT} [, col_name2={expr2|DEFAULT}] ... [WHERE where_condition] [ORDER BY ...] [LIMIT row_count]

You should use an array for the form field name, with the id as the array's key so that when the $_POST data is submitted you can use php's array function(s) to iterate over the data - name='mark[{$row2['id']}]' This will result in $_POST['mark'] being an array with the key being the id and the value being the option value that was selected.

The 'official' definition of your database table would have shown the keys, you have two of them, that has been defined for it. What does the query SHOW CREATE TABLE ws_bi2_cup_clan_lineup produce?

What's the definition of your database table? The key mentioned in the error is likely using a different 1st column and you have a default value being inserted for that column, which duplicates an existing entry.

The only data you escape are the values being put into the query statement.

You would need to make a unique temporary file (see tmpfile), write the php code to the file, include the file, and use output buffering to capture the output from the code. btw -ob_get_clean does the same thing as the two ob_ statement in the existing code.

Is the path displayed in the error message correct? Does the capitalization of the filename match what the actual file is?

I get a different error, so I suspect that the forum software removed some white-space you had before/after the closing heredoc tags. The closing EOD; and MOVIE; tags must start in column one of the line they are in and they also cannot have anything after the ;

You would avoid the problem entirely by retrieving a list of permitted items from the database and present that to the user to pick from, typically via a select/option drop-down menu.

It would be kind of nice if you posted an example of what the $text being put into the eval() statement is? If it doesn't contain any php code, there's no point in using eval on it.

The following lines of code are the problem - if (!empty($name) && !empty($score) && !empty($screenshot)) { if ((($screenshot_type == 'image/gif') || ($screenshot_type == 'image/jpeg') || ($screenshot_type == 'image/pjpeg') || ($screenshot_type == 'image/png') || ($screenshot_type == 'image/pdf') || ($screenshot_type == 'image/docx')) && ($screenshot_size > 0) && ($screenshot_size <= GW_MAXFILESIZE)) { if ($_FILES['screenshot']['error'] == 0) { 1) By testing the ['error'] element last, you are doomed to display your type/size application error message any time the upload fails. The ['error'] check must be first, so that you ONLY use the uploaded file information when you know that the upload was successful. 2) By lumping the type and size checks together, you are doomed to never know which one of those checks failed. Each validation test must be separate and produce a distinct and unique message telling the visitor exactly why the validation test failed. 3) Your distinct and unique validation error messages should display the value that failed the test and the acceptable value(s) so that the visitor (and you when debugging your script) know what value was submitted to the code and what the code allows. This step will let you see that the mime types for pdf and doc don't even have 'image' in them. To make your type test easier to modify, you should put the 'image/gif' ... values into an array and use in_array to test if the submitted value is one of the permitted values.

Which half? The first, some out of the middle, the last, every other row, or rows where the data might look like html tags and don't display in the browser but appear in the 'view source'? There a good chance that It's your code or something about the data that makes it 'appear' that it is missing from the select query. Post your code and show us what some of the 'missing' data looks like.

Your code is requesting the test.php page a second time. Since the <form tag in that code is incomplete, that would imply that all the code you have posted is in test.php? If so, when you first browse to the page, your database logic is being unconditionally executed and is inserting a row with empty data. You need to test and validate the input data so that your database logic only runs when you expect it to.

I'll assume you mean that without any activity that makes a http request that causes a session_start() statement to be executed that the session variables for any particular visitor disappear? If so, you need to extend the session.gc_maxlifetime value. This must be done before every session_start() statement to have any effect and if you are on a shared web server where everyone is using the default/common session.save_path setting, you will need to make your own session data folder and also set the session.save_path setting to point to your own session data folder in order to get your session.gc_maxlifetime value to apply to your session data files.

The current error is because your code changed (to get the error checking and error reporting logic in it, which you should keep btw, and should always use when forming and executing queries) and the result resource is in a variable named $query now. You would need to use that variable in your mysql_fetch_array statement.