PFMaBiSmAd

If there are zero rows in the result set, mysql_fetch_array($left_customer_result) will be false and the code inside your while(){} loop will be skipped over. The code you have inside your while(){} loop that is testing or displaying $left_customer_result_count won't ever be executed. You would want to test $left_customer_result_count before the start of your while(){} loop.

1) Find a simple calendar script that displays a calendar the way you want. 2) Query your data table for the range of dates being displayed and read the data into an array with the index being the date and the value being the data. 3) Pass your array of data into the function that generates the calendar and when the current date being displayed exists in the array, get and output the data. Remove the just processed data from the array (makes accessing the remaining data quicker.) This may require that you produce the current date being displayed in the calendar code that matches the format you have in the array keys. 4) Done.

As to why some quotes are not escaped at all - they are probably not straight quotes (someone probably copy/pasted text that contained curly/smart quotes) and wouldn't break the sql syntax and the various escape functions (built-in and user called) don't operate on them. As to why some quotes are escaped more than once - php thought it was a good idea to 'help' make code safe against sql injection instead of have someone spend 3 minutes learning how to properly escape data. See the excuse at this ridiculous link - http://www.php.net/manual/en/security.magicquotes.why.php

Edit: LOL, same suggestion ^^^ Don't unconditionally use stripslashes() on your data. That can prevent actual \ characters from being used in the data. First, find out why your data is being escaped extra times and only some times and address the actual problem.

Your user function - mysql_prep() is also relevant code.

Your code isn't checking if the upload worked, before accessing any of the uploaded file information. $_FILES['slika1']['error'] will be set and be a zero if the upload worked. If $_FILES['slika1']['error'] is a non-zero, the value would tell you why the upload failed. See this link for the ['error'] values - http://us.php.net/manual/en/features.file-upload.errors.php

New-line characters don't mean anything in rendered HTML that is displayed on a web page (unless you use <pre></pre> tags or similar around the content.). You need <br> or <br /> HTML tags. See this link - nl2br

To get a local mail server that will actually send an email to an external email address requires that you have a valid domain name (or use a hostname from a service like DynDNS) and a DNS server (from a service like DynDNS) where you can put all the necessary dns zone records to make your mail server a valid public mail server that other mail servers will accept an email from. You would also need to determine if your ISP hasn't blocked the ports necessary to do this and you will need to configure your router/firewall. You can also just set up a local mail server that will accept an email from the php mail() but send it only to a local dummy mail box on the local mail server. There are a number of free/open source mail servers and you can probably find one that is ported to work on your operating system. Do you need to test your mail function by actually sending an email? Couldn't you just log the $to, $subject, $message, and $headers variables to make sure of what they contain? You can also use a php class, such as phpmailer with SMTP Authentication to use a remote mail server, such as your ISP's mail server or a gmail/hotmail account you may already have.

If you are not validating the input and you happen to be putting a form field content in to the mail header, it is likely that the spambot script is sending multiple copies of the email through your mail server and the copy you see is just the one going to you, but there could be dozens going to other email addresses. If you are putting data from the form in to the mail header, you should probably log the it to a file or record it into a database table so that you can see what is really going through your script.

You would use browser keyup/keydown/keypress events - http://www.cryer.co.uk/resources/javascript/script20_respond_to_keypress.htm

Shouldn't your validation logic in your form processing code detect and prevent the insertion of that, assuming you have validation logic in your form processing code?

The var keyword only has meaning in php4 inside of a class and would have no effect on the error you used in your example. Your code should not produce any errors during its normal execution, only for unexpected things. See this recent post for why - http://www.phpfreaks.com/forums/php-coding-help/can%27t-connect-to-mysql-db-from-php-code-on-localhost/msg1505574/#msg1505574

The REMOTE_ADDR that the target/destination server sees (the server where the applications are at that you want to allow/deny requests to) when requests are made from the actual client computers, is the only thing that matters. So far, the only relevant information you have posted appears to be - "when I test from different machine the Remote_Addr is showing correct IP." Was this one of the client computers you want to allow access or deny access (you didn't state either way) and what was the IP address that was correct? (Correct to you doesn't mean anything to us unless you actually tell us what you saw in front of you.)

A local php.ini is read on very page request because it is only available when php is running on the web server as a CGI application and there is a separate invocation of php on each page request.

$errorString; <--- doesn't do any thing. It likely doesn't even produce any php byte-code. You would need to assign a value (any value, even null) to cause the variable to be defined.

You need a mail server in order to send an email. The php mail() function only provides a way for a php script to interface with a local mail server, either using SMTP or through the mail server's command line interface.

What exact syntax are you using in the local php.ini? Have you checked using a phpinfo(); statement if the setting is actually getting changed? What sort of problem are you having, because you would also need to change the post_max_size setting as well?

Displaying user information - what page they are on/last requested, how many are log in, logged in user names... involves storing that information using an easy to access method. Storing it in a session using $_SESSION variables is not the best way, even if using a database by changing the session save handler. The session data is serialized before it is passed to the session save handler, which means accessing any specific part of it where it is stored, such as getting all the user id's/user names would require that you retrieve each relevant record and unserialize the data. Normally, either the existing user table or a separate table is used to store the needed information in a format where it can be directly accessed and this is done separately from any use of session variables in your application (except for using a session variable that identifies the visitor.) Back to the Codeigniter link you posted (the subject of this thread), yes they are storing user/session data in a database and generating a corresponding id that gets stored in the client using a cookie. You can use this side-by-side with your normal $_SESSION variables. It could be added to any application and used to keep track of the user information.

^^^ Yes. A session is just a container that allows variables to persist between page requests. There should be no need to manipulate the actual session or the data in it and the people who try end up with a lot of extra code and special case conditions that can be bypassed. What exactly are you trying to accomplish?

The simplest way of seeing what information is in a http request would be to make a .php script with a phpinfo(); statement in it and browse to the URL of the file. The PHP Variables section (near the end) will list all the information that was contained in the request. For the ip address ranges you listed in your last post above, are those the IP addresses the destination server sees from the proxy server or are those the client IP addresses on the internal network? You have got to tell us exactly what information you are dealing with in order to get a solution that has anything to do with your problem. You have made statements, such as 'I found that the ip address the client returning was different', but you haven't supplied that information to us to help show what problem you are having.

Yes it does clear out old session records.

Not really. On a shared web host, all the databases on any database server can been 'seen' by all the accounts that use that database server (and in fact all the database servers present are usually accessible by all the accounts) and since at least mysql does not have any bad username/password detection and lockout, it is fairly easy to break into someone else's database on a shared web server. Only the strength of the username/password keeps your data safe. Of course, if your site requires good security, you would not be hosting it on a shared server to begin with. The safest and simplest way of protecting session data files on a shared web server is to set the session.save_path to be to a private folder within your account's folder tree. The codeigniter code is used in place of the built in session handling (you don't use $_SESSION variables at all with it.) So, it would require rewriting all your code that sets or references $_SESSION variables. Back to your question. If you did replace the built-in file session save handler with a database driven handler (there are existing php scripts posted all over the Internet), so that as far as your application code is concerned, nothing about the use of session variables is changed, the garbage collection operates exactly the same way as when using the built-in file session save handler. There is a garbage collector function that gets randomly called, based on session.gc_probability and session.gc_divisor settings, when the session_start() code gets executed. In the case of the file based session save handler, files with a last accessed time older than the session.gc_maxlifetime setting will be deleted. In the case of a database based session save handler, records with a last accessed time older than the session.gc_maxlifetime setting will be deleted. You should not rely on the operation of the session garbage collection to do anything but to clean out OLD session data files/records, mainly because it runs randomly (you should leave it running randomly) and OLD session data files can exist for an indeterminate time after the visitor is no longer active on your site. The php source code can be examined to learn exactly how the above is accomplished (I have actually looked at the session garbage collection code - I was curious if the session.gc_probability and session.gc_divisor was truly random or was some count.)

You could always just put the form processing code ON the page where your form is already at?

Actually, since your data is an array of arrays, AFAIK array_unique() won't remove duplicates in each set of 10. You are likely getting duplicates because some of the various fields in each set of data probably contain new-line or other white-space/non-printing characters. You should probably use an editor that has the ability to display new-line/white-space/non-printing characters to examine the data being written to the file so that you can find out why the code is storing what appear to be duplicates. You do realize that your code will be simpler and much much faster if you use a database instead of a file.

There are two (straight forward) ways you can display the error messages in your form - 1) Pass them using a $_SESSION variable (the $errors array that Zurev has suggested can either simply be copied to a $_SESSION variable, something like $_SESSION['errors'] = $errors; or you could use $_SESSION['errors'][] directly in the code instead of $errors[] ) 2) Put your form and your form processing code on a single page. This will also have the advantage of being able to directly redisplay the form data that was already entered so the visitor does not get pissed off about having to re-enter all the data.