Sessions and Cookies

It appears to me that sessions and cookies in concrete5 are simply broken, my guess being that C5 is doing something that breaks their persistence. I have seen a number of posts on sessions where C5 interferes with session variables. The fact is that no matter what I try or whose advice I follow I can't do the most basic thing with sessions or cookies -- things I have done dozens of times on other non-C5 sites. I have a login page where, after the user has successfully logged in, I try to set a session variable (or a cookie) as so:

$_SESSION['etivisitor'] = $mid;

When I echo the variable it is set.

But then when I go to another page and try:

if (!isset($_SESSION['etivisitor'])) {

the STATEMENT gets executed meaning the $_SESSION['etivisitor'] variable is no longer set.

I have tried this with and without session_start(). I have also tried this with cookies. The variables just do not persist. Please, if anyone knows what is going on here or if there is something obvious I am missing (or something stupid I am doing), let me know. Thanks.

I love the design of C5 but the deeper I dig the more it seems like it isn't quite ready for prime time. The great design may very well still be worth the growing pains over the long run but the "gotchas" are starting to pile up. Again, any help would be appreciated.

View Replies:
andrew replied on at Permalink Reply
concrete5's authentication uses session exclusively, meaning if you can login to your website, then sessions HAVE to be working for you. This is the case for every website that runs concrete5, so I highly doubt there's some kind of problem with it, in a large sense.

That said, it's possible that there's something strange going on with your server. In certain cloud setups we've had issues with sessions being server-based, but different servers handling different load, and $_SESSION not being consistent across them. Could that be what's happening? Are you able to login to your server?

Another thing - you shouldn't have to specify session_start(). concrete5 already takes care of that when it loads concrete/startup/session.php.

Finally – I take a bit of umbrage regarding the idea that we're not "ready for prime time." Bug-free? No. Feature-complete? No. But I think our feature list strongly competes with any other major CMS out there (and our advantages are, as you've outlined, pretty clear.) I'd be curious as to what other roadblocks you're running into, so we can hopefully get them sorted out :)
wwwdev3 replied on at Permalink Reply
I wanted to strike the right balance between my admiration for many aspects of C5 (especially the in context editing which is great) and what I perceive as "not ready for prime time" issues. Search, for instance, is a completely inadequate feature within C5. The whole view.php/single page requirement frankly seems convoluted (there really is no reason to make a distinction between single page templates and regular templates that may be used 1, 2, or 3 times). Also, form validation is pretty weak, to the degree that there is no check for an "@" sign in an email field (pretty basic stuff there). And there are other issues.

But having said all this, I am hoping that C5 matures quickly as the attraction of the basic concept gains ground. It is easy to poke at the imperfections (and they are frustrating) but I want to make clear there are things about C5 I love.

However, sessions is not one of them.

There seems to be a definite persistence problem (as clearly outlined in my initial post) and when I take C5 out of the picture everything works fine. I have no problem accessing/logging into my server and as I have said when I simply put up a page with no C5 involvement, sessions and cookies work just fine. This is something I have done dozens of times on many different servers but put C5 in the mix and things just break. I put in session_start on the off chance that would help things but it didn't work and I don't have it in the code now and things still do not persist. Again, I would point out that there are other posts out there as well complaining about session issues so I just do not think you have nailed this.

But finally, I don't want this to be a bitch session (I was venting somewhat last time because this problem is frustrating). I'd just like to figure out what is wrong and how to fix it. I would love to hear from anybody with any insights into what is going on. Thanks in advance for the help.
andrew replied on at Permalink Reply
I can imagine it's frustrating. My reply was a bit bitchy as well ;) so I apologize for that. Do you have particular code that's not working for you? Where are you trying to access the $_SESSION array? I'd be happy to take a look at it.

I agree that search isn't quite ready for prime time, either – but this is a frustrating one, because others have said the same (including Franz) yet no one can quite point out exactly how it might work better, and still be something that can scale, work without a lot of configuration, and work out of the box on any website. I'd be very happy if we could solve that problem, however – we're up on now and are actively taking patches through its Pull Request interface.

Regarding your other concerns: we'll probably just have to agree to disagree on single pages vs. templates: I'd hate to see "Login" and "Register" and Dashboard pages listed in my templates menu every time I wanted to add a page to my site; I think the single pages vs. page types makes it nice, because you can use the same MVC syntax/approach for extending the dashboard and your own site. I will agree that it does lead to an interesting learning curve at first, and may take a second to "get." We're adding an "email" input type to the form block for the next version of concrete5, and our built-in email fields (For things like user accounts, etc...) do, of course, check for valid email addresses.

Thanks for continuing to talk about this – we're pretty close to this so we sometimes get defensive but I think it helps everyone when we (myself included, of course) can talk about this stuff and hash it out.
jordanlev replied on at Permalink Reply
I have used the $_SESSION variable successfully on several sites, so I'm guessing this is some kind of issue with your server setup as opposed to C5 itself. I just do the normal thing too, without calling session_start() first.

Your comment "I tried using cookies too" sounds like it might be a potential issue -- do you normally not have cookies turned on in your browser? C5 sessions are cookie based so you would need to have that enabled in order for the session to work. And also make sure you're testing this over the course of a few different page calls -- session data isn't available to the server until it's gone out to the client and come back again in a subsequent request.

Sorry if I'm stating the obvious, just tossing out ideas because it is not a normal problem (at least that I've ever had).

As for the "not ready for prime time" comment, I personally disagree with that as I've used C5 successfully for dozens of sites over the past year and it has worked out great pretty much every time. Of course the kinds of sites you're building may be different than what I'm doing, so maybe instead of "not ready for prime time" you mean "it doesn't do everything that I personally want it to do" :)
caffeineborg replied on at Permalink Reply

Did you get any where/ resolution with the $_SESSION issue for concrete5?

I, too, have a situation where I have set a $_SESSION variable, on a follow on page the variable is there and I can echo (crude verification for now).

However, if I return to the home page (my example), the variable is not there (I do a check / set if not in a block).


1) go to home page
if (!(isset($_SESSION['myVar']))) { $_SESSION['myVar']=2011; }

2) select a link on the page that advances to another page
can verify that $_SESSION['myVar'] is set (again crude echo ...)
On this page I have tried setting and have set in advance the variable and confirmed that it is as I set it (like $_SESSION['myVar']=1776; )

3) on page (the one advance to) if link back to home page the variable is not set.

I can refine the tests but have used $_SESSION on other sites and see this as unique (and not expected) behavior.

Any feedback/pointers/insight is appreciated

caffeineborg replied on at Permalink Reply
In the end I am not married to how to accomplish what I am after.

The goal is:

- set it to a default value $_SESSION['myVar']=2011
if !(isset

- or to have a parameter plucked from the URL /?myVar=2001
$_SESSION['myVar'] = $_GET['myVar']

- then to have that remain sticky (in session) ...

Let me know if that makes sense

jordanlev replied on at Permalink Reply
Sounds like there may be a problem with the cookie being set for a specific subdirectory on your site. I would install FireCookie, which is an extension for Firebug (which is itself an extension for FireFox) -- that will show you what cookies are being set and under which path. If the cookie isn't set to the top-level path of the domain ("/"), then it won't be readable on every page in your site.
caffeineborg replied on at Permalink Reply
So, I installed FireCookie (v1.3) and restarted firefox (v7.0.1).

I see the CONCRETE5 cookie at the / level. Is that what you wanted to know? The 'myVar' is a $_SESSION and I thought in session on the server ...

I can see (again used crude echo ) the $_SESSION['myVar'] on the page I navigate to.

The value of the cookie is abstracted ...

What information can I give you. Do I need to be schooled and am missing something?

jordanlev replied on at Permalink Reply
Hmm... I don't know. Checking the domain of the cookie was just my first guess at troubleshooting, but that seems to be working the way it should. I have no clue how to address this -- if it were me I'd step through the C5 code to see what's going on. Sorry, wish I had a solution for you :(
caffeineborg replied on at Permalink Reply
Let me ask this (kinda sounds too basic):

Is there a way to specify named sessions? Is there something like that going on?

Do, I have to do something more than:

$_SESSION['myVar'] = 1776;

Did the existence of the CONCRETE5 cookie with the "/" path tell you something that is related to the $_SESSION? Am I missing something? I thought the $_SESSION information is on the server (not down to the browser). Sorry to ask such basics but I want to make sure I am giving all the information you need.

My idea was that I was keeping 'myVar' in session on the server and it would be available so I can operate on it on other pages (or back on the home page (like a link to the home page)) so I an have unique PHP Blocks 'do things' when it finds myVar set or not.


jordanlev replied on at Permalink Reply
My understanding is this:
The session is a group of data that is stored on the server. But in order for the server to be able to identify a group of data with a particular user, it stores a cookie in the user's browser that contains a session id. So the order of things happening is this:
* User visits a website and sends whatever cookie data it has for that website.
* If this is the first time a user is visiting a site, the server sees that no cookie data was sent so it creates a new group of data and whatever the id is for that new group of data gets sent back as a new cookie that will then get stored in the user's browser.
* If this is not the first time a user is visiting the site, then they already have a cookie and when they request the page that cookie is sent to the server. The cookie only contains a session id, though -- the server sees that session id and pulls up the proper group of data based on that id.

So the existence of a CONCRETE5 cookie means that Concrete5 has created a session and sent the id for that session to the user's browser in a cookie called "CONCRETE5". If the cookie is set for "/", that means it can be used by every page and every path under that domain name. But if the cookie were set for a subdomain of the site (e.g. "/about"), then the cookie would only be sent to the server if the user was visiting a page under the "/about" section -- if the user were visiting the home page (which is *not* under the "/about" path), then the session data still exists on the server somewhere but the browser doesn't send the cookie containing the proper session id to the server so the server can't actually retrieve that data for this user.

Having a cookie set to a sub-path is the most common cause of problems where the session data is available on some pages and not others, and that's why I suggested you investigate that first. But since that's not the case here, then it would seem something else is going on (and I don't know what that something else could be).

Hope that cleared up more things than it confused :)
caffeineborg replied on at Permalink Reply
No that is really good and clearly describes the process (a help, thanks as I had a glimmer of it).

Now, given that FireCookies shows the CONCRETE5 cookie with a "/" path and moving from one page (the home page) where I can see my session var set and verify that on the destination page: where do we go from here?

Is there some debugging/logs/tests/code you would point me towards to take another step?

Is there another tack to take to accomplish (hope I gave a good description) what I am after?

Is there a unique cookie set up (like creating another cookie) that is better to follow? How to do that in C5?

Thanks for your time
jordanlev replied on at Permalink Reply
Everything from here needs to be done on the server. There's something fishy going on with the way C5 is setting sessions (or maybe it's a server or php setting of some kind?).

What I would do is set up the site on a local server (like in MAMP on a Mac or WAMP on Windows) and see if I can recreate the problem there. If it's giving you the same issue locally, then I would start debugging. I have xdebug set up on my local machine to allow me to step through the code one line at a time -- I'd find the portion of C5 code that sets the session (do a global find for "session_start"), and set a breakpoint there. Also set a breakpoint in your code before you try to access the session data yourself. Note that getting xdebug set up is a pain in the neck. And then you have to find a front-end for step debugging, which is another pain in the neck. Ahh... so actually you might be better of doing it old-school with "die()" statements in the code to print stuff out and experiment that way.

If the problem can't be recreated on your own machine, that means there is some setting in php.ini or some other server setting that is doing... something (couldn't say what though). In that case, time to start googling (better yet, just search on -- usually best answers are there).

It won't be easy, sorry to say.

(As an alternative, you might want to try setting your data in a cookie directly -- as long as it's not sensitive information, you could set your own cookie separate from the CONCRETE5 one and put your data in the cookie directly instead of putting it in the session).
caffeineborg replied on at Permalink Reply
I have this issue in both my dev environment and production. Thanks for the details on how to dig into it. I will start first with a simple (quick) tack on setting a cookie (not sensitive data "1776" ...).

Once I have the needed functionality in place I will return, first with the plan to run a test with pages outside of C5 on the same server (even same virtual host).

Thanks -- is it best if I post back to this thread?
caffeineborg replied on at Permalink Reply
QUICK UPDATE: I was looking more at FireCookie and noticed this,

The variable is set on the home page, is available as I traverse from home to another page (via a link on the home page). Now my issue
was that a link on this destination page back to the home page would take the browser back to home but the variable in session was gone.

What I noticed is the Domain is changing as the browser moves from each page (specifically in the case of my dev environment the domain gets switched to the fully qualified name for production). The net of this I suspect is that the SESSION information is not accessible
so in turn the variable is not there.

That said,

a) can you confirm the above makes sense?

b) can you provide details on why the domain would change and the navigation (URL) not? And that the operations otherwise seem function?

c) can you provide details on where to set or define the information that the cookie is picking up and why it might change from page to page (given this is an/the issue)?

I will hold on the cookie solution in case there is a straightforward path to solution as there are these details.

again my thanks
caffeineborg replied on at Permalink Reply
So, it looked like the theme designer put an absolute path in a global component. That looks like it set the domain when visiting the destination page.

I cleared that (made the image request be relative) and the domain for the CONCRETE5 cookie is now constant between the pages in question.

Still the $_SESSION['myVar'], set on home, available and correct on the linked to destination page is not the same if a home page link is selected (almost like going home clears it).

that said - I am spinning here and need a solution and will start looking into setting a cookie as you suggested.

please let me know if there is anything in what I have provided that might add to a solution for the $_SESSION issue

jordanlev replied on at Permalink Reply
Sorry that I can't provide any more help -- I have no idea why or how this stuff works within C5 and if I ran into this issue I'd just have to step through the code and investigate like you're doing, so my last post is the end of my knowledge on the subject.
caffeineborg replied on at Permalink Reply
The day (meetings etc. ) is getting away from me ...

I am looking to see how in C5 I can set cookies (via a block with PHP) with access on a page and prior to headers are being set?

Likely it is an available function ... and I am looking just have yet
to find my answer.
caffeineborg replied on at Permalink Reply
Started working on using COOKIES ($_COOKIE) as per the discussion on $_SESSION that is not working. Please correct me if I did not interrupt this correct.

It seemed most logic to add the following to the theme header.php

if (isset($_GET['myVar'])) {
$oi = $_GET['myVar'];
if (!isset($_COOKIE['myVar']) || !isset($_GET['myVar']) ) {

with the idea being if you come to the site with a specific myVar or have a cookie with that all is good. Else to set it to a default (2011 in this example).

Now when I go to the site initially firecookie shows the cookie but code in a block does not pick it up

- is header.php the correct place?
- is there some race condition?
- am I on the right track using cookies per your advice?
- if header.php is not the place, where?
- are there methods I can call, where?, that will let me get from the URL or set the cookie?
- have I provided a good enough explanation of what I am trying to do?
with the idea being if you come to the site with a specific myVar as a $_GET['myVar'] or have a cookie with that all is good. Else to set it to a default (2011 in this example).

- Is there an issue with cookies being set in header.php and there need to be another (how) to set this prior to the code running? It is some form of a race condition with the cookies as suggested where the cookie may be in the browser but the code does not see (cookie set but php is being interrupted on the server in advance of the cookie ... ). That is why I initially targeted session. I might be able to compensate with redundant code blocks.

I send this in for review/comments/thoughts.

Am I on the right tack?

Thanks for your time

Have a great weekend
jordanlev replied on at Permalink Reply
The thing about cookies is that the browser sends whatever it has to the server as part of the request, which means the browser sends its cookies before the php code runs. Thus, when you set a cookie in the php code, it happens AFTER you've received the browser's existing cookies -- so you won't see that cookie stuff again until the NEXT page request by the user. Does your code work upon a subsequent page load (like clicking to another page)?
caffeineborg replied on at Permalink Reply
Hi thanks - In my zest to yank the $_SESSION code I got into my own
trap of just thinking about the cookie.

I thank you for your set of eyes on this. Yes that is good for me to
remember. The code works as it goes to another page and looks to stay
if there is a link back to home.

I will have to review the snippet I put out as I thought there was a
catch for no cookie (either the $_GET['myVar'] or an assign to a default
value). I will review this.

Any other thoughts? Are the questions I have making sense? Is the
header.php the right place? Any other updates on $_SESSION? Have I
missed something?

On 10/07/2011 06:39 PM, Concrete5 Community wrote:
jayrich replied on at Permalink Reply
So sessions work as needed for the tasks that concrete5 uses them for, but are problematic for any extending we use them for? Am I correct in this assumption?
JohntheFish replied on at Permalink Reply
Cookies are set in the page header. So any attempt to set a cookie after a page output has started will be lost. Cookies have to be set before the header is set, so they can be attached to the header. This is a fundamental part of web pages and is not a limitation imposed by concrete5.

The session cookie is always sent in the header and tied to the session data held on the server, so you can use the session global whenever you like. But it only lasts for the session and will not persist in the user's browser.

If you need to set a delayed cookie from php, ie. after the header has already been sent, the trick to get round the above limitation is to output a scrap of javascript onto the page that sets the cookie when it executes in the browser.
katiam replied on at Permalink Reply
Please tell me that controller code is executed before any of the page gets outputted and headers are sent.. surely?
I too am having session issues within C5, previously not had any issues using sessions on NON-c5 sites.