This isn't the first time it's happened but before it seemed to fix itself:

erors dosen't fix them selves

can u show the code visiblecheck.php?

or you fixed it?

It uses the same check as this site so its wont be just the mods site. Seems like its just you as no one else is getting those and there is no reason too either

if it hadn't reason it wouldn't show up xD
i think

Well the only reason that would show is if the $user suddenly becomes empty or if the visible string for whatever it is because empty which is almost impossible unless the database disconnects for some reason

i fully didn't get the idea , but the main i understood :d

If it can happen to me, it can happen to anyone (I refer to the useragent bug )

Not true, it might just be a conflict with the sessions. However as I stated before, you would also get it on this site as well but no one has meaning it could have been just a problem with the connection to the database as the delimiter was empty which is not possible

Well seeing as the mods site no longer exists I'm going to call this fixed.

This bug has been deemed [Fixed] by an eoCMS developer. If you dispute the Fix, please PM a developer, giving details of why. This topic can then be unlocked allowing for further discussion.

Not fixed, i just found out the problem. Its due to a conflict of cookies when you have multiple eoCMS installations on domain, subdomains and in different folders

is this fixed yet, it will be interesting to see how this affects or works with "child boards" when the time comes..

the more work you do here supporting multiple domans and multiple installs and folders per server, the easier it should be to add "child boards" later..

I have found the problem. Its because the PHPSESSID cookie is set to / so it affects everything. A work around would be to use the COOKIE_NAME constant as the session_name, however that would mean the sessions stored within the cookie can no longer be md5()

We could instead change the path of the session cookie. Paul any ideas?

which session path are you talking about

if you mean the js accessible cookie, then that allows you to define a "scope" which includes a path. This will need a bit of multi browser testing tho, as there are some known issues with certain browsers

If you mean the php session path, thats set in the ini, and should not conflict with other sessions, except under extreme circumstances and even then it is avoidable (also via the ini)

if you mean "the scope on the php session" with reference to the path being "/", this should not be the case.. if it is, more research is required.. check this

this is an extract from a easyphpcalendar post, but it may help..

Its basically saying, on some servers, you have to manually set the path to where you session data are going to be stored (as opposed to using the ini entry)..

check the page, they have an example.

I like ur idea of MD5 the cookie, should keep that even if it requires a custom session function..

also check this:

I was thinking more of
http://www.php.net/manual/en/function.session-set-cookie-params.php. If you check eva's site, the PHPSESSID cookie path is set to / as well meaning it would be used in other folders and not just /eco which is the problem, because eoCMS uses the contents of the md5(session id) contents of the eoCMS cookie to log you in again when that session expires, and if that session is being carried across to other sites, it causes the problem TGPEG has described above.

I believe I have fixed it. The setcookie() was setting the path incorrectly, it will now set it with the folder if it is in one. If anyone running the SVN version is having trouble with logging in to subdomains, the solution is to change the cookie name within the config.php file to something like eoCMS2 as browsers will accept 2 cookies with the same name but from different subdomains but PHP will only return one of them and its pot luck which one it does

Paul in your installer... Is it possible to change the Cookie name that is defined within the config?
EDIT: Paul, in your installer, if you visit it with a filled config, it empties the contents of it

You might have to make an article with instructions on that so people actually notice it.

when it gets sorted.

the cookie final set name should be the cookie name plus the sitename, that fixes many problems..

cookie in installer: yes, the default one.. but to set it with the site name (or any other user input algorythim) will be painful, because that is written BEFORE db info and access is required. something can be sorted tho. see suggestion above

revisit installer: that maybe the new write test, if so that will need to be changed... that should not be the case tho, as no data is written..

Fixed in SVN, it wont display that now, however I wont lock it as the sessions still conflict, I have an idea on how to fix but not yet implamented

Ok do you mind if I resticky it so you font forget?