Search

A new Extension, “Cookie Monster” is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

This is a rewrite of the old Cookie Monster CS for 1.7. It will register any GET variable present in the URL with a cookie it maintains. Be sure to read README.txt and check out the Event documentation by going to your Components area of Symphony and clicking on "Cookie Monster: Add GET variable to cookie"

Requires Symphony 2 Revision 5

Changes

1.1 - Cookie values are added to the page parameters. This makes them usable in Data Sources.

Thanks for that Allistair.

It's going to be a few weeks before we get around to implementing this, but I'll let you know how we go with it.

It looks like it will be perfect for our needs anyway.

Thanks Alistair! I wonder how hard it would be to convert the session monster.

How should I configure the cookie prefix? Do you recommend to change all values where applicable or define SYMCOOKIEPREFIX in the event and data-source files or perhaps in the config file? Am I correct that this can not be achieved through the control panel?

The cookie prefix is set in /manifest/config.php. That value is used for creating the define you mentioned, __SYM_COOKIE_PREFIX__. The Extension adds -cookiemonster to the end just to make sure it doesn't clash.

@carsten

I wonder how hard it would be to convert the session monster.

http://symphony21.com/forum/discussions/266/1/

Give that a whirl.

It appeared to be quite easy to convert.

Are you planning on converting all your campfire services to symphony 2 extensions?

Is it possible to get the value of a specific cookie variable and shove it into a param of some sort so that i can filter the DS before the page XML gets built? I assume that would be better than loading in heaps of XML data and filtering via XSLT.

Is it possible to get the value of a specific cookie variable and shove it into a param of some sort so that i can filter the DS before the page XML gets built?

Not currently, but I really like this idea. I just have some concerns about its implementation.

This gives visitors the ability to name parameters, which may result in a possible attack vector. DSs can work without all their params present, and there'd be no way for Symphony to distinguish one of these from a maliciously-set cookie param. I'm not sure what the implications of this are, since it largely depends on DS design.

Also, there'd need to be an order of precedence to resolve conflicts. I think this would be fairly straightforward: reserved params like $today are checked first, then DS param output, then URL params, then GET variables, then cookies.

(For some reason I thought specifying URL params was possible with GET variables in previous versions of Symphony...but can't get this to work in 1.7 or 2.0. Did I somehow fabricate this memory??)

For some reason I thought specifying URL params was possible with GET variables in previous versions of Symphony...but can't get this to work in 1.7 or 2.0. Did I somehow fabricate this memory?

/?param=value

The above would result in $url-param as a parameter equal to value. It was not possible in 1.7 but it is in 2.

@Lewis: Gosh, how did I not know that? But it doesn't allow for what I thought was possible - specifying URL params out of order, e.g. skipping month from the URL param list year/month/day with a URL like /page/2008/?day=15. I don't really trust my memory, though.

I've posted a new version above. From the readme:

2: (optional) If you want values added to the cookie via cookie monster to show up in the page params, making them usable by DS's for filtering, you will need to add the following code to line 157 of /symphony/lib/toolkit/class.frontendpage.php:

 $this->_Parent->ExtensionManager->notifyMembers('ManipulatePageParameters', '/frontend/', array('params' => &$this->_param));

It will replace the existing commented line starting with 'TODO'

and

  • If you made the delegate change in step 2 of installation, values added to the cookie via cookie monster will show in the page params like so: $cookiemonster-KEY = VALUE where KEY and VALUE.

Hopefully this helps.

The README lies! that delegate call should be on line 146 or so. Just above the line

$this->__processDatasources($page['data_sources'], $xml);

Sorry if there was any confusion.

I've three categories in a blog section, and I want visitors to have the option to filter out categories of no interest to them. Could CookieMonster be used for this?

I cant get this to work, has anything changed with this for 2.0?

Okay got it working, sort of, except the cookie doesn't stay after the initial page request.

Any ideas?

Does anybody know if this extension is still working in Symphony 2.0.2?
It seems like the event saves something to somewhere but nothing is returned in the data source. Has anything been changed in the internal cookie handling lately that could cause problems?

I had a look at class.cookie.php and found out that $Cookie->set($key, $val) will call a function that stores data in $_SESSION. Is this just a misleading naming convention or does Symphony’s Cookie class store data in sessions instead of cookies? I am confused.

Nils overriding cookie is leftover from time when there was no sessions implementation. So sessions were implemented as “drag&drop”, to make them easier to install than editing a lot of files inside Symphony.

Since sessions support is built-in now, maybe cookie could be changed back to what it was, but we’d have to go through whole Symphony source and make sure sessions are used instead of calling $Cookie->set/get.

Is there a reason You want to use cookie instead of session? Because in the end, it works almost the same, with the only difference being that cookies would be stored on client side and session data is stored on server and only one session cookie is created on client side.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details