Solution to the problem: Notice: SSI.php was unable to load a session!

Started by Sardtok, April 06, 2007, 09:41:45 PM

Previous topic - Next topic

Sardtok

Hey,
after some work, I've found the solution to this:
1. Disable local cookies and enable subdomain independent cookies (I do this because some people use www and some don't)
2. Do not save any files that get loaded prior to SSI.php as Unicode (I had mine saved as UTF-8 and it caused headers to get sent as soon as the files were opened by Apache).
3. Make sure there are no characters prior to the <?php tag's start

You don't have to require/include SSI.php before you do absolutely anything else.
Even having the include/require inside another document included by whatever document you are loading works fine.
Heck, I even have mine inside a header included in one document included in another document after doing some variable declarations and it still works.
Just make sure no characters are printed to the HTTP stream before SSI.php is included.
This will happen if you use Unicode (well, at least with UTF-8 haven't tried with UTF-16, but I suspect the same thing happens).
How do you get Unicode to work then?

You might have to change the structure of your site.
Anyway, something like this should work:
Use one ANSI encoded .php file that requires SSI.php and whatever other documents will be included/required later in the document.
All files included after SSI.php can be Unicode, as it will only result in the Character-Encoding header being sent, since the headers required by SSI.php have already been sent this doesn't result in headers_sent() returning true. (At least that should be the only header that gets sent by the first Unicode php document prior to you possibly sending some other headers)...
So, for instance a structure like this:

index.php - ANSI
require_once - SSI.php
include_once - header.php
                      index.content.php
                      footer.php

You could of course choose to use a bit of a different structure, where the content is a page that is gotten with a GET variable or something similar, but this should fix the occurrence of this problem.
As far as I know that should be all the problems.
If it hadn't been for the fact that I had just converted my site to UTF-8 minutes before starting to integrate SMF, I would never have found this out. So I guess it was lucky I did. ;)

Advertisement: