Finally after days of hunting I discovered the cause and fixed this annoying bug (just for Windows users as you will see).

In setup_smarty.php I replaced:
ini_set('session.cookie_path', dirname($_SERVER%22REQUEST_URI%22));

ini_set('session.cookie_path', str_replace( "\\", "/", dirname( $_SERVER%22REQUEST_URI%22)));

because dirname() under Windows returns "\" and not "/", and cookies with the path set to "\" are not later recognized by PHP/Tiki.
Please correct str_replace argumentss if you are aware of other problems with *nix platforms.

BUG FIX Added: 12/17/2004

See my (Qo027) notes below

I found that Tiki was hard coded to look for PHPSESSID in the session cookie so I corrected this in two files tiki-setup.php and tiki-login.php. Once I did this my problem with cookies not enabled no matter what my session.name in my php.ini was set to went away. I did my modifications to 1.8.4. Here are my changes:


Old Code

if (isset($_REQUEST["PHPSESSID"])) {
} else if (function_exists("session_id")) {

New Code

if (isset($_REQUEST[ini_get("session.name")])) {
} else if (function_exists("session_id")) {


Old Code

// Alert user if cookies are switched off
if (ini_get('session.use_cookies') == 1) {
        if(!isset($_COOKIE['PHPSESSID'])) {
                $url = 'tiki-error.php?error=' . urlencode(tra('You have to enable cookies to be able to login to this site'));
                header("location: $url");

New Code

// Alert user if cookies are switched off
if (ini_get('session.use_cookies') == 1) {
        if(!isset($_COOKIE[ini_get("session.name")])) {
                $url = 'tiki-error.php?error=' . urlencode(tra('You have to enable cookies to be able to login to this site'));
                header("location: $url");

If Tiki is installed in the document root directory, for example www.mytiki.com the PHPSESSID cookies it sends to the browser have the Path field set to '\' instead of '/'.
When this happens the login doesn't work and the page is just reloaded.

It Tiki is installed to a subdirectory, for example www.mysite.com/tiki, the PHPSESSID cookies have a Path set to /tiki and the login works fine. Note that the Path is not set to \tiki as coherently I could expect after the previous case.

You can check these behaviours using a Mozilla/Firebird browser.
Obviously the php.ini setting is as usual: session.cookie_path = /

What makes everything even weirder is that if you check the 'Remember me' checkbox the login works fine in any case !
Has anybody a suggestion about what could be the cause ?

Tried on:
  • Tiki - from 1.7.x to 1.8 HEAD
  • Windows - 2000, XP and 2003
  • Apache - 1.3.x and 2.0.x
  • PHP - 4.3.3 and 4.3.4
  • Also tried EasyPHP 1.7


I installed a fresh Tiki1.8 got from CVS HEAD under a new machine (tried Windows 2003 and XP) having Apache 1.3 or 2.0, PHP 4.3.4 and Mysql 4, all got from official sites and with basic and quite standard configurations.
I created an empty db and populated it using tiki.sql.

The site shows up, I logon with admin/admin and Tiki forces me to change the password, but after that it doesn't allow me to logon.
What happens is the following:

  • Tiki creates a sess_* file (in the correct session.save_path folder) and sends to my browser a cookie when I load the home page with the login prompt
  • When I enter user/password and click on 'login' a new sess_* file and new cookie is created (and sent to my browser) with the user name (admin) inside
  • The login is not done and the home page with the login prompt is showed again
  • Of course a new sess_* file and cookie like the first ones are created and sent to browser
  • Anyway if the remember-me checkbox is checked the login works fine, and a regular tiki-user-<sitename> is received by the browser

  • I applied the solution provided below to last 1.8 CVS sources, but the bug is still there. I think the cookie management has to be analyzed thoroughly but I need the help of a cookie and PHP sessions guru.


marcius said:
Since 1.7.x I encountered problems with the login.
There still is a problem in my 1.7.x install that requires the user to check the 'remember me' box to succeed in logging in.
The problem wasn't fixed by an upgrade to 1.8.
This bug is BLOCKING: just think if I disable the 'remember me' checkbox.
I am not the only one that has this bug: in the IRC channel I met 2 persons complaining for the same reason.

russelleon said:
I have the same problem. If this helps, the only way to login is to run tiki-install.php first. I then skip the db creation, and go into tiki-index.php. I then login again and its fine. As long as I keep that session active, I can log in and out at will, using any registered user i want. Once I close the browser, and then go back, I have to rerun the tiki-install.php again, or I cannot login as anybody. It has to be something being initialized in the install that is not being done in any of the other tiki-*.php files. Not a PHP pro, so any help is appreciated. This is happening on both an NT and 2000 server, under either Apache 2 or IIs.
I added this to the top of my tiki-index.php file, and now the login works correctly.

ini_set("display_errors","0"); session_start();
Not sure if this is the best solution, but it works for me. If you don't turn the display errors off, the session_start(); triggers an error message.

mcoyote said:
I installed Tikiwiki 1.8 RC1 with EasyPHP 1.7 on my Win2k and WinXP boxen and experienced the same problem. Basically, the first login as "admin" with the password change works great and everything else I do in that web browser session works out.
The minute I close the browser or open another one I can't log in as anything again, even if I establish groups, assign permissions, whatever. The only way out is to completely re-install again and then I still only get one session.
I followed the suggestion above:

ini_set("display_errors","0"); session_start();
...at the top of "tiki-index.php" and everything appears to work now.

You can turn the error messages back on if you are debugging something.

starrrider said:
I've installed Tiki - I don't even want to think about how many times now - and nothing seemed to change. Nothing I did let me back in a second time.
This time - I'm in and it is working properly - so far. The only difference that I can see is that - after the first manditory password change, I went into Features and turned on everything. Then I changed my admin password a second time. When I logged out I still could not manage to re-enter - but russellon's method of entering through Tiki-Install.php worked. Again I added the 2 lines mentioned above at the top of Tiki-Index.php and now I can get in every time - without playing games.
All that I can say is: Thank you russellon

david2000 said:
Thank you very much for this fix. It was driving me crazy, no logs in apache, no problems with mysql. I bet it was a really hard to find bug. thanks again

sbindon said:

Remember if you set your homepage to the articles home (tiki-view_articles.php), that it includes the
ini_set("display_errors","0"); session_start();
I forgot to do this and I sure did kick myself.

Qo027 said:
I didn't want to implement the fix above because on the surface it seemed to take some functionality away and the session_start() code would have been in the tiki-setup.php code (or the called code somewhere)... So I looked into tiki-setup.php and found that there is an assumption in the Tiki 1.8.4 code on line 280. The assumption is that the session.name parameter is set to PHPSESSID. My Tiki was working fine until I change my session.name in my php.ini. Once I changed it back to PHPSESSID everything worked as expected again. So I believe this needs to be updated. I will test some more on Monday (12/20/2004) to see if there is a generic fix to this but for now make sure your session.name parameter in your php.ini is set to PHPSESSID. Obviously, there are some very legitimate reasons for changing the session.name parameter, check with your server admin berfore changing this back to PHPSESSID. Hope this helps.

I did some more digging and I made some changes to the tiki-setup.php and the tiki-login.php that will make the PHPSESSID requirement go away. I added my code to the bug fix at the top of the page.

Page last modified on Saturday 18 December 2004 03:15:40 GMT-0000