Symphony.

I think it makes more sense to allow to the developer to set permissions for the events rather than for the system to assume anything. Thanks for the fix, brendo.

Missing from the documentation for the Members extension is an API for extension developers. For example, the Forum extension needs to access the Member object to determine whether a member is logged in or find the member ID to filter data or redirect other members trying to access restricted pages or data.

I'm still fumbling around with OOP where I'm wondering how best to access the Member object in different contexts.

In the context of an extension driver, it is possible to access a Member object's properties and methods through the Symphony::ExtensionManager() class.

$em = Symphony::ExtensionManager()->create('members');

// Fetch the member ID from the OpenID email address
$id = extension_Members::$fields['email']->fetchMemberIDBy($email);

I'm not sure how to go about this in the context of a data source or event.

$members =& $this->_Parent->ExtensionManager->create('members');
$members->initialiseCookie();
$isLoggedIn = $members->isLoggedIn();

For example, how would I port this code to use the Members Beta extension?

if(!$members->Member) $members->initialiseMemberObject();
$member_id = $members->Member->get('id');

Symphony::ExtensionManager() is available everywhere, it's Symphony core, not Members specific, so it will work in your Datasource, Event, Field, Filter whatever.

edit You'll need an extra ->Member.

$members->Member->Member or $members->Member->initialiseCookie()

$members->Member refers to the Member class being used, which at the moment is SymphonyMember. It has been abstracted like this for possible enhancements down the track of creating other Member classes, such as TwitterMember, FacebookMember etc.

$members->Member->Member will be an Entry object, or null.

The Members API documentation is on the todo list, but it will probably come in update in the form of some PHPDoc generation (same as Symphony's API) and not be included in 1.0

I think it makes more sense to allow to the developer to set permissions for the events rather than for the system to assume anything. Thanks for the fix, brendo.

We talked about this in yesterday's UX working group chat. The conclusion was that using allowEditorToParse was not a viable solution, since events customised by a developer might still be eligible for Members permissions. However there needs to be something declaring this permission-able-ness, since some custom events will not be eligible for permissions at all (the Login Info event for starters). In these instances we decided that they should either be hidden from the table completely (black magic, not ideal), or shown in the table but greyed out so that permissions cannot be set.

So could the PHP nerds have a headscratch to consider the best way of being able to flag an event as eligible for event permissions? The UX nerds can act on this logic and style the events list accordingly.

$members->Member->Member

Can this be tidied into a more logical API? Accessors like that seem a bit like an afterthought in terms of code usability. (Not necessarily for v1.0!)

The login (or logout) event won't appear in the role table as they aren't true events. The role table will show all events that appear in the components listing.

As for api, definitely, just want to get groundwork set and solid.

Thanks, brendo. That should help. I was missing the extra ->Member in my accessor. I haven't quite wrapped my head around abstract classes yet.

To check whether the event should be managed by Member Roles, the previous implementation added a method to events:

public static function showInRolePermissions(){
    return true;
}

Then, the Members extension would parse the events list to check whether to include the event in the Member Roles list or not.

$EventManager = new EventManager($this->_Parent);
$events = $EventManager->listAll();

if(is_array($events) && !empty($events)){
    foreach($events as $handle => $e){

        $show_in_role_permissions = 
            (method_exists("event{$handle}", 'showInRolePermissions') && call_user_func(array("event{$handle}", 'showInRolePermissions')) === true 
                ? true 
                : false
            );

        if(!$e['can_parse'] && !$show_in_role_permissions) unset($events[$handle]);
    }
}

Whether that's the best approach, I don't know.

From what I remember, that was one of the more hated and confusing aspects of the old extension. All events will display.

For the record, I'm happy to have all event displaying. Thanks, brendo.

The Members: Reset Password event is not working for me and I was wondering if it's working for anyone else. If no one else is experiencing this, I suppose my setup must not be quite right. Here's what I'm finding (using Email Template Manager extension):

• Submit form with email address only: Error - Username is required
• Submit form with username only: Success. But email is not sent. Event XML does not include status of the event filter for sending the email.
• Reset Password Email Template preference gets saved to configuration file, but preferences page does not show the option as selected.

Here's the form that I'm using:

<xsl:template match="data" mode="identify">
    <xsl:param name="event-action" select="'members-reset-password'"/>
    <xsl:param name="event" select="/data/events/*[name()=$event-action]"/>

    <h3>Reset Password</h3>
    <xsl:choose>
        <xsl:when test="$event[@result = 'success']">
            <p class="success"><strong>A code has been emailed to you.</strong> Click on the link and click the Reset password button to verify you would like to reset your password.</p>
        </xsl:when>
        <xsl:when test="$event[@result = 'error']">
            <p class="error"><xsl:value-of select="$event/error/@message" /></p>
        </xsl:when>
        <xsl:otherwise>
            <p><strong>Supply us with either your username or email.</strong></p>
        </xsl:otherwise>
    </xsl:choose>
    <form method="post" action="{$current-url}">
        <fieldset>
            <p>
                <xsl:if test="$event/username">
                    <xsl:attribute name="class">error</xsl:attribute>
                </xsl:if>
                <label for="name">Username</label>
                <input id="name" name="fields[username]" type="text" />
            </p>
            <p>
                <xsl:if test="$event/email-address">
                    <xsl:attribute name="class">error</xsl:attribute>
                </xsl:if>
                <label for="name">Email</label>
                <input id="name" name="fields[email-address]" type="text" />
            </p>
            <div id="submission">
                <input id="submit" name="action[{$event-action}]" type="submit" value="Send me the code" class="button"/>
            </div>
        </fieldset>
    </form>
</xsl:template>

Submit form with email address only: Error - Username is required

I have the same problem with the Regenerate Activation Code event. I will post it on the Github issue tracker.

Submit form with username only: Success. But email is not sent.

Yes, in your form you forgot to include the recipient info for the Email Template Manager, like so:

<input name="etm[][recipient]" value="fields[email-address]" type="hidden" />

But, unfortunately, that didn't work for me either. :-) I submitted this issue on Github.

Reset Password Email Template preference gets saved to configuration file, but preferences page does not show the option as selected.

OK, that's clearly another bug! Can you post this one on Github, please? (https://github.com/symphonycms/members/issues)[EDIT]: I did it.

@brendo: How is the Regenerate Activation Code event supposed to send an email? As far as I see, there is no email template filter configuration for this.

Thanks for confirming these issues and posting them to GitHub, Michael. I'm glad to know that it's not just me.

I figured that if there was a preference for a Reset Password Email Template that the Members: Reset Password event handled the triggering of the send mail filter. However, I did try the form with the etm[][recipient] input as well, just to make sure that it wasn't something missing from the documentation, but that didn't work for me either.

Same here: I am very glad that I am not alone with this.

I am afraid that the recipient setting in the ETM (using field[fieldname] syntax) is still broken, so I will re-open this issue on Github. Regarding other settings (i.e. email header fields), Huib already fixed it. But I found a small bug in the Core Email API (SMTP class) as well regarding the reply-to-email header field -- I will prepare a pull request for this.

At the moment etm[][recipient] will work with usernames (only).

I've pushed a whole bunch of fixes in the last hour that should resolve each of these problems. Please let me know otherwise.

I'm AFK for this evening, but will tackle them tomorrow lunchtime.

Thanks for testing and persisting guys, couldn't do it without you!

@brendo: To make the registration process more secure, Members provides two useful event filters which prevent DOM hacking attacks. But how can I do the same on a Member account edit page? Isn't it possible to change the member role by hacking the DOM? Shouldn't we have another filter for this?

Use the same filter. Its not hardcoded to a registration event :)

Yes, but will it not set the member to the default role using brute force?

Ah I see what you mean, in the instance that a member then is upgraded to a different role other than the default. Yeah, we'll need another/enhance the current filter to ensure that whatever is provided in the role field is the same as what is in the database. That does mean that it would be difficult to promote a member from one role to another on the frontend using standard events. This is all a bit edge case though. It does require that the attacker knows the role field name and then the names of your system's role.

Why don't we:

• Enhance the filter to use the current role or, if not set, the default role
• Rename the filter (new name: Members: Role) -- this would be consistent with Members: Activation

If you ever need to update the role from the frontend, you simply don't append the filter to your event. It's only an event filter, isn't it?

Sry guys, it is so much frustrating to keep searching to know how things work after hours. And it's sad that symphony isn't well documented.

Can some1 explain how can I send registration email to the newly regitered member from frontend ?

I did following steps :

• created a datasource selecting the last created member
• created Email Template
• created an event with the right datasource associated
• added Email template filter to the event
• added Members : register filter to the event
• used the both forms generated in the event
• I have 2 forms, one for each fiter added to the event on the page
• The entry is created but the email isn't sent.

How to have 2 actions done with same event (register and send email) ?

Are you using the Email Template Filter, or the Email Template Manager?

There is a tutorial on how to set up a Email Template Filter written by Rowan (the creator).

Your steps look a little odd. I'm not sure what you mean by 'created an Event with the right datasource associated'. Do you mean 'created an Event with the right Member section associated'?

You should only have one event, so your comment about 'both forms' generated in the event is a little confusing as well.

Could you post your Register form HTML?

Sry guys, it is so much frustrating to keep searching to know how things work after hours. And it's sad that symphony isn't well documented.

Please keep in mind that Members is in Beta and as such there is little documentation because things are still in flux. The best source of documentation for this extension at this stage is the README. If you have concerns/ideas about other areas of Symphony that need to be documented, please don't hesitate to create a thread to bring it to the attention of the Team. This thread is a growing source of tips and tricks for Symphony.