Symphony.

If the parameter is in the pool, you must be able to output it (no matter which script added it, and when).

Could it be that you are fooling yourself using two different clients (e.g. browsers), one of them having the param in the session, the other one not?

If not, it must be a typo in your original code. (The code which you posted here looks fine to me though.)

To debug this further you might also want to try

<xsl:value-of select="$sessionmonster-test"/>

which is "the old way" of accessing parameters.

Haha, that's kind of funny. I was calling it the "old way" before, but had the errors when the param wasn't set, so I was creating a blank one: <xsl:param name="sessionmonster-test"/>, which I thought was maybe causing the problem, hence replacing it with /data/params/ instead. Ended up not being the case though.

So anyways, after a fresh sleep, I opened this up again and it seems to be how the __trigger function is called. It looks like it's not being called unless there is a $_GET set: if(is_array($_GET) && !empty($_GET)) return $this->__trigger();

The reason I can see the values in the param pool in ?debug is because $_GET existed.

I've changed that line to be just: return $this->__trigger(); and it seems to be working fine now.

I'm no php genius, so I'm curious if calling __trigger() that way is bad practice or anything.

I looked at the code, and it looks like the event has been changed with this commit to include the parameter if the event is triggered. Honestly, I don't know what is the reason for this. You should normally use the datasource which is included in the extension. And also adding parameters to the pool should be done in the datasource (but it is not done there). So I don't really understand the mentioned commit. At first sight I guess that the code was put in the wrong place by accident.

Maybe someone else knows more about it?

If you remove the condition from the event's load() function, you should use this condition around the foreach in the __trigger() function, so you don't attempt to perform a foreach on a potentially empty array.

You should normally use the datasource which is included in the extension.

Interesting. The datasource was removed from the Cookie Monster extension. I figured it was removed due to it being redundant, as the events/params gave you what you needed to work with. That being said, I actually removed the datasource from my fork of the sessionmonster.

I also assume that it's called in the Event trigger so that the params were updated on page load as they do with sessions, whereas cookies require a page reload/refresh after they are set.. but I could easily be mistaken there. Perhaps using $_SESSION already takes care of that?

Placing that condition around the foreach would give me the same results I was experiencing before, correct? So in better practice, the datasource should still exist, and the params should be set in there instead of the Event?

You are right. Using sessions the datasource will work fine, because events are always executed before datasources. So the datasource will always see any fresh session content.

Placing that condition around the foreach would give me the same results I was experiencing before, correct?

Yes. It will just not execute the foreachloop if the $_GET array is actually empty.

So in better practice, the datasource should still exist, and the params should be set in there instead of the Event?

That is my understanding. Ideally, events should execute business logic (like saving things, sending emails etc.) and add information about this to the <events/> node of the XML. Datasources should pull data and add them to dedicated XML nodes — and additionally add parameters to the parameter pool.

There is one downside of the above, however, and maybe that is the reason why it has been done in the event: When filters in other datasources rely on a parameter being set, you would have to create a dependency in order to make the "session parameter" datasource be executed first. Otherwise your filter wouldn't work as expected. If the session parameters are set by an event, they will be available for every datasource without the need to create dependencies.

So maybe it's simpler to use if you keep this in the event. I personally would add the parameters in the load function, then call __trigger() conditionally. But this is just a matter of taste, maybe.

But this is just a matter of taste, maybe.

No, great call. This way the foreach for events won't run if it's empty too.

All seems to be in working order now, thanks for the help!

From @creativedutchman's response it looks like I'm out of luck here unless I work with a development branch.

If I could make Symphony forget all sessions when the browser is closed, that would suffice as the admin doesn't mind logging in each time she edits the site.

I would expect there to be a session time variable in config.php but there is nothing there. Is there a variable I can set somewhere to make Symphony forget all sessions each time the browser is closed?

Thanks

Stu,

these are the two places that define a value for the cookie timeout. You could change the former to another number, but then it wouldn't be two weeks, or change the latter.

/Users/designermonkey/Sites/richard-designs.local.buginteractive.com/htdocs/symphony/lib/boot/defines.php:
  192    * @var integer
  193    */
  194:  define_safe('TWO_WEEKS', (60*60*24*14));
  195  
  196   /**

/Users/designermonkey/Sites/richard-designs.local.buginteractive.com/htdocs/symphony/lib/core/class.symphony.php:
  261           define_safe('__SYM_COOKIE_PREFIX__', self::Configuration()->get('cookie_prefix', 'symphony'));
  262  
  263:          $this->Cookie = new Cookie(__SYM_COOKIE_PREFIX__, TWO_WEEKS, __SYM_COOKIE_PATH__);
  264       }
  265  

Thanks John. Interestingly, though setting the TWO_WEEKS variable to zero means that I have to login to Symphony each time the browser is closed, the session monster variables are more persistent and remain set after the browser has been closed. I guess Session Monster works differently to Symphony itself.

Hey that really is weird. I would expect that it would log you out every time, but the session should also be destroyed in the process.

I can see that session monster does things slightly differently, although I would expect it to still work. I think this extension will need some love too when we deal with sessions in the next release.