mac_gyver

array keys/indexes must be unique, so your anticipated result is not possible.
 
not knowing why are you doing this, what you are ultimately using the data for, which would produce the best result, i would recommend making an array with the start value as the main array key and the (start)/title/description data as sub-arrays under any start value. it would look like - 
$data['201601221400'][0] = array('start' => '201601221400', 'title' => 'FABLife',    'desc' => 'Mark Cuban (``Shark Tank\'\'); top five must-haves; collectors try to guess the prices of celebrity memorabilia; creating a high-end playroom and eliminating toy clutter without breaking the bank.' ); $data['201601221400'][1] = array('start' => '201601221400', 'title' => 'The First 48',        'desc' => 'A young man is robbed and killed while meeting up with a girl he met earlier; a man is gunned down outside an annual football game.'   );  $data['201601221400'][2] = array('start' => '201601221400', 'title' => 'Teen Titans Go!',        'desc' => 'Robin makes the other Titans sell their treasured mementos from past adventures.'   );  
you would produce this by looping through the data, using the 'start' value as the main array key and appending an array consisting of the start, title and desc - 
$data = array(); foreach($items as $arr){ $data[$arr['start']][] = $arr; } echo '<pre>'; print_r($data);

you would use a html array name for the rec form field, where the array key is the SKU number - name='rec[1769057]'
 
this will result in an array in $_POST['rec'] that you can use php's array functions on, such as a foreach(){} loop to loop over.the elements when providing data to your sql query.

it's probably something in the 'dbconfig.inc.php' file.
 
 
or if the posted code is being included/required into another file, it's coming from something in the main file.

it's likely that your actual complete code is deleting the file after you have moved it to the folder. i'm betting if you put a die; statement after the echo '<br>$result: '.$result; line, that the file will be present in the folder.
 
edit: btw - how do you know the file isn't in the folder? what method are you using to get a listing of the files, since the fault may be in the method being used?

the header('location: ...') is only telling the browser to make a http request for a page. if this is causing a new browser tab to open, there must be something somewhere else in the code on the page to cause it. this is not being caused by the header() statement.
 
why do you have so much repetition in your code? this just makes for a lot of extra work for you, especially when you need to fix or change anything in the code. currently, you need to add protection against sql injection for all those queries, which there are actually only two different variations of a single query. by refactoring your code so that the sql query statement only exists once, adding sql protection, or changing anything about the query, would only have to be done in one place.

your code that is executing the sql query statement is not inside the loop. it's after the end of the loop. therefore it is only executing the sql query statement that was formed in the last pass through the loop.
 
wouldn't you have to execute the sql query statement inside the loop?

the error about the header() ... states that some output was sent to the browser and on what line all or the end of that output was at, that's preventing the header() from working. you would need to find and fix what is causing that output.

your error message has changed, because the problem changed.
 
the original error was due to fg_membersite.php, not membersite_config.php. in the first post, the require_once() for membersite_config.php was working. it was the require_once() for fg_membersite.php, inside of membersite_config.php, that wasn't working.
 
the most immediate problem is now the path for membersite_config.php.
 
all the folders in question are inside a folder named gesdocente.
 
you either need to add the gesdocente folder to the absolute path you are making for all the require_once() statements OR you need to make the relative path using two .. for all the require_once() statements.
 
edit: relative paths, anything that starts with a ./ or ../ are relative to the main file that was requested, because when you include/require code into your main file, its scope when it runs is the main file, not where it is stored at on the server.

there are three other serious problems with your code -
 
1) the mysql_ functions are obsolete and have been removed from the latest php version. if you or your web host updates to the latest php version, your code will stop running at all and will need to be rewritten. to avoid wasting time learning obsolete methods that will have to be redo in the near future, you should be using either the PDO or mysqli_ database functions. PDO is the best choice, especially if using prepared queries.
 
2) your code has little to no protection against sql injection or of special sql characters in the data causing sql errors. the easiest and most constant way of protecting against these problems are to use prepared queries.
 
3) don't use the GLOBAL keyword to being data into a function. this breaks encapsulation and you might as well not be using functions. you should pass any data into a function as call time parameters.

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?
 
do you have the PDO error mode set to exceptions so that any PDO statement that throws an error would cause an exception so that your main code only has to deal with error free execution of the PDO statements?

this is a problem with the foreach($arr as $txn) loop and references. the $txn variable that the foreach loop creates is a new variable and any reference(s) when you ran the bind_param() statement no longer exists.
 
your example is only looping over a single set of data. if you don't need to do this in a loop, don't.
 
if you do need to do this in a loop, either 1) bind individually named variables, $payee, $date, , ..., then, inside the foreach(){} loop, assign each named element of $txn to the correct named variable, $payee = $txn['payee'];, ...or 2) bind elements of a differently  named array, $temp['payee'], $temp['date'], ..., then, inside the foreach loop, assign each named element of $txn to the correct named element in $temp (you can actually use a second foreach loop to do this). if you use the $temp array method, you must assign each element individually inside the loop. you cannot simply do $temp = $txn; because this will end up referencing the last element in the $arr every time through the loop, if i remember correctly.

you should have one set of users and one login. each user would have a role/type stored for him/her that would determine what they can do or see on any particular web page.

your concatenation probably didn't work due to the semi-colons ;. those only go on the end of php statements. when not within a quoted string, the first semi-colon that was encountered was telling php that was the end of the statement. everything following that probably didn't make any sense to php and it was throwing a syntax error.
 
to put the object method calls in the string, you would need to put { } around each object method call so that php can figure out what part is the reference to the object. you would also remove the semi-colons, unless you literally want the ; character to be in the output.

UPDATE queries don't return a result. calling the ->free() method after running an UPDATE query makes no sense.

just checked the mysql documentation and CREATE EVENT queries cannot be prepared. see the list of statements that can be used - http://dev.mysql.com/doc/refman/5.7/en/sql-syntax-prepared-statements.html
 
just confirmed this by getting your 'prepared' query to work with PDO's prepared query set to 'emulated' and also by using a normal ->query() method with your hard-coded query.
 
using a real prepared query, it silently fails with nothing in the mysql query or error log, so the lack of any pdo error is likely due to the php driver not doing anything in this case.

because you are using the IGNORE keyword in the INSERT query, you are probably triggering some unique index/key error. you would only use the IGNORE keyword when you want to silently ignore duplicate data and the index/key errors they cause.
 
however, just about everything your code is doing is has a problem. the biggest problem is your food database table should NOT have columns like - eggs_price, bread_price. the data for each item, eggs, bread, ... should be a separate row in the table, with an item_id column that identifies which item the price is for.
 
another BIG problem is the massive amount of logic you have (or are going to write) that only differs in the the values being tested/used. if you use an array to hold the weekday/hour data, all that $weekday/switch($hour) logic can be replaced with a few lines of code.
 
lastly, what is the overall goal of doing this? you are apparently calculating prices for each hour for each day of the week a date falls on. this is derived data and you will end up with a massive amount of stored data as the number of dates increases. in general, you would not do it this way, but store the weekday/hour data in a data structure (database table, array) and calculate the price as needed.

for the value to be a zero in the table, the column definition is probably a numeric data type, not a character data type. what is the definition of your database table?

are you changing the master php.ini (this would require owner/root access to the server) or a local php.ini (this would be the case if you only have an account on a shared web server), what is your php version, and is php running as a CGI/FastCGI application on the web server?
 
the most likely reason is you have a case were you are using a local php.ini and it only affects the folder that it is in. try copying the php.ini to the ajax folder or put any files that you are going to be making http requests to in the public_html folder.
 
you may want to see the following section of the php.net documentation for the different server/version configurations that determine how php finds the settings it uses - http://php.net/manual/en/configuration.php

you can build the $expiry_options array entries with whatever values you want. store the strtotime offsets - '12 hour', '24 hour' (add them manually), '1 week' up to 'n week' (add the weeks dynamically using a loop) in the array. i'm pretty sure that the 's' is optional in the strtotime, so build the values that you need for display purposes, and the strtotime() should work.
 
since the permitted values are now in an array, to validate that the submitted value is one of the permitted ones, before using it in your code, you can just use in_array().
 
see this code -
<select name="expiry_date">     <?php     $num_weeks = 10; // define the number of weeks you want in the option list     // produce the data for the option list     $expiry_options = array();     $expiry_options[] = '12 Hours'; // manually add the two hours entries...     $expiry_options[] = '24 Hours';     foreach(range(1,$num_weeks) as $week_no){ // add the week entries         $plural = $week_no > 1 ? 's' : '';         $expiry_options[] = "$week_no Week{$plural}";     }     ?>     <option value="0">Expires In</option>     <?php     // output the option list     foreach($expiry_options as $arr){         $sel = !empty($_POST['expiry_date']) && $_POST['expiry_date'] == $arr ? 'selected' : '';         echo "<option value='$arr' $sel>$arr</option>\n";     }     ?> </select>

here's something else that you can do that will generalize your code. for the dynamic/conditional parts of the sql statement, add the different terms to arrays, then implode the contents of the array using either ' OR ' or ' AND ' as the separator string.
 
for sections where you are producing something1 OR something2 OR ..., you would add each of the something... to an array, then implode the array using ' OR ' to give that part of the sql statement.
 
your overall WHERE clause is a collection of AND'ed terms. you can have a main array that holds each of the individual parts as they are being built, then implode this array using ' AND ' (along with a few ( and ) ) to give the total AND term.
 
here are your snippets of the query showing these methods (untested, could contain typo's) -
$params = array(); $and_terms = array(); $and_terms[] = "au.suspended = 0"; if (!empty($_SESSION['advs']['title'])) {     $terms = array(); // always initialize (array) variables     if (isset($_SESSION['advs']['desc']))     {         $terms[] = "au.description like ?";         $params[] = "%{$_SESSION['advs']['title']}%";     }     $terms[] = "au.title like ?";     $terms[] = "au.id = ?";     $params[] = "%{$_SESSION['advs']['title']}%";     $params[] = $_SESSION['advs']['title'];         $and_terms[] = implode(' OR ', $terms); } if (isset($_SESSION['advs']['buyitnow'])) {     $and_terms[] = "au.buy_now > 0 AND     (au.bn_only IN('y','n') AND (au.num_bids = 0 OR (au.reserve_price > 0 AND au.current_bid < au.reserve_price)))"; } if (isset($_SESSION['advs']['buyitnowonly'])) {     $and_terms[] = "au.bn_only = 'y'"; } if (!empty($_SESSION['advs']['zipcode'])) {     $userjoin = "LEFT JOIN " . $DBPrefix . "users u ON (u.id = au.user)";     $and_terms[] = "u.zip LIKE ?";     $params[] = "%{$_SESSION['advs']['zipcode']}%"; } $wher = "(".implode(') AND (',$and_terms).")"; // bind the data in $params here or use $params as a parameter to the ->execute($params) method

the character-encoding for the first link/page is - utf-16le, which is treating characters as consecutive 2byte/16bit entities.
 
the character-encoding for the second link/page is - utf-8
 
just changing the character encoding that the first file is saved with may fix the problem.

the way to do inventory, is like a checking account or an credit-card account register. you store a row for each + or - transaction.
 
the table tracking the inventory would hold the book_id (you would also have a 'book' table that holds the unique information about each book/title), user_id (who added or subtracted a quantity), the date-time (when the user added or subtracted a quantity), the quantity, and a memo/comment/status column.
 
you would initially store a row for each book/title, with the a positive quantity of how many are on hand. the user_id for that row would be the admin/librarian that initially enters the information. if more books are ordered and added to the inventory, you would add a row with a positive quantity.
 
when someone checks out a book(s), you would enter a row for each different book_id, with the quantity as a negative value. when they check in a book(s), you would enter a row for each different book_id, with the quantity as a positive value.
 
to get the quantity on hand, you would use a query with SELECT SUM(quantity) .... .... GROUP BY book_id.
 
if you are giving each book a unique id/serial number, you would still do the inventory this way, but you would have a separate row for each separate book, with a serial_number column to record exactly which book was checked out/in. the quantity column would then either be a 1 or a -1.

based on the error message, you are using mysql. the lag and over functions don't exist in mysql. they are ms sql features.

re: post #6. there's nothing obvious in the code that would account for the problem/browser difference. if i have time i will investigate the code further.
 
re: post #7. isset() tests if the variable is set or not. the boolean true from the print_r just means that it is set. when it is set, it can have either a false value or it will contain the fetched row from the query, so, adding an isset() around it is meaningless.
 
any chance that in the browser where this works, the browser has been configured to remember passwords and it's actually the browser that's supplying the password and in the browsers where this doesn't work, you are actually typing the password and you are using the wrong one, either because the one that works was originally entered/registered with some fumble-finger accidental extra/wrong characters in it, or you are typing wrong password where it doesn't work?
 
in any case, you need to determine why the query is not matching any rows. here are two things to do -
 
1) temporarily modify the sql query statement so that it only tries to match the username. if the code then results in a var_dump of the $user variable with the expected row from your database table, that means that the username comparison is working and it's the password that's the problem.
 
2) echo the md5() hashed password value and see if it is the same as what is stored in the row in the database table. i suspect it is not. i would do this for both the browser where it works and at least one where it doesn't. the echoed hashed value should be the same for all browsers and it should match exactly what is stored in the database table row that corresponds to the username you are testing with.
 
edit: actually, step #1 in the above may not be so temporary. if you switch to using password_hash()/password_verify(), you will need to match the username in the query, retrieve the hashed password and pass the entered password and the retrieved hash through the password_verify() function to see if they match.