Using cookies to store/get user preferences

I'm an experienced programmer with several languages (COBOL, REXX, Java, Javascript, etc.) under my belt over many years but I know very little about PHP. I dabbled in it a bit a year or two back and got it to do what I wanted to do but I'm not sure how to do what I currently need.



A bit of context: I have designed a website where the user can choose between various page styles; each style invokes different CSS to give them a different visual experience of the site. They can select the style they want via View/Style in Internet Exploder and View/Page Style in Firefox but that preference is only remembered as long as they're on that page. As soon as they move to another page on the site, they have to choose the alternate style again or live with the default style. I want them to be able to select that preference ONCE, the store it in a cookie specifically for them, then keep using that style every time they visit the site. (Naturally, I want them to be able to change the style and then remember the new style as well.) There will be many visitors and each will want that same capability. I currently don't require any login to the site. (I'm toying with password-protecting some of the site down the road but that's not a factor in this page style thing that I'm talking about here.



Now, my questions.



I've found a variety of short articles describing how to use setCookie() to create the cookie (and delete it later) and getCookie() or the newer echo $_COOKIE["name"] to determine the cookie value. However, I am NOT seeing anything that says where I put the code to set and/or read the code within my web pages. I would really appreciate an explanation of that! I expect to write short fragments of php code to do those jobs which I will then imbed within my web pages via SSI (Server Side Includes). Is that reasonable or is there a better way?



Also:

1. When the user clicks on the desired Style in the View/Style menu, how do I detect what choice they made?

2. Should the name of the cookie be something like "pageStyle" or should it be something that uniquely identifies the user so that the right cookie is retrieved when the come back? If the latter, what value should I use and how should I obtain it? I assume that something unique about the user obtained from their headers is far better than displaying a dialog and asking them for some unique identifier.



I'd rather stay away from Javascript in any of this functionality since I can't rely on it being turned on.



One quick aside while I'm here. Does anyone know how to change the page style if visitors use Google Chrome or Opera? I can't even FIND options for changing the page style in my copies of those two browsers and both are current versions. Do they not support differing page styles at all or do they just hide the technique to choose the style very effectively?



--

Henry

 

You should simply make a on-page choice for this, not rely on browser capabilities (which may change per new iteration of the browser). Just make it part of the page, like have a settings-page, with a select drop down. On choice, the user picks a style, it gets stored in a cookie on the users computer, and when the user comes back, the associated style is loaded. If no cookie is set, just load the default style. No need to uniquely identify a user via a cookie - cookies are normally used for on/off-functionality (a simplified explanation).

 

I am surprised people still use Server Side Includes.....

 

Fair enough; you make a good point, although I disagree about cookies normally just being on/off: I think that is OVER-simplified ;-) I'll think about how I can implement a settings option.

 

Really? Why? I find them an invaluable technique for keeping code very modular and compact. I'd hate to go back to not having them. Or are you suggesting that there are newer, better methods for doing the same thing? If so, please tell me what you mean. No need to be detailed; just give me the name of the technique and I can google it for details....

 

Why rely on server side includes when you can achieve the exact same thing by using native php, and using include or require? Php never breaks, as long as the host supports php (which is more or less always enabled), while SSI depends on, for instance, an Apache module if using Apache.

 

If it works for you that is fine. However, once you use a .shtml extension the server will parse the page looking for the SSI tags then execute the script you are including. It's like an extra unnecessary step. Just have the script generate the page.

 

I find it at least extreme, to use SSI in 2014,
why not make a clean php only solution ?

SSI is not secure, is not able to run on all providers,
and over all in the long run, it wont be as reliable as
a plain php would be.