Showing posts with label PHP. Show all posts
Showing posts with label PHP. Show all posts

2014-04-13

GoDaddy PHP Upgrade from 5.3.x to 5.4.x Kills Sessions on IIS/Windows

The problem...

I spent a sleepless night on this one, but finally figured it out...

NOTE: This issue should only affect those on the GoDaddy Windows Hosting plan using PHP on IIS, but if I'm mistaken, please post your details and solution [if discovered] in the comments!)

I work on a PHP website that is in the process of being rewritten in ASP.NET MVC.  Because of this, the site has been set up on GoDaddy on a Windows Hosting plan with PHP running under IIS.  All was well through PHP versions 5.2.x and 5.3.x, but tonight needed to upgrade to 5.4 while we wait for the migration to be complete.

The site came up fine until I hit pages that required Session data.  It seemed that Sessions stopped working with my existing code.  After much troubleshooting, I discovered that the sessions were being written on the page setting the data, but when I hit another page that wanted to use said Session data, the Session was blank as if created new.

It turns out that there is a discrepancy on GoDaddy on the session.save_path used for PHP 5.2.x/5.3.x and PHP 5.4.x when hosted on the Windows hosting plan.

session.save_path comparison

PHP 5.2 and 5.3

session.save_path = C:\Windows\Temp\


PHP 5.4

session.save_path = D:\Temp\php\session\

The solution...

Now, I don't know if the directory doesn't exist, or if there aren't proper permissions set on the directory, but for whatever reason, it doesn't like that path.  After reverting back to 5.3.x and discovering the path difference, I re-upgraded to 5.4.x and forced the session.save_path to C:\Windows\Temp\ using a ".user.ini" file in the root of my site on GoDaddy.

What to do...

  • Create/Edit ".user.ini" in the root of your site and make sure it has:
    session.save_path='C:\Windows\Temp\'
  • GoDaddy Control Panel | IIS Management | Recycle App Pool
    (This will ensure the PHP config overrides in ".user.ini" are loaded and used)
  • Enjoy access to $_SESSION again!
I hope this will save someone else a sleepless night.

2008-05-14

PHP fails to load MySQL Extensions claiming "The specified module could not be found" on Windows

I ran into this issue tonight after setting up Apache 2.2.8, PHP 5.2.6 and MySQL 5.1 on Windows XP SP3. I installed Apache using their installer and then manually configured httpd.conf. I downloaded the non-installer zip version of PHP; extracted it, saved a copy of php-ini-recommended as php.ini and manually configured it.

I correctly set the PHPIniDir setting in httpd.conf and set the correct extension_dir. I confirmed so by bringing up a page with phpinfo() called and it was showing my other extensions loaded. I'd comment one out (like php_gd2.dll) then restart Apache and refresh the phpinfo() page. The gd information disappeared, so I knew the settings were correct.

After a bunch of searching, I finally found a newsgroup post that pointed me in the right direction. there is another dll called libmysql.dll that comes with PHP (but is in the root PHP folder, NOT the ext folder.)

Both php_mysql.dll and php_mysqli.dll depend on this DLL. The fix was to copy this file to the WINDOWS directory. Once I did that, I restarted Apache and refreshed my phpinfo() page. There they were. Huzzah!

In my searching it seems people may run into this issue because of a few different things; so I'm publishing what I think is a good plan of attack for discovering what might be the problem when you can't get the MySQL extensions to load in PHP:

  • Confirm the extension_dir setting in php.ini is set correctly (trailing slash is required on Windows; I'm not sure about other operating systems. Example: C:/php/ext/)
  • Confirm the files exist in your extensions directory and are spelled correctly.
  • Ensure libmysql.dll is copied from the root PHP directory to the Windows directory. This is extremely important if you've upgraded PHP as well and have an older libmysql.dll in the Windows directory that may not work with the newer PHP code. Make sure the current PHP version's libmysql.dll is copied to the Windows directory.

If you have discovered anything I may have missed that would help others that also run into this issue; please leave your feedback here.