Symphony.

Just wondering, since it says events run before data sources, how would I get a data source value into it? For example I want {/data/events/facebook/@id}

@Pat Seems like you have to hack the event to achieve this.

How do I correctly populate a SBL field with multiple values?

From a given value of 1,2,3 it only gets 1, or the first one.

Supply an array.

OK I believe I did. That is I hacked the event exactly as adviced here - works perfectly I think - to get datasource output parameters into the event - namely a list of system-ids like $ds-entries.system-id.

This I supplied as a {$ds-entries.system-id} value to the field in the event's UI. I assume it is an array, but maybe I'm wrong somewhere. I see it as an array in case of a var_dump just extending that former advice to like die(var_dump($env['pool']['ds-entries.system-id']));, returns

array(2) { [0]=> string(4) "1954" [1]=> string(4) "1955" }

Im not that programmer, so pls don't get me too hard on my words. I do only some soft basics.

Anyway, following that array example, I get linked only the 1954 entry.

Any further steps warmly appreciated :(

This I supplied as a {$ds-entries.system-id} value to the field in the event's UI.

Hmm, I don't know about that. I'm not sure if Event Default Values is capable of handling parameters that way.

Perhaps @brendo can shed some light on this one.

I'll have to test it, I haven't used this extension recently on a 2.3.4 build :)

can this extension be integratead with Symphony CMS events ?

can this extension be integratead with Symphony CMS events ?

You mean as a core feature? Would make sense in my opinion.

If using it with the Members extension do you think a parameter can be set as a default value if that parameter depends on the member being logged in when that same event is deactivating the member and logging him/ her out?

I presumed default values are "looked up" upon page built but if this happens after the event has executed, and in the above case, after the member has been logged out, then that parameter is no longer there.

Anyone encountered this? I'd love to hear your thoughts as it's driving me crazy.

(used with 2.6.1)

Default Event Values uses the EventPreSaveFilter delegate, which is triggered after the FrontendParamsResolve delegate. (The latter is used by the Members extension to add Member details to page parameters.)

So yes, that won't work. What exactly are you trying to achieve?

I see... Thanks, Michael.

I wanted to deactivate a member upon email change and save their old email address so that a notification is sent to it with the ETM. Just added security, but not essential.

Hmmm, interesting idea! But if you log the Member out, there is no way (apart from using POST data with a hidden field, but that's not safe at all). I think it might work if you keep the Member logged in, because Members and Default Event Values alike act before saving the data.

Tried looking into this but it looks like member gets logged out automatically when deactivated.

What do you mean by "deactivated"?

When the form contains <input type="hidden" name="fields[activation]" value="no" /> (also passed as a default value). Thus, the member is no longer activated and needs to verify their email address before being able to log in again.

Ah, you force deactivation? Why do you do this? (I always regarded activation as a one-way street.)

Yes, because I allow members to change their email address and if they do I have to make sure it's theirs.

Hmmm, I see. Let me think about it (in the coming days).

@ellie / @micheal-e could you technically 'leave' their old email in place, until they 'verify' the new one? Sending an email to their new address, and when they click on the confirm-link you actually do the submission on the page via javascript to update the email address?

You could use an intermediary table/section to hold the new email address, the member id, and maybe a unique hash. It's maybe less complicated than de-activating an account. - You might need to do some minor code to validate that it's a valid/correct request. But I wouldn't de-activate a user/change his email because at that point I don't think he'd be able to activate it if there is a mistake in the new email address for example.