$_SESSION is a special array used to store information across the page requests a user makes during his visit to your website or web application. The most fundamental way to explain what a sessions is like is to imagine the following scenario: You are working with an application. You open it, make some changes, and then you close it. That is a session in it's simplest form.

They start with a basic "how to use them" example of setting a username value to the current session and pulling the value back out. They also show the use of the session_unset and session_destroy methods for ending the session. Some security tips are mentioned too - timeouts, regenerating the session ID, destroying them correctly and using a more permanent storage option (by default, they store on the local disk).

Symfony uses the PHP session management sub-system to store tempoary user specific data. When using the sfDoctrineGuardPlugin, or any other application guard, the timeout and lastRequest data are stored. [...] Since PHP has no clue of Symfony it will happily delete all session files that are older than the gc_maxlifetime value. This causes Symfony to logout the user. The user then has to login again. For all "day long apps" that are only used periodically (like time tracking software) this can cause some greif for the user.

His solution is to change the gc_maxlifetime setting in your php.ini file (or just the ini settings) to something higher than what Symfony will use. This can be done directly in your application too by defining the ini value on the fly in your factories.yml config file.

Let's try to understand the reason behind this. [...] Let me now summarize some of the IIS FastCGI settings and PHP INI configuration directive to ensure that everyone is on the same page and which are most important for this discussion.

The two FastCGI settings he mentions are the ActivityTimeout and the RequestTimeout as well as a generic PHP setting that could be a cause of the problem, max_execution_time. He suggests some default values for each of these, but only experimentation will help you find the right balance of these three. It's a great starting place to look, though - especially if you've been battling the problem for a while.

Ever since the upgrade to Wordpress 2.9, I've been having a problem in the scheduled posts in Wordpress. Everytime I set a post to be scheduled in the future, it used to miss the scheduled time and never get posted. When I checked the status of these posts in the posts admin area, each of these posts had the status "Missed Schedule" next to them.

To correct the issue, you need to make a change to the cron.php script for your installation (in wp-includes) to change the default timeout by quite a bit to ensure that the remote call has plenty of time to finish. It seems its related to the version of PHP's curl extension that's compiled into the web server installation.

Caching your database-driven website pages has a plethora of benefits, not the least of which being improved speed and reduced server loads. This article will explain how to set up a simple caching system, and will also address when and where caching might not be appropriate.

She shares her "six lines of glory" that cache the resulting HTML page (after all data has been pulled from the database and rendered) into a cached file with output buffering. On other side of things, there's another script that, based on the page requested, checks to see if a cached file exists. She also modifies it slightly to include a timestamp so things aren't just cached forever.

There's also a recommendation in the comments of the post to use the APC caching extension that's already built. Of course, this can only really be used if you have access to install it on the remote machine (not an option on things like shared hosting).

I have some very time consuming scripts running through CRON - some nice web scrapping jobs. They are not processing-intense, but rather slow because of slow websites. All these jobs are really hard to divide in to separate scripts (another article), so one script should have no limits to run for hours. However, web servers don't like it by default.

He show how you can use the set_time_limit function to free your script of the timeout limitation (which can be a good and bad thing) or having your script output something, like a "processing" message, as it runs through the loop to keep the timeout away. You can also use the ignore_user_abort function to continue the process even if the user hits the stop button or otherwise closes the request.

There are several reasons that PHP could not be able to connect to MySQL. [...] Or, perhaps the entire server is offline.

The mysql.connect_timeout setting in the php.ini is supposed to handle this sort of instance, but the default is set tpo 60 seconds. It's only apparently used when the server is completely offline and, in his opinion, is set way too high. He's proposing a patch to the MySQL extension to change this setting's default to shorten it to something a bit more reasonable.

It often happens that when you're building a web page or app, you may want to include some content from a remote server. Say that it's some statistic figure that the remote outputs as HTML or TXT and you then want to retrieve it and either do something with it or directly display as part of your own page. And you're working in PHP.

PHP provides a fancy way of opening and including files directly over HTTP, which they call "URL wrappers". As tempting as it may seem, in the long run doing remote opens with URL wrappers is not the best practice. So here's what I came up with when needing to do this kind of caching thing in my own scenarios. It requires you have the cURL module installed and that the webserver can read and write from /tmp.

They provide the short script that does the work inside a function (easy to drop into a class), and grabs the remote file, and pulls down to /tmp for the script to use. It even allows you to specify a timeout for the file, forcing the script to grab a new copy every so often...]]> Wed, 18 Jan 2006 07:19:36 -0600