SWFupload cannot write data after upgrade to PHP 5.3
The Upgrade - PHP 5.2 to PHP 5.3
If you provide me with a better tool, I'll use it. I recently upgraded a client's server from PHP 5.2 to PHP 5.3 to be able to use dynamic static calls in my code. Yes, there are PHP 5.2 compatible solutions to my problem, but this code is much cleaner and, quite frankly, I like it.
The Problem - SWFupload Doesn't Work Anymore
My client contacted me the next day and told me that the PHP 5.3 upgrade had broken Multiupload for VirtueMart, an extension that saves him a lot of time. Upon looking into it, I found that rather than being built on awesome HTML and JavaScript, it was built with stupid crappy Flash, specifically with a tool called SWFupload. I installed the extension on my Joomla development environment and switched between PHP 5.2 and 5.3. Sure enough, I was getting a 303 "See Other" error whenever an upload completed. The files were being uploaded, but they weren't being saved.
How Sessions Play a Role
After I figured out how to turn debug mode on for swfupload, one of the first things I noticed was that the session handling wasn't right. The context of the session was changing between requests in PHP 5.3, whereas it was the same between requests in PHP 5.2. Not only was my session data disappearing, but the user-agent string changed. In PHP 5.3, the debug data stated that the user-agent was Adobe Flash, whereas it was returning as Firefox under PHP 5.2
And of course, Cookies come into the pictures
Long story short, the solution to the session issue involves cookies...sort of. In PHP 4.3.0, a new runtime configuration option called use_only_cookies was introduced. This option, when set, prevents sessions from being started based on anything besides the cookie value of the session ID. In PHP 5.3.0, the default value of the use_only_cookies option changed from 0 to 1. What this means is, no matter how many hours I spent trying to force a specific session by passing the ID or name to the session handler, the session handler didn't care. It was like "sure, yeah, uh huh...what's the cookie value?" Technically speaking, the Adobe Flash script was actually making the HTTP request to save the data, not my browser. So PHP was looking at the cookie-based session ID being passed by Adobe Flash, instead of the session ID that I was trying to set manually.
The Solution
There are, of course, several different ways to solve this problem, but they all boil down to one thing: you need to set the use_only_cookies value to 0 if you want to start a session using a dynamic session.name or session.id. Here are some examples:
In your php.ini file:
session.use_only_cookies = 0;
In your .htaccess file:
php_value session.use_only_cookies "0"
session.use_only_cookies
At runtime:
ini_set('session.use_only_cookies', 0);
Conclusion
Upgrading to PHP 5.3 isn't such a daunting task, as long as you're armed with the right information. The only other issue that I ran into was the presence of depreciated function messages, but those don't appear under normal deployment server conditions.
