mac_gyver

what tool/software are you using to assign privileges to the database? you may need to explicitly flush the privileges to get them to take effect. another possibility is if you have a typo or some white-space as part of the value(s) in the php code.

are you sure of the database server hostname for the new domain? it may in fact be different from any previous domain. are you sure of the database username and database name? a lot of web hosting requires the hosting account name as part of the database username. after you created the database username/password, did you assign that database username privileges to the database you are trying to use?

and since these key values likely came from user supplied data, you should use a prepared query to supply the data values at the time the query gets executed in order to avoid sql injection. this would involve dynamically building the IN (....) term with the correct number of place holders and dynamically binding the input data. doing this with mysqli is a pita. using the PDO extension, instead of mysqli, is all around easier and more consistent.

what debugging have you done to narrow down the problem? have you dumped (see: var_dump()) the role value so that you know what if anything it is? are you sure that login success code is even running for the users with those roles? if all your code is doing is mapping a set of values to other values, you shouldn't write out conditional logic (if/elseif/switch/case) for each possible choice. this will require that you edit the program logic just to add, remove, or change any of the possible choices. it also makes for cluttered code, which i just noticed is the cause of your problem. you have a missing {, which has made all your conditional logic off a bit. properly indenting your code, based on where matching { and } are at would help you make sure all the { and } are where you intend. you should instead write general purpose, data driven code, that defines data (arrays) that tells simple code what to do. see the following example - // define categories of roles (in a configuration file) $management = array('Admin', 'Manager', 'Front_Desk'); $staff = array('Writer'); // at the point of decided what to do for the category a role belongs to if(in_array($role,$management)){ header("location: reservation.php"); exit; } elseif (in_array($role,$staff)){ header("location: articles.php"); exit; } else { // none of the defined roles, handle that condition here... } next, logging someone in, involves identifying who they are, not what permissions/roles they have, which is a different concern/different process. all your login code should do, when the username/password has been confirmed, is to store the user_id in a session variable. after your post method form processing code successfully runs (with no errors), it should do a header() redirect to the exact same url that the form submitted to. this will cause a get request for the page, which stops the browser from trying to resubmit the form data. when each page gets requested, it should take the user_id from the session variable and query for the current user permissions/role. this will insure that any change made to a user's permissions/roles take affect on the very next page request. any page should take the user permissions/role and use them to determine what will be processed on the page and what will be displayed.

the examples in the documentation, SELECTing the value returned by the FIELD() statement are only to demonstrate what value is returned for each example. imagine calculating that value for each row of data in the result set and ordering the data by that value - ORDER BY FIELD(cstype,'main character in', 'secondary cast in', 'appears in', 'cameo appearance in')

you can either use FIELD() or FIND_IN_SET() in an ORDER BY term in the query to do this.

the OP's symptom is most probably due to php not being able to send the session cookie to the browser. the session data file is still created in this instance. does the OP have php's error_reporting set to E_ALL and display_errors set to ON in the php.ini on his development system so that php would report and display all the errors it detects, particularly a couple of warnings at the session_start() statement?

you will need to attach a partial sql dump of your database table as a file to a reply. this will show us the table definition, in case the definition of that column has something to do with the problem, and it will provide us with the actual data value you expect the query to match. also, how do you know the query doesn't match the data? the method/code you are using to detect if there is a result set may be at fault.

if you read the whole error message, it's also telling you where the output is occurring at that is preventing the header() from working.

$filenames = array("index.html", "areas.html", "test.html", "example.xls"); $folder = $this->skeleton_dir; $files = glob("$folder{".implode(',',$filenames)."}",GLOB_BRACE); return (count($filenames) == count($files));

because of the meta key/value pairs, that you want to match two different sets of, you need to join with the woocommerce_order_itemmeta twice, once for each set of values. the following (untested) should work - SELECT oi.order_item_id, oi.order_id, pm.post_id, pm.meta_value, u.ID, u.user_nicename, oim_t1.meta_key, oim_t1.meta_value, oim_t2.meta_key, oim_t2.meta_value FROM $wpdb->postmeta pm INNER JOIN $wpdb->users u ON pm.meta_value = u.ID INNER JOIN $wpdb->woocommerce_order_items oi ON pm.post_id = oi.order_id INNER JOIN $wpdb->woocommerce_order_itemmeta oim_t1 ON oi.order_item_id = oim_t1.order_item_id AND oim_t1.meta_key = '_wcs_migrated_subscription_status' AND oim_t1.meta_value = 'active' INNER JOIN $wpdb->woocommerce_order_itemmeta oim_t2 ON oi.order_item_id = oim_t2.order_item_id AND oim_t2.meta_key = '_product_id' AND oim_t2.meta_value = '20' WHERE pm.meta_key = '_customer_user'

you should use the highest php version that's available to you. there are actually few incompatible changes moving up to higher php versions, provided code isn't using deprecated/removed features, and code doing basic/common tasks isn't likely to be affected at all. edit: for the error above in post #10, it looks like you are missing the semi-colon ; on the end of that statement.

the error is because of the php version. add the word array before the [

no. the injected sql is normally used with SELECT queries to read other tables in your database. because you are already selecting data to display, all the injected sql needs to do is satisfy the syntax of your existing query, then it can add a UNION SELECT anything it wants, to get your code to query for and output things like the content of a user table including email addresses and hashed passwords. there's nothing syntactically wrong with the posted code, provided you are using php5.4+. you are likely getting a fatal run-time error, such as an uncaught pdo exception. do you have php's error_reporting set to E_ALL and display_error set to ON so that any run-time errors will be reported and displayed? if you are using a version of php that's lower than 5.4, you would be getting a php syntax error due to some php5.4+ specific syntax in use. what is your php version? the wild-card % are around the data, not part of the array index name. you would use the following, including the double-quotes - "%{$_POST['search']}%"

stopping sql injection is just one part of making a secure application. your query can be safe from sql injection, but your application can still be open to misuse. should all the users on your site be able to submit data to this code and update any record having any id value? if not, you would need a user permission system to control who can perform any action (an update query for events, in this case) or view any content (the 'edit/update' button part of an events list and the events update form for a particular record) and if they are restricted to only affecting records they are the 'owner'/creator of, or do they have permission to update any event record. to allow a user to pick which record to update, you would end up passing the id as a hidden form field value, which is what you are doing now. you would need to determine if the user has permission to run the update code at all and if he has permission to affect the record with the id value that was submitted.

in the first post in this thread, you had the correct syntax for an UPDATE query, just the desc column needed special handling since it is a reserved keyword. why have you now completely changed the syntax? the following is the syntax definition for an UPDATE query (from the mysql documentation) - the red parts are what is commonly used.

you will also need to put the % wild-card search characters around the actual data value in $_POST['search'] when you supply it for the query's execution.

array indexes/keys must be unique. it's not skipping. when you define three elements with the same index/key, each new definition replaces the previous one. depending on what you are trying to accomplish, you can make each array element have a region and city - $areas = array( 'region'=>"London", 'city' => "North", 'region'=>"London", 'city' => "South", 'region'=>"London", 'city' => "West", 'region'=>"Newcastle", 'city' => "North" ); or you could make a sub-array under each region - $areas = array( "London" => array("North","South","West"), "Newcastle" => array("North") );

if you read the documentation for that error number, you will find what setting affects it. this will also let you decided if you even want this check to be used, since it was just php doing it's own thing that's not in any way secure from tampering and therefore is pretty meaningless to use. if you don't want to use this particular php feature, just remove the line from the form markup.

you are actually using several of the statements with the wrong or non-existent variables. if you had php's error_reporting set to E_ALL and display_errors set to ON (the best place to set these is in the php.ini on your development system), you would be getting several php error messages due to the incorrect usage. if $con is your database connection, you would use that in the mysqli_prepare() and the $con->error. you would not use it in the mysqli_stmt_bind_param(). the mysqli_stmt_bind_param() uses the $stmt. next, you should have error handling for all the database statements that can fail (connection. prepare, execute), so that you don't run following dependent statements when an earlier one has failed. this would catch the case where the connection didn't work. you would never get to the point of trying to run code that depends on the connection. the easiest way of universally adding error handling for all the database statements, is to use exceptions. by using exceptions, your main code only has to deal with error free database statements. you don't have to write conditional logic in your code at each statement that can fail. lastly, are you open to using the PDO extension, rather than the mysqli extension? when using prepared queries, the PDO extension results in the cleanest code.

untested, but should work - // the code given in your last thread - $data = array(); foreach($items as $arr){ $data[$arr['start']][] = $arr; // index/pivot the data using the start datetime as the key } // the suggested processing in this thread - foreach($data as $time=>$arr){ echo "$time<br>"; // output a heading $arr = array_slice($arr, 0, 5); // get a maximum of 5 elements from the array foreach($arr as $element){ echo "Title: {$element['title']}, Description: {$element['desc']}<br>"; // output the data the way you want } }

that may be what you have as a setting, but what is the actual value that's in effect when the php code runs? what does the output from a phpinfo() statement show? also, where are you setting the error_reporting setting at, and does the phpinfo() output show that location to be the one that php is using on both systems? it's more likely that one system isn't using that setting at all or you have a local php.ini or .htaccess file that's overriding the setting or a syntax error in the php.ini file that prevents all settings after the error from having any effect. for the exact same code, this would normally be due to using short opening php tags. for the exact same code, this would normally be due to using short opening php tags in the included/required file.

from your last thread, you have the $data array. foreach($data as $time=>$arr) { // $time is the main array index time value // $arr is an array of the arrays of data under that time - do whatever you want with it here. }

so, what you are trying to do is output a maximum of 5 sets of data for each time value? if so, i would just loop over the result you got from your last thread on the forum, which would give the time and an array of the data for that time, and output the data the way you want it. you can use array_slice() to get a maximum of 5 elements from the array under each time value, then just implode or loop over that array, depending on how complex the formatting is, and echo the result.

yes, the } you have on line 114 does close the function definition. the error is due to the Heredoc closing tags (two places) being indented. they must be the only thing on a line and cannot have any characters before them on the line and can only have a ; and a newline after them on the line. the color highlighting in your programming editor should have stopped changing at the first EOF; to alert you to this problem (all the code after that point is considered to be part of the string.)