Pantheon Requires session.save_handler set to files

Is this code still working for you? I tried adding the same code you used

ini_set('session.save_handler', 'files');

As well as what's recommended in pantheon's handbook:

if (!ini_get('session.save_handler')) {
  ini_set('session.save_handler', 'file');
}

But I'm still getting the following errors:

Warning: session_start(): user session functions not defined in /srv/bindings/5e3271543... on line 12 

Fatal error: session_start(): Failed to initialize storage module: user (path: ) in /srv/bindings/5e327154... on line 12

Update: I never could get PHP sessions working on Pantheon. Switched to using cookies instead.

I still don't think this works and Pantheon support doesn't offer help. Seems like cookies are the only way to go here?

No not at all. This post is the highest on Google for the Pantheon issue/bug in general with session_start(), but you are saying the patch still works for you on Pantheon sites with CiviCRM and Community Media Starter Kits? I realized after the fact this is the wrong place to post, but Pantheon certainly doesn't help you out here so I thought maybe people finding this thread would know something.

I can start a stackoverflow question as that is more appropriate.

I'm confused. I've used this patch which hasn't caused any issues, but Pantheon seems to have conflicting messages about using the default PHP session handler.

In the link posted by Jen suggests enabling local sessions and save to file, but another Pantheon article on sessions with Wordpress suggests that using PHP's default session manager -- temporary files on local disk -- isn't supported for their distributed environment and provides a library to save sessions to the database.

Is Drupal's session not available when CiviCRM is being installed? (The only other place this seems to be an issue is with the extern/* urls such as rest.php, soap.php). And if it can't access Drupal's session there won't it default to the PHP default of using temporary files?

@kreynen, I don't think this has anything to do with WP in particular. From Pantheon's documentation it has everything to do with their system of different containers being able to respond to the same request:

Despite this general prohibition, there are a number of WordPress plugins in common use that rely on PHP’s built-in support for sessions that is based on storing session data in the filesystem. While this technique works fine in a dedicated server or virtual private server environment, it breaks down entirely in large scalable architectures such as Pantheon, where any given request for a user might be handled by a different application container. If a plugin does attempt to use the built-in session mechanism, all page requests will fail with an error related to session_start() or $_SESSION.

I think the confusion lies in that it won't fail ALL the time, since there's still a good chance the same container will respond. But it will fail spectacularly when a different one responds.

I believe that is what is happening to me even though I added the patches to force the session to files. Every so often contributions with Paypal will fail with a 502 and it will continue until caches are cleared (and even then doesn't always work).

So I think that the solution instead is to have it use Drupal's session handler, which is what CiviCRM will normally do, it just avoids bootstrapping Drupal it seems on the external scripts.