Symphony.

Yes, the Members extension required changes to the core and it would be great to either have these included in 2.0.7 or remove the need for these changes from the extension. Without one or the other, further development on the extension will be very difficult, since it will mean having to figure out how to modify the core, each time there is an upgrade.

I created a fork of the Symphony repo to track the changes that enable compatibility of the Members extension with the Symphony 2.0.6 core in the Forum Ensemble.

I think it would be great to have these changes made in 2.0.7 as there seems to be an interest in front-end membership in some recent discussions.

I for one am looking forward to a more mature membership system to replace my own.

I was surprised to find that the compatibility of the Members extension hadn’t been a consideration in the release of 2.0.7, especially after Allen’s announcement that the Members extension would be getting some attention and comments about a better permission system. It’s such an important feature, and I thought that one of the major issues that is driving the push toward version 2.1 is the need for better authentication systems for front end and back end, along the lines of what Nick had discussed back in April 2009. As I recall, the ultimate goal is to abstract user authentication so that different systems, such as OpenID can be used.

Is this being addressed in Symphony 2.07 RC-1?

Yes. Members has been the focus of the team’s work for the past week and will be released in beta alongside or shortly after 2.0.7 final.

Craig, thanks for the input. I appreciate your help!

Missing Login Event?

Working with this invaluable extension and have been having trouble getting the login bit to work.

The documentation mentions that for login and forgot password there is no need to create an event because the members extension uses a delegate of some kind. However, when I look in the /members/events I only find an event for forgot password. Should there be one for Login too?

Would someone please help me understand what I need to do in order to interface a login form with this plugin, without creating an independent event for logging in?

Here’s what I use:

<form action="{$current-url}" method="post">
<fieldset>
        <label for="username">E-Mail</label>
        <div>
            <input class="text" id="username" name="username" type="text" />
        </div>
        <label for="password">Password</label>
        <div>
            <input class="text" id="password" name="password" type="password" />
            <p><a href="{$root}/login/forgot-password/">Forgot password?</a></p>
        </div>
    </fieldset>
<input name="redirect" type="hidden" value="{$root}/m/" />
<button class="button" type="submit" name="member-action[login]">Login to myDBMS</button>
</form>

member-action[login] triggers the code.

Progress Report

Firstly, thank you @Lewis for your help. Your posted code confirmed that my form was correct. I do see now that when I login on my form and yours that a $login-id parameter appears with the user id of the person logged in.

What still remains to overcome - HELP PLEASE :-)

What was throwing me off was that in the members extension (forum branch) documentation there is suggested that the event xml result member-login-info would appear; however, it is not appearing after login (event when posting to ?debug=xml.

Consider this template copied from the read-me file:

<xsl:template name="login-panel">
    <xsl:param name="member" select="/data/events/member-login-info"/> <!-- Event in view here -->
    <form id="login-panel" action="{$current-url}" method="post">
        <fieldset>
            <ul>
                <xsl:choose>
                    <xsl:when test="$member/@logged-in = 'true'"> <!-- with attributes that would be helpful to find -->
                        <li>
                            <a href=""><xsl:value-of select="$member/name"/></a>
                            <xsl:text> </xsl:text>
                            <a href="?member-action=logout">(Logout)</a>
                        </li>
                    </xsl:when>
                    <xsl:otherwise>
                        <li><input name="username" value="username"/></li>
                        <li><input name="password" type="password" value="password"/></li>
                        <li><input id="submit" type="submit" name="member-action[login]" value="Log In"/></li>
                    </xsl:otherwise>
                </xsl:choose>
            </ul>
        </fieldset>
    </form>
</xsl:template>

Next Questions

1) So should I be looking for /data/events/member-login-info or is that deprecated?

2) If it is deprecated, is there a recommended way to check for login status? I’m asking this because I anticipate the release of 2.0.7 and don’t want to have to redo the very large project we’re working on here when we upgrade.

3) If it is not deprecated, does anyone have ideas as to why it does not seem to be generating the event xml result?

I can’t speak for the forked (unofficial) members extension, but have you looked at the official Members extension? It’s not yet announced but it’s available on github. This is something we’ve been working on for the past two weeks.

There will also be a demo reference ensemble to show how the members extension works when the extension is announced.

So should I be looking for /data/events/member-login-info or is that deprecated?

As far as the official members extension, member-login-info is still around, I can’t see why the unofficial one wouldn’t have it also – furthermore, the current Symphony website uses a similar version to the unofficial one.

If you’re going to try out the official members extension, be sure to also install the two extensions it’s dependant on:

• SMTP Email Library
• Advanced Symphony Database Connector (ASDC)

@Allen: Why does it rely on the SMTP Email Library?

This whole email thing seems rather fundamental to me. Shouldn’t the Members extension rely on core features as far as possible (and the email core functionality be more flexible on the long run)?

Why does it rely on the SMTP Email Library?

Symphony’s core utilises the default php mail() function. While it’s convenient to use, it’s not very reliable. Previous to this version of the Symphony website, we used the core’s feature to send out registration emails. We roughly get about 10% users contacting us that they never got the email.

mail() by default uses the servers own sendmail functionality and does not use any kind of authentication. In many cases, certain email servers won’t recognise the sender’s server and reject the email.

Whilst you can tweak PHP to use different MTAs (mail transfer agents), its usually beyond the reach of many users. Furthermore, it is also quite a complicated process to get it set up and working properly.

The SMTP Email Library uses the PEAR mail package which is a more robust emailing system. Using the PEAR class allows users to optionally set authentication and choose to use whichever SMTP server they like, totally independent of the server they are on.

Since the extension relies on third-party code, we decided to keep it outside of the Symphony core. This way, when the PEAR mail package is updated, we do not have to synchronise the update alongside Symphony core updates.

Another reason for keeping it as an extension is to give developers a choice over their preferred email sending solution.

If it is not deprecated, does anyone have ideas as to why it does not seem to be generating the event xml result?

Make sure you are utilizing the role field in your members section.

I’m having trouble working on a log in page using the unofficial members extension. I’d love to be able to use some kind of AJAX log in but I’m having problems.

If I use an actual form with a submit button then it wants to refresh the page.

When I’m using the built in functionality of jQTouch to do an AJAX submit, then it just doesn’t work. I think I need to send the name=”member-action[login]” variable somehow?

Is this possible?

I can’t speak for the forked (unofficial) members extension, but have you looked at the official Members extension? It’s not yet announced but it’s available on github. This is something we’ve been working on for the past two weeks.

There will also be a demo reference ensemble to show how the members extension works when the extension is announced.

Thanks Allen for the tip and the response. Your labor is most appreciated.

Is the unofficial Members system going to be retired in favour of the official extension? Is there a feature comparison that can be done between the two?

I believe the unofficial Members extension should be retired, especially since it does require modification of the Symphony 2.0.6 core and there are no plans on my part to update it for use with version 2.0.7. I’m glad that the Symphony Development Team has found the time to further develop the Frontend Members extension for an official release built for compatibility with version 2.0.7.

I haven’t had time to put the new Members extension through a thorough test run yet, but at first glance, here are the major differences:

• The Roles page now uses a slider control instead of checkboxes to select Event Level Permissions for editing (options: No Privileges, Own Entries, All Entries). I’m not sure whether these permissions include the ability to delete entries.
• Page Level Permissions appears to be identical to the Forum Ensemble Members Extension which allows the selection of pages to Deny Access. (The initial implementation required the selection of pages to Allow Access. This was a problem since access was automatically denied to every created page unless configured otherwise. The official Members extension assumes that all pages are accessible unless expressly configured to be under access control by the Members Roles configuration page.)
• Email Templates have been removed from the Members:Roles page. A new Email Templates page is now used to configure multiple email templates for each Role and for different types of events (Reset Password, New Password, Activate Account, Welcome Email) that are now stored in the database rather than in the configuration file.
• The Preferences page has been changed to the Setup page, and now includes one of the most exciting features, I think: a Smart Setup feature that provides a Create button that automatically creates a new section, called Members, containing Username/Password, Role, Email Address, and Timezone Offset fields.
• Member activation is now optional. A checkbox is used to configure whether member activation is required: If activation is required, new members will be added to the ‘Inactive’ role until they reply to the ‘Activate Account’ email. Activated members will be added to the role selected on the Setup page.

These improvements are reason enough to deprecate any previous versions of the Members extension.

I agree with bauhouse. We should concentrate on the new Members extension.

Thank you, bauhouse, for your list of differences!

I would suggest to add a message about the official Members extension in the description of Unofficial Release to avoid confusion.