mac_gyver

the file of code in post #5 isn't running any code. that's just the class definition. browsing to that file WON'T produce any output. you would need to include/autoload that file, make an instance of that class, and reference the class methods/properties of that class.

your code was exit()'ing inside the else {} statement (which had nothing to do with a mysqli error, it matched your if (isset($_POST['submit']) ... statement) and never reached the <form>. after the change you made, it's still exit()'ing. why do you have that exit(); statement in your code?

the settings that allow statements to read a file using a url are usually turned off. do you have php's error_reporting set to E_ALL and display_errors set to ON so that php would be reporting and display any errors it detects?

sorry if this sounds too blunt, but you cannot program if you aren't looking at and learning what the statements in the code are doing. in your previous thread, you were selecting a database. in this code you are not. you cannot run a database query query unless you select a database or explicitly list the database name in the query. in your previous thread someone suggest setting php's error_reporting/display_errors settings, adding error checking logic to your database queries, and testing if queries match any rows. where is your code that's doing these things? if you always do these things, php and your code will tell you when something fails, where is it failing at, and why, or at least where to start looking to find out why it failed. you also should not be trying to use the mysql_ statements. they are obsolete and will be removed from php in the future. what you are learning now will be out of date and the code you are writing will stop working and need to be rewritten. you had mysqli_ statements in your last thread. you should have corrected that code to use ALL mysqli_ statements.

INSERT queries don't have WHERE clauses. please read the documentation for whatever you are trying to do - http://dev.mysql.com/doc/refman/5.6/en/insert.html perhaps you you are trying to UPDATE existing information, rather than inserting/creating it?

the code you posted above is a race-condition waiting to happen. unless you lock the table, you CANNOT select data and increment the highest value and be sure that you don't have concurrent visitors doing the same thing at the same time, producing the same end value. in fact, since it's going to take a relatively long time (in terms of computing) to retrieve all the rows, there's an even bigger window of time where multiple visitors can be trying to run that same code. why aren't you using an auto-increment column as the invoice number?

try this for the code that combines the arrays - $data = array(); while($row = mysql_fetch_assoc($results)) { $data[$row['id']] = $row; } while($row = mysql_fetch_assoc($results1)) { $data[$row['building_id']] = array_merge(isset($data[$row['building_id']])? $data[$row['building_id']]:array(),$row); } you will also what to sort the final $data array on the key using ksort()

what operating system are you running on the server and what web server are you using?

your's is the first post i have ever seen that has indicated a problem with not getting a data() and given you have had this on different servers and php versions and that most problems are due to code and not underlying bugs, it's more likely that the problem is something like register_globals (in php versions where it exists) overwriting the $invoice_number variable or some handling of the value (in code or the database) is truncating it/clearing it. the 'njis' format string will generate a 6, 7, or 8 character string. perhaps you have some code or data storage that when it is either 6 or 8 characters, that the value is getting cleared? in those cases where you don't get a value, what does your date("njis").rand(11111,99999) value end up being? assuming you are storing these values in a database column, do you have a unique key/index set up on the column, because multiple invoices could be generated during the same second, resulting in duplicate values that could end up resulting in data not being inserted into the database table. also, what is the data type of the column (you could be generating values that are out of range or invalid for the type, resulting in a zero or an empty string being inserted instead.) it's also possible that your code is being requested twice on occasion, once with and once without expected external data and the execution path the code takes results in a value being generated and inserted into your database that's not what you expect. another common occurrence for unexplained operation of code that are redirects that don't have exit; statements after them and the code that continues to run after the redirect does unexpected things to data, since that code isn't receiving the inputs that it expects. you could also have code that is updating a properly stored value to an empty value, either due to pages being requested twice/redirects without exit; statements... short-answer: in about 99.7% of all cases of common things php code is used for, incorrect operation of code/data is due to something the code/data is or is not doing, not due to underlying bugs in the language.

do you have php's error_reporting set to E_ALL and display_errors set to ON so that php would help you by reporting and displaying all the errors it detects? next, you cannot use mysqli_error() to display mysqli_connect() errors, because msyqli_error(...) requires the connection as a parameter. you must use mysqli_connect_error() to display mysqli_connect() errors. lastly, you should always test if your database queries ran without any errors (display a user error message and display/log for development/live server the actual error information) and for queries that may match zero rows, test if the query matched any row and output a user message if it doesn't (sorry, no data was found.)

it depends. bindparam() uses a reference to a variable to get the actual value and would be typically used when you prepare a query and execute it multiple times, in a loop, with different values. the execute() statement evaluates the reference to the variable to get the current value. to use bindparam() in the code in this thread, the foreach loop would need to be - foreach($users as &$user) so that you are supplying a reference to the actual element of the array that's holding the data. bindvalue() uses the value at the time the bind statement is executed and would be used with static values and queries that are only executed once.

you would need to retrieve the data from each query, separately, storing it in a single array, using the id as the array index/key. this will combine the related data together for each id. then just loop over the resulting array of data and display the information the way you want.

you need to keep the tokens in the table, at least for some amount of time, to insure uniqueness. yes, that is correct. you would want a user to be able to login and be remembered separately and independently on different devices/browsers. yes, you need to match both the correct userid and token value when setting the active flag to 0. it's not necessary to unset/delete the cookie. i consider it a waste of time, since you actually aren't removing the cookie in the client. you are setting the time in it to the past (hopefully at least one day in the past so that computers in all timezones, relative to the server's timezone will end up with a time in the past) so that the client won't send it to the server any longer. the cookie and the token value in it will actually still be stored on the client. yes. you probably should also have a 'last accessed' time column in that table that you UPDATE each time the rememberme row is accessed. this will let you know how long in the past the row was used. you can then periodically (via a cron job/scheduled task or even via a database trigger on that table) remove rows that haven't been accessed recently.

here's (untested) the simplest and probably most efficient code that would accomplish this - $users = array(1,4,7); $terms = array_fill(0,count($users),'(?,?)'); $sql = 'INSERT INTO users (user_id, no) VALUES ' . implode(',',$terms); $stmt = $conn->prepare($sql); $i = 1; foreach($users as $user) { $stmt->bindValue($i, $user_id, PDO::PARAM_STR); $stmt->bindValue($i+1, $user, PDO::PARAM_STR); $i += 2; } $stmt->execute();

the place-holder names must be unique. to do this for a multi-value query, you should use ? place-holders and you will either need to use a & reference in the foreach() loop for the bindparam() statement or simply use bindvalue() instead.

several of the possible upload errors will result in an empty ['name'] element. to specifically test if the file upload field was left empty, you need to test for error value 4 = UPLOAD_ERR_NO_FILE you would need to dynamically build the UPDATE query statement to leave out any imagex = '$picx' terms when no image was uploaded for that specific image.

the tutorial you linked to in the above post is also out of date and won't even run on php5.4+. it suffers from the following problems - 1) uses session_is_registered/session_unregister. these functions were deprecated 12 years ago and aren't even present in php5.4+. php will throw a fatal runtime error and stop at these function calls. 2) uses the obsolete/deprecated mysql_ database functions. these will be removed from php in the not to distant future, requiring that the code be rewritten using either the mysqli_ or PDO database functions. if you are learning php or writing new code, you should not use the mysql_ database functions. 3) uses sha/sha1 hash with a fixed/same salt for passwords. sha/sha1 hash is not appropriate for password hashing and using a fixed/same salt value for all passwords makes it easier to find all the passwords matching any particular hash value. see the php password_hash()/password_verify() functions that Ch0cu3r mentioned in his reply. 4) uses poor programming practices, one of which is passing values into functions using the global keyword. 5) specifically turns php error reporting off. error_reporting should always be set to E_ALL and for development/learning/debugging display_errors should be ON and on a live server, display_errors should be OFF and log_errors should be ON. 6) none of the forms repopulate already entered values. 7) none of the database query are tested for errors, so results testing if a row was matched or not can return an incorrect indication. uses ereg() that is also obsolete and deprecated. 9) uses htmlentities() on input data. htmlentities() is an output function and does nothing useful for inputs. given the spammy and nonsense comments posted on that site that the author hasn't even bothered to clean up, that's just another search result/click bait site that could careless about the quality of the content on it.

example code that implements the suggested logic - // at the point in your code where you have determined that the login was successful - $_SESSION['user_id'] = $row['id']; // remember who the logged in user is // check if rememberme is set if(isset($_POST['rememberme'])){ $max_attempts = 5; // the token column is defined as a unique index in the table $query = "INSERT IGNORE INTO rememberme (user_id,token,created,active) VALUE ({$row['id']},?,now(),1)"; $stmt = $pdo->prepare($query); $stmt->bindParam(1,$token); for($x = 0; $x < $max_attempts; $x++){ $token = bin2hex(openssl_random_pseudo_bytes(40)); // 40 bytes/80 hex chars $stmt->execute(); if($stmt->rowCount() > 0){ // row was inserted setcookie('rememberme',$token,time()+60*60*24*365,'/'); break; } else { // row not inserted - this should be very rare trigger_error("duplicate rememberme token occurred"); } } if($x == $max_attempts){ // user error message $errors[] = "the remember me function did not work. the site admin has been notified."; // system error message trigger_error("max attempts used when generating rememberme token"); // this should be even rarer or there's an error in the code/data } } function logged_in(){ return isset($_SESSION['user_id']); } // rememberme check if(!logged_in() && isset($_COOKIE['rememberme'])){ $query = "SELECT user_id FROM rememberme WHERE token = ? AND active = 1"; $stmt = $pdo->prepare($query); $stmt->bindvalue(1,$_COOKIE['rememberme']); $stmt->execute(); if($user_id = $stmt->fetchColumn()){ $_SESSION['user_id'] = $user_id; } } // existing/typical login check if(!logged_in()){ // do what you normally do here when not logged in header('location: login.php'); die; } // at this point, the user IS logged in, either because he had a valid rememberme cookie or he already had a current session that identified him, use the session data any way you need var_dump($_SESSION); you should not store things like user permissions or the usrename (if you want to allow the user to change his username) in the session data as this will mean that you cannot alter these on the fly and have them take immediate affect. you should query on each page request for the user values that can change.

the only thing that is stored in a cookie is the token. it indirectly identifies who the user actually is, via the database table that holds the user id/token values.

variable variable references take three times longer then an equivalent array reference. if you have a set of related data, that's what arrays are for. you can then use php's array functions to operate on the data, generally without any need to explicitly loop over each value and without writing out line after line of code referencing each discrete variable.

yes, but are you assigning the database connection resource to two different variables (or perhaps array elements) and using those two variables (or array elements) in the correct places in the code?

when a user logs in, your session based login should store the user id from the row in your user database table. that's all you need/should have in the session to IDENTIFY who the user is. you should then use that session user id value to query for things like the permissions the user has. to add a remember me feature, you would generate a unique and random token (see openssl_random_pseudo_bytes()), store the token in a cookie and store it and the user id in a database table. set the database table column to be a unique key to enforce the uniqueness of the token (regenerate the token should a collision occur.) as part of your login check code, if the rememberme cookie is present and the current user is not logged in, use the token value from the cookie to find the corresponding user id value. store that user id value in the normal session variable. the rest of your code remains the same, using the user id from the session variable. when the person logs out, mark the matching row in the database table as being logged out (a separate column in the table.) this will prevent that token value from being usable by that person or any one who gets a hold of it.

further to the above, the data you 'collect' each week is what all other results are 'derived' from. by storing the source data, you can query for any of the derived information. you don't need to store the derived information itself, as this results in redundant and wasteful data storage. to query for the top player in any week, you just query the source data to get the highest score for any date/week. to query for the overall leaders, just group by the player_id, sum() the score values, order by the sum'ed score, and retrieve the top n records. whatever you do, you need to fix the security in the code you posted above. the login check needs an exit; statement after the header() redirect to prevent the rest of the code from running. anyone, logged in or not, can just ignore the redirect and post anything they want to your code and your code will process the submitted data. if that particulate session variable is the same one that is set when anyone logs into your site, anyone who is logged in can submit data to that code, not just you as the administrator of the site. you need to enforce permissions to limit who can submit data. currently, a logged in user can easily add any amount he wants to his or anyone else's points and because you are not storing the raw data as separate rows in a results table, you don't even know if this is happening. you are not doing anything to prevent sql injection, so until you fix the above two items, so that only you can submit data, anyone can mess with your database tables any way they want. lastly, if you were doing something where you need to maintain a point value for each individual user, you don't need all that code. you can use one INSERT ... ON DUPLICATE KEY UPDATE query to replace the three individual select, update, and insert queries.

the reason it appears that your data isn't updated until after you have submitted the form twice, is because you are retrieving and displaying the data near the top of your code, with the form processing code at the end. the form processing code should be near the top of your code, with the display code after it, so that any changes made to the data will be present when you retrieve the data to display it.

1) you need to review the last post in your previous thread on this forum. 2) you should NOT have separate database tables for each location/venue. you should have one result table with a column that holds a location id that the data belongs to, with a separate table that defines the locations and assigns the id value via an autoincrement column. 3) once you have the raw data stored properly, you can query for anything you need anytime you need it.