Allow multiple sections for Members

[brendo]

Members is currently tied to work with a single section (as set by the preferences page). This works well for most situations, but there are some instances where it would be preferable to have member data stored in different sections (or perhaps the data for each member requires different fields).

On completion of this issue, the Members extension will be able to work with multiple sections.

The proposed solution will use a hidden field to specify which section the event should use. ie. <input type='hidden' name='members[section]' value='section-handle' />.

To maintain backwards compatibility, if $_POST['members']['section']is not provided, the extension will look for the the 'active member section' from the config.php (which it does now) otherwise throw an error.

Other notes:

• It won't be possible for a member to be logged into more than one section at a time (this would be an edge case anyway), so the Members Logout event won't need a section.
• The Roles are antagonistic and are available for all member sections

[michael-e]

@brendo, are there any news on this issue?

It won't be possible for a member to be logged into more than one section at a time

Will Members maybe overcome this limitation? Let's say I have two websites delivered by a single Symphony installation, could it be possible two have "virtually independant" members accounts for these websites?

[brendo]

Yeah, it will. I'm working on Members this weekend for 2.3 updates. This is a pretty high priority though.

[michael-e]

I just thought about the following: Since the members section is stored in the config file, wouldn't it be possible to simply use separate manifest folders (i.e. config files) for two domains (the rest of the system folders being symlinked, like in the "Ninja Domains" technique)?

[michael-e]

@brendo, I managed to add a second Members section for one of my domains by adding the following to config.php:

if($_SERVER["HTTP_HOST"] == 'example.com'){
    $settings['members']['section'] = '49';
}

It seems to work, I managed to login a Member. But in the second (additional) Members section, the Member Role field is broken (displays the first role in the list, selectbox is inactive). Do you have any idea why this happens?

[michael-e]

I must have been tired yesterday (or maybe I am an idiot?). The condition which I added to the config file does not work in the backend, of course. :-) So here is the complete hack to use a second Members section for a second domain:

if(   ($_SERVER["HTTP_HOST"] == 'example.com')
   || (strpos($_SERVER['REQUEST_URI'], '/symphony/publish/my-section-handle/')!== false)){
    $settings['members']['section'] = '49';
}

After adding the above code at the end of the config file, I am able to use the second Members section. I haven't tested everything yet, but it should work.

@brendo: If Members is changed to allow these things without hacks, we may have to account for a lot different scenarios.

[brendo]

The changes this issue was about was logging into two different sections in the same install (So Customers and Agents etc.) and not really for cross domain accounts.

I would be curious about your setup though!

[michael-e]

Ah, the setup is some sort of "Ninja Domains gone wild". :-) Some hundred websites are generated by a single Symphony install. It's a web app, providing frontend login for every website using global Members accounts. So using a single account, you can login on every website (and do things you are allowed to do on this website, of course). This works great with Members since I am using subdomains of a main domain for the "user pages" of these websites, and I changed Symphony's getDomain() function to always return the main domain (which means you get a cookie for .example.com). So being logged in means being logged in on every website.

So far so good. But now I have one website in this setup which is a bit special and requires its own Members section. I could, of course, separate it from the multi-domain system (i.e. use a dedicated Symphony install), but in this case I would give up a lot of other "technical connections" betweeen the websites. So I tried to use a second Members section if this website (i.e. the "special domain") is requested. (Of course, I can only use one Members section per website, but that's OK for me.)

[michael-e]

I also managed to allow technically separate logins by changing the cookie prefix:

if(
    (
        $_SERVER["HTTP_HOST"] === 'example.com'
        && strpos($_SERVER['REQUEST_URI'], '/some-uri-still-using-default-members-section/') !== 0
        && strpos($_SERVER['REQUEST_URI'], '/another-uri-still-using-default-members-section/') !== 0
    )
    || strpos($_SERVER['REQUEST_URI'], '/symphony/publish/second-members-section-handle/') === 0
){
    $settings['members']['section'] = '49';
    $settings['members']['cookie-prefix'] = 'sym-specialprefix';
}

I know that doing this in the config file is a terrible hack. I am sure that there is a much more elegant way, so I am looking forward to learning from your additions and changes to Members! Maybe there is a delegate in Members which might be used to change the configuration?

[michael-e]

It should be noted that what I do here is very dangerous. If ever during page creation the configuration was saved, I'd be lost. :-)

I guess that the planned additions would suffice for my use case, so I can probably switch to a newer version of members — assumed that there will be a 2.2.5-compatible release. If the latter is not the case, I can maybe backport the new functionality into the 2.2.5-compatible branch.

Just one question, @brendo: Technically, does it make any difference if I hack the config file (like above) or use Symphony::Configuration()->set during page creation? In both cases Symphony's configuration object is "modified", isn't it?

[brendo]

Just one question, @brendo: Technically, does it make any difference if I hack the config file (like above) or use Symphony::Configuration()->set during page creation? In both cases Symphony's configuration object is "modified", isn't it?

Yeah, it doesn't matter either way. Hacking the config.php file is less future proof (especially with XML config files on the horizon #669), but if it's a Symphony 2.2.5 build (and sounds like it will be for quite a while), it's your fastest option.

Interesting setup too, might have to pick your brains more about it in the future ;)

[michael-e]

@brendo, just a short update: Hacking the config file is no good idea if you ever save the Symphony prefs. :-)

So I will try and manipulate the config array during page load using an extension.

[michael-e]

Well, the frontend was no problem (using the FrontendInitialised delegate). But I have serious problems to hook into the backend. I tried using the AdminPagePreGenerate delegate, but it's too late, obviously, to manipulate the Members section. (I need to do this in the backend when the section's index or entry edit page is displayed.) I tried the following:

public function adminPagePreGenerate($context){

    $callback = Symphony::Engine()->getPageCallback();
    if(
        $callback['driver'] == 'publish'
        && $callback['context']['section_handle'] == 'my-section-handle'
    ){
        Symphony::Configuration()->set('section', '49', 'members');
    }
}

Is there a delegate that runs before the Members section is resolved?

[brendo]

Potentially InitaliseAdminPageHead?

[michael-e]

Uuuuh, you found another interesting typo in the core! InitaliseAdminPageHead — LOL!

I suggest that this time we should not try to eliminate this. It's too much hassle, isn't it?

[michael-e]

I tested the InitaliseAdminPageHead delegate. It's fired too late as well. At this stage Members already read the config.

Well, it's OK. The frontend "hack" is done by an extension (properly), and for Symphony's backend I can live with hacking the config file (if necessary).

[brendo]

For all that are interested, I've written a Wiki about the Multiple Sections implementation just so everyone is aware of the future, and for feedback!

[designermonkey]

Oh you diamond! Nice one.