-
Notifications
You must be signed in to change notification settings - Fork 38
Multiple Sections
In an upcoming release of Members, as mentioned in #173, Members will support multiple sections, which allows developers to silo user data in their own sections. This allows developers to create more complex membership sites, where there may be many different member types that require vastly different schemas or requirements.
This document outlines the things that will need to change to allow this happen and to note the progress. The next release of the Members extension (as in 2.3 compatible) will most likely not support multiple sections just yet as there is a need for a 2.3 compatible Members extension immediately and it is anticipated that this work will take a little bit of thought and time to implement and test.
In Members 1.1, developers select an active members section from the Preferences page. We have two options here, remove this and determine the Members section dynamically (likely to be slower) or to allow users to select multiple sections that can be used for Members. This is nothing but a shortcut and a potential whitelist for the extension to know what sections are allowed to verify Member data.
Similar to the Frontend Member Manager extension written by Rowan Lewis, developers can specify the 'active' section by including a hidden field in their forms. For example, to login to the Admin section, <input type='hidden' name='members-section' value='admin' /> might be used in the Login form markup. This would tell the Members extension to use Admin as the active section.
There is some risks with this, and it's likely that we'll need a Lock: Section filter to prevent this being DOM hacked (or encourage Default Event Values be used). Because of this, perhaps selecting the 'active' sections on the Preferences page would be a useful security measure?
Work as already been committed to the integration branch that allows the extension_Members::getField() function to accept a $type and $section_id, but this has not yet been added to getFieldHandle(). At the moment these functions store the field objects and handles in single static variables, extension_Members::$handles[$type] and extension_Members::$fields[$type]. These will probably have to be two dimensional arrays, with the key being the $section_id and the value the array that exists at the moment.
This one needs some thought, so feedback is more than welcome. My idea is that the Roles page becomes tabbed, which each tab specifying the roles for each Member's section. This means that no Role can be shared between member sections and it may require some duplication from a developer's perspective during setup but I think it's more future proof for us, and developers.
This will require some minor updates to the RoleManager class, mainly to save the associated $section_id will a Role. All Roles are created, read, updated and deleted using their $role_id, so this should work out in our favour.
Members provides four events, but there are two that will need thought. Members: Activate Account and Members: Reset Password have settings, which specify auto activation and auto login. Developers may want to change these settings on a per section basis. Some options:
- Flesh out the settings in these events so that they can be saved per section, perhaps using duplicators. This might work, but we have to remember these events are being saved using some AJAX magic so there may be issues here.
- Allow events to be overridden by hidden fields. We have precedent to do this, and this could be done more securely with Default Event Values, so it might be a good option.
- Do nothing... yet. With Symphony 2.3, the providers concept was introduced which allows new Datasource types to be provided. Symphony 2.3.1 is likely (or will do if Members requires), to allow new Event types to provided, which would mean our current event system can be streamlined.
The absolutely most important thing for this feature is that is must be implemented as such so that current installations (and those that will be updated for Symphony 2.3) can be updated to the multiple section Members version. Ultimately this mean more work for us (as we'll have to fallback to finding a section when it has not been specified), but it's the right thing to do for the developers.
- Determining ownership of an entry could be tricky if a developer links one Members section to another. It might not be, but just noting it now for completeness