kicken

An flock call may fail due to various reasons. You should always check for success before attempting to use the file. Under normal operation the call will eventually succeed and your script can continue. In abnormal conditions something may cause it to fail in which case your script should either re-try or just close the file an abort. There's not much point in calling flock at all if you're just going to ignore it's result and do whatever you want with the file anyway.

Reading a file line-by-line may be slightly slower due to having to run more read operations. I don't think the difference in speed would be all that significant though. If line by line does result in a significant decrease in performance you can improve things by reading in chunks rather than line by line. For example read out 10MiB of data at a time, then split that into lines and process each line. If the last line is incomplete prepend it to the next chunk of data that gets read. By doing this you help reduce the amount of reading done by reading in larger chunks, but still keep memory usage at manageable levels by controlling how big of a chunk you read.

When you choose 6 images you are probably exceeding PHP's limit for the maximum upload or post size. See the relevant INI directives post_max_size and upload_max_filesize. Make sure they are configured to be large enough for the amount of data you want to upload.

Checking the manual for sendmail_from shows that it is a PHP_INI_ALL level setting which means you should just be able to set it using ini_set also rather than muck about with a custom php.ini file. ini_set('sendmail_from', $myemail); mail($myemail, $subject, $message);

create a file called php.ini with the content: [PHP] sendmail_from = your@email.com Then upload it to the root folder of your hosting account. For some hosts this is enough to create your own php.ini files. If that does not work you can either contact your host to find out how they handle it, or follow the second part of the error's suggestion (or custom "From:" header missing) and add your custom From: header using the fourth parameter to mail

Migrating from PHP 5.4.x to PHP 5.5.x That covers things to be aware of regarding differences between the two. Look through it and see if you have used any of the new features. If phpinfo() is disabled, using ini_get_all may work as a way to check INI directives. You could also use extension_loaded or function_exists to test if various extensions or functions that you need are enabled.

What kind of caching is appropriate is dependent on the nature of what that stuff is. Language translation strings for example do not change from user to user, so caching them in the $_SESSION array is not ideal. Caching them in a file you can include, or into some shared cache would be better as you're then not wasting space storing a separate copy of all the translation strings for each visitor. A user's preferences though are ideal to cache into the $_SESSION array as those are dependent on each user. You have been provided plenty of information as to what is possible for ways to cache data on an application-level, but you seem to be choosing to ignore all that and instead continue to just dump everything into $_SESSION, while simultaneously getting upset at people for some reason.

You could add a call to gc_collect_cycles after resetting your $pricesArr variable. Unless your running into some problems due to the memory usage though I wouldn't worry about it that much. Processing a huge result set is going to require some memory. PHP does not always run garbage collection immediately, it will wait until it deems it necessary.

For a shared memory cache you would typically use something like Memcached or APCu. You'd simply store your string as a serialized array or in json format. Another alternative is to simply store the strings in a PHP file however and include it when necessary and store the data into a variable. For example: In the strings file: <?php return array( 'string1' => 'Something' , 'string2' => 'Something else' //, .... ); To use it: $strings = include('strings.php'); echo $strings['string1']; You could move the strings permanently from the DB to the file and manage them there, or you could generate the file on demand if it doesn't exist or needs updated. Before any of this though, I'd wonder why you have these thousands of strings and why you feel it's necessary to load them all to begin with. Surely you'd only need a small subset of the strings on any given page and could simple query for those strings.

what kind of information are you looking to cache?

strtr

You'll probably need the admin password to configure IIS so until you can get that you'll either have to use Apache or PHP's built-in server. If you choose apache I'd suggest trying the pre-packaged solutions like WAMP/XAMPP even if you don't intend to use MySQL. You could also try installing it and configuring it manually if desired though.

What you'll want to use is Google Maps API's Geocoder service. Have a look at the documentation for the details. It's usage is fairly simple: var request = {address: 'Your address here'}; var coder = new google.maps.Geocoder(); coder.geocode(request, function(result, status){ if (status == google.maps.GeocoderStatus.OK){ var location = result.geometry.location; //create marker using location. } }); If your list of places is fairly static, you should probably consider just manually obtaining the proper latitude and longitude and save the result to your database as additional columns rather than geocode it each request. You then will not have to worry about google blocking your geocode requests and the map will load significantly faster. I've moved this thread to the Javascript forum since it is primarily a Javascript question and not a PHP question.

The typical cause was running with magic_quotes_gpc enabled which would automatically apply addslashes to all input data and then escaping the data again before putting it into the query without first undoing the magic quotes effect.

Even with mysql_real_escape_string there should not be any kind of visible escaping after your data has entered the database. If you are seeing things like backslashes before quotes within the database when querying with phpMyAdmin then you're actually double-escaping the data which is incorrect. Using quote() as a replacement for mysql_real_escape_string is fine, however as suggested you should move to prepared statements as soon as you're able to. Note that unlike mysql_real_escape_string the quote method will add quotes around the string so you'll need to either update your queries to not include quotes or strip the leading and ending quotes.

What is being suggested is you just set the cookie regardless of if they want to set custom preferences or not. You'll likely have some common file you include on each request to read the preferences. What you do is just add code there so that if your preferences cookie is not found, you set it. if (empty($_COOKIE['preferences'])){ setcookie('preferences', 'whatever'); } If the cookie does not exist, you can assume that they are not allowing it. By their second page visit either it will be set already or it wont be due to being blocked. On your preferences page you can then just check if the cookie exists and if not, show your cookies must be enabled message. Unless the preferences page is their very first page visited (unlikely) your message will be more or less accurate. As for the size of the cookies, my memory suggests that around 2k was the upper limit, however if you think you'll need to store a decent amount of data, I would recommend generating a random ID and storing only that in the cookie. You can then use that to look up the preferences in your database. This is essentially the same principal that sessions use.

If the image names really are the same as the field letter you could simplify the code to just $letter = strtolower($data['judges_ccpadv']); echo "<img src='images/{$letter}.png'>\n";

Use a sub query to get the number of the most recent, then use that to join to the original table, or in your where clause condition. Eg: SELECT * FROM table INNER JOIN (SELECT PostId, MAX(version) as version FROM table GROUP BY PostID) mr ON mr.PostId=table.PostId AND mr.version=table.version Make sure you have an index on PostId,Version

Only takes about 2.22 seconds for me using the PDO code and an InnoDB table. Using a MyISAM table takes about 0.25 seconds with the code above. Alterting the code above to add beginTransaction/commit calls drops the time on an InnoDB table to about 0.23 seconds. $dbh->beginTransaction(); do { ... } while (); $dbh->commit(); You could try wrapping your loop in the stored procedure in a START TRANSACTION...COMMIT as well and see if it helps.

function exception_error_handler($errno, $errstr, $errfile, $errline ) { throw new ErrorException($errstr, 0, $errno, $errfile, $errline); } set_error_handler("exception_error_handler"); There, now you've converted most (but yes, not all) the traditional errors into an exception. That will cause even something like an E_NOTICE to throw an exception, if you want to avoid that then you'd have to add some extra logic to the error handler. The manual page for ErrorException has some extended implementations in the user comments or one could DIY it. For the final few percent make sure to configure display_errors off and set error_log to log them somewhere.

Depending on how you have PHP setup with the server, how PHP is configured, and how the server is configured then not catching an exception could range from getting a stack trace printed to the screen to a simple 500 error message with no useful information printed. I believe what Jacques1 is suggesting is that you should make sure PHP logs the error rather than reports it, and then returns the 500 error. You could then configure the server to send back a nicer page for the 500 error by using it's error document configuration That's all fine and dandy if you have that level of control over your setup, but you may not (ie, shared hosting) so I personally dis-agree and would rather perform a generic try/catch at the top level and generate an error page manually with PHP. It's less prone to mis-configuration issues and does not add a lot of extra programming work or overhead. I can't speak to the availability of physical books with PDO as I've not touched a PHP book, but there is plenty of information on the internet regarding how it is used, and the manual is an excellent reference. I would highly recommend you stick with PDO, primarily because it's API is much simpler when it comes to doing prepared queries with parameters compared to MySQLi's.

It can be useful as a hint to PHP that the variable is no longer necessary and the memory can be collected. If you're doing something in a loop and might end up reading in a lot of data on a particular iteration adding unset can help get PHP to collect that memory sooner. The primary reason I use it however is to break references, for example if you use a foreach loop with the value as a reference: foreach ($array as &$value){ //do stuff } After the loop $value will still be a reference to the last item of the array so if you happen to later on do something like: foreach ($array as $value){ } you'll end up over-writing the last index with each of the indexes before it. Adding unset($value) after the first loop will prevent this by breaking the reference between $value and the last index.

You just need to do some reading about how to understand JSON then you'll know exactly how to access any property you might want to access. json_decode($json, true); will turn the json string into a PHP array with the property names as array keys, so if you have the json: $json = '{"myProperty": {"subProperty":"This is a value"} }'; you would access the property subProperty as: $array = json_decode($json, true); $value = $array['myProperty']['subProperty'];

flock will wait if it cannot acquire the lock. If you have two different scripts trying to get a lock on the file then one of them will succeed and the other will be blocked until the first releases the lock.

Not sure what you mean by it being missing. The binary flag is mentioned. They just don't list r and rb as different modes because it's unnecessary.