kicken

You need to enable the mbstring extension either by recompiling PHP with it enabled, or via the system package manager. Which one depends on how you installed PHP in the first place.

You're PHP setup has an invalid value for the date.timezone setting in php.ini. You need to determine what the correct setting should be and then update the php.ini and restart the server. Based on what you have, and the list at http://us1.php.net/manual/en/timezones.asia.php I'd say you probably want to set it to 'Asia/Calcutta'

You can't. The user can ALWAYS leave the page. There is no way at all for you to prevent that. There isn't even a reliable way to determine if the user has left the page. What you need to do is setup your system so that until all these fields have been filled in, that DB record is considered to be incomplete and is more or less ignored. If you want, you can have a cron job periodically run to delete all the older incomplete records to conserve space. Another alternative is to just not create the DB record at all until they have submitted all the necessary information. Store everything into session variables until everything is complete, then create the DB entry at the end.

Without knowing more details, I would venture to guess that the script you have is intended to be run via the CLI version of PHP, not as a web page. There is probably a check in the code to determine if you are running the script via CLI or not and if not, it is showing that error and refusing to run.

Your problem is that your number2 column is the wrong datatype. You should change it's type to be one of the numeric types (INT,DOUBLE,etc, whatever is appropriate for the values stored). Once you do that it will sort them correctly without the need for a hack like your currently using.

Bug# 51096 'last day' meaning -1 day is the correct behaviour. It returning the last day of the month was considered a bug and got fixed. Use the date('Y-m-t') method, or possibly 'last day of'.

A database request shouldn't affect how flush/ob_flush work. If they are not working properly then most likely there is something else down the line buffering your data which you have no control over (ie, the webserver, proxy, cache server, etc). Also I don't know what your full code is, but if you are going to do a while(true) loop like that then you should include a delay in each iteration. That way even if your script does end up running for a long time it is not chewing up all the CPU cycles and DB processing checking for nothing. Something like: while (!$messages = GetNewMessages()){ sleep(1); //Pause for a second } If you really want to do long-polling then a more ideal solution would be to have a separate server which the clients connect to for message checking which handles the situation better. The main problem with doing this with something like apache is that while your script is sitting there waiting for new messages, it's tying up processing threads which apache uses to handle requests. If you end up tying up all the processing threads with your polling script nobody would be able to browse your site at all. That is one of the reasons that short-polling (ie, returning a 'nothing new' response, despite being a bit of a bandwidth waste, is preferred.

This is my choice usually when doing something like this. I provide only two boxes, and handle them like this: - Only first box filled in, exact date search or date <= given date (depending on what is appropriate for the given report) - Both boxes filled in, range search - Only second box filled in, exact date search or date >= given date (depending on what is appropriate for the given report) I include a short bit of text explaining how they work next to the fields to help the user make the proper choice in what to fill in. Regardless of what you do on the client side though you need to include a check on the server side. If all the fields are filled in you need to have some way to prioritize which one you use. That could be via a radio button as mentioned, or just an arbitrary ranking (ie, prefer exact date over range).

You can't, not from a remote network anyway. If you're accessing a site on the LAN then their IP would be in the $_SERVER['REMOTE_ADDR'] variable. If your site is on the internet though then there is nothing you can do to get their LAN IP, only their public IP.

The proper way to code that query would be this: SELECT * FROM users LEFT JOIN profiles ON users.username=profiles.username WHERE users.username=? Then you bind the username you want to search for as the value for the ? parameter.

It look like whatever you did to try and change the port was unsuccessful. Perhaps the wrong config file or the change was not save properly. You'll also need to either disable the SSL port (443) or change it to something else.

$('.remove_cart_item', this) That sets the context so it will only search nodes under the this node, which would be the div that is currently being moused over.

Your problem is that your trying to figure out how to combine pieces of pre-written PHP code. Instead you should just think about what process you have to go through to generate a watermarked image and then try and develop code for that. Once you know the proper process, figuring out where in your upload processing the code to do it should go should be relatively simple.

Yes. Then to load a site via apache you'd visit http://localhost:8080/

For apache you edit the httpd.conf file and change the Listen 80 line. Change 80 to be whatever new port you want, save, then restart apache. I've no idea how you edit the IIS port via the command line, but if you use the administration GUI you'd just edit the bindings in the site configuration.

Is the path to your image via URL something like http://example.com/public_html/recipeimage/cheesesandwhich.jpg or is it http://example.com/recipeimage/cheesesandwhich.jpg. If it's the latter you'll need to strip the public_html bit off before you echo out the path, which you can do using substr.

Make sure your variables that are used in the SQL queries have been escaped using mysql_real_escape_string, or even better, update your code to use PDO and prepared statements. Secondly, rather than do some SELECT's to get $money and $money1 you can do the whole thing in a single UPDATE query which would prevent race-conditions resulting in a bad money value. My syntax may be off some as I typically used SQL Server that has a different syntax. Check the mysql manual for syntax details UPDATE users u INNER JOIN ad_clk a ON id=$adi SET u.money=u.money+a.money WHERE u.id=$uid

Run this: SELECT HEX(ticker) FROM stocks That will print out the value as hex pairs which you can use to figure out what extra characters are present.

Correction: 192.168.45.203 should actually be 192.168.40.203 in the example. 192.168.45.203 would not match any of the routes and end up going to the default gateway.

would become simply: addresses = <?php echo json_encode($addressList); ?>;

No, it wouldn't. There is a way to do it known as variable-variables, however as mentioned it is the wrong solution. What you should do is store everything into an array. For example: $addressList=array(); for ($i=0; $i<20; $i++){ $addressList[$i] = mysql_result($result, $i, 'address'); }

It all has to do with the routing table of the computer. Basically the sequence of events goes roughly like this: 1) The OS's TCP/IP stack examins the destination IP and attempts to match it up to some entry on the routing table. Essentially this is the 'Is it local or not' step. 2) Assuming the address is not local, it typically goes to the default gateway. If you have a LAN, then it would end up at your local router, which most likely would just send it on to the ISP's router. If you don't have a LAN, then it'd just go directly to the ISP's router. 3) The router goes through a process similar to what your PC did. It looks at the destination IP and matches it to a route in it's routing table. If it matches one, it will send the packet down that route. If it can't find a match then the packet goes up to the next router in the chain. This process of passing up to a higher-level router repeats until a match is found (or there are no more possible routes). As for how the PC and router determines which route the IP is a part of, this has to do with the Netmask. A route basically defines an IP prefix and specifies which port belongs to that prefix. So for example say your ISP's router had 5 ports, each connected to another network. Lets assume the ports are connected like so: Port 1: 192.168.10.100/24 Port 2: 192.168.20.100/24 Port 3: 192.168.30.100/24 Port 4: 192.168.40.100/24 Port 5: 192.168.50.100/24* The /24 part in the above is the netmask, specified using CIDR notation. With the values I chose it basically splits the IP at the last dot so the first 3 sections denote the network, and the last denotes the host. Assume the * denotes the default route/gateway If the router gets a packet destined for 192.168.45.203 then it would attempt to match that IP up to it's various routes. First it will take that destination IP and break it down to just the network portion, which is: 192.168.40. Then it will go through it's routing table looking for a matching network entry. In this case, it finds one on Port 4, so it would forward that packet out to whatever is connected to Port 4. If the router would have been unable to find a match (say the destination IP was 192.168.100.48), then it would forward the packet to it's default gateway, which in this case is 192.168.50.100. Then that router would repeat the process until a valid route was found. Not exactly. The IP is what determines the host. The port indicates the service. So it would make it to your computer by IP address alone. Once it has reached your computer, the OS accepts the packet and examins it. The OS looks at what service (port) the packet is destined for and then checks it's records to see if any process is expecting packets destined for that service (ie, apache). If so, it will pass the packet on to that process which then pickes it up and does whatever. If the OS can't find any processes that will accept that packet, it generates an error response and sends that back to the original packet sender. That is essentially the super-simplified basic understanding of how networking works. There is potentionally a lot more going on, such as NAT's, Firewalls, Tunneling, etc. NAT's may be causing you some confusion, evidenced by a couple things you mentioned: "a port ... forwards it to the host"/"and somehow remembering which device requested it". Involving NAT is what introduces the need for port-based forwarding of packets, which requires the device to remember where packets originated from. If you're behind a NAT, when you send a packet out, the router will take note of that packet's source IP and port #. It then re-writes that bit of the packet with it's own IP and port # and sends the packet up the chain. When a reply packet is recived the router will check it's destination port# and try to match it up to it's list of sent port numbers. If it finds a match it will re-write the packet with the proper destination IP and port and forward it on. If it doesn't find a match the packet is usually just dropped.

You can pass multiple variables to unset(). unset($func_get_args[0], $func_get_args[1]);

If you want to use dynamic field/table names, you still just concatenate the variables into the string, same as what was done before with the mysql extension: $sql = 'SELECT '.$fields.' FROM `users` WHERE `user_id` = ?'; $data = $db->prepare($sql); ->fetchColumn will fetch just a single column from the first row of returned data. If you want to fetch every column of the first row, use ->fetch(). If you want to return every column in every row, use ->fetchAll()

You can't parameterize (bindParam/bindValue) things like field names, table names, SQL code, etc in a query. The only things you can parameterize are values (strings, numbers, NULL).