Symphony.

This is in answer to Nick's question about what sort of author access I might be looking for in Symphony.

I was hoping to have at least the same functionality as the Author Registration extensions that I had commissioned the Twentyone Degrees team to build for me for Symphony 1.7. Now that we've moved on to Symphony 2, the extensions would need to be rewritten to work within the new extensions API.

Without the knowledge to rewrite these extensions, I created my ensembles as proof-of-concept experiments in building the front end forms to simulate and extend the default Symphony admin pages. They were originally built as possible workarounds for the lack of author access control in Symphony 2 beta and for the usability issues that arose with the proposed functionality for section links.

It seems my proposed solutions, and their own ideas for solving the performance issues around building XML and database interaction, inspired the Twentyone Degrees team to scrap Symphony 2 beta revision 5 in favour of developing revision 6, what we are now calling Symphony 3. I don't know if I inspired the team to think about rebuilding the Symphony admin to be powered by XML and XSLT, but if I did, it seems I may have inadvertently delayed the official release of Symphony 2 for everyone.

While I applaud the direction the Development Team has chosen, especially now that Symphony 2 has become much more of a community effort with its open source release on Github, author access is the one major piece that I find is still missing. Without it, it's difficult to realize my ideas for an all-in-one Design Business Administration system running on Symphony.

At Domain7, we've been strategizing on the best way forward in regard to project management and CRM for our clients. We've been building onto our own proprietary solution written in Perl for the past dozen years, but it seems the time has come for us to take a new direction as clients are seeking to avoid proprietary systems and vendor lock-in. I'm pushing hard to propose Symphony as the best way forward, or at least part of the solution. The ideal system would utilize a single user login, probably using OpenID, for clients and staff to access tools for creating, managing and collaborating on site content, tracking project progress, costs and revenue, and developing strategies around site analytics and financial reports.

Without a more robust user-authentication system, it becomes more of a challenge for me to sell Symphony as a solution. When clients are requesting Drupal and Magento implementations, it's hard to argue otherwise when user access and ecommerce systems would need to be built from scratch for Symphony.

That said, Nick, I'm itching to integrate your work into what I'm working on. We finally have an ubuntu server dedicated to running PHP. I needed to enable libxslt for PHP by installing an XSL module to get Symphony running. For anyone interested, I logged in as root and installed the XSL module:

apt-get install php5-xsl

Then restarted the server:

/etc/init.d/apache2 restart

And I was good to go.

So far, I've got the Fluid 960 Grid System working in Symphony as a set of XSL templates. Then, I've extended the available layout and HTML structures to simulate static content including news, articles, comments and feeds, as well as blogs and calendars. The only database interaction is for pages and a static XML data source for the calendar months.

The Current State of Author Access

I'm pitching the idea to our team of either developing an Author Access Control extension inhouse or collaborating with anyone else who might be interested in adding this functionality to Symphony. I have tentative approval, pending the discovery of any existing extensions that might already fit the bill.

As Rowan Lewis has already created a Frontend Member Manager extension, this may not be necessary. I'll be trying to decipher the inner workings of this extension, as it appears that it has not been officially released for lack of documentation.

• The official answer from the development team about author access is that it is best dealt with as an extension, suggesting the use of a front-end page with restrictions applied to that page and section-posting event.
• There has been mention of Restricted Admin Access.
• There has also been a proposal for User Restrictions in Symphony.
• Allen mentioned in June that a Membership system would be built into the core.
• In fact, Airlock commissioned Twentyone Degrees to create a membership extension, which will not be available until Symphony 2 beta revision 6, aka Symphony 2 RC1, aka Symphony 3. View the screencast for Allen's description of the feature set (see 21:00).
• However, Scott announced that they cut user roles: They were complicated and ugly.
• The possibilities of using Symphony for social networking sites was discussed.
• A native forum would require a front end authentication extension.
• Mark Lewis had also mentioned a Members extension back in April, which he also mentioned had been updated to Symphony 2, but hadn't yet been prepared for release.
• Alistair has created the beginnings of a solution with his Front End Authentication extension.
• Changes have been implemented to use sessions instead of cookies for login.
• A custom application has been built with an ACL-based authentication extension but was not generalized enough for release.

To move ahead, then, it would be great to have the input of the developers and the community to make sure we're not duplicating work that has already been done. Do we have a feature set that we can all agree on? It may even be helpful to follow the work of Mark Boulton and Leisa Reichelt of Mark Boulton Design as they try to fix Drupal for the next version: Drupal7 User Experience, also being documented on Flickr. Interestingly, they're both using WordPress.

Wow, big post. I think basic functionality would include user's being able to register an account, manager their account details, and access content depending on their role. One of the key features for me would be integration with other extensions (using delegates in extensions?), e.g. establishing networks of members for social networking, or linking an e-commerce system to the user's account. I haven't looked at the extensions available, but naturally you should pay extra attention to security when you are dealing with sensitive information.

I can see that user restrictions are very important when creating a complete design business administration system with Symphony. However, it is my opinion that it is not the only (solid) functionality that is still missing in Symphony. I can think of much functionality that is required in a great portion of websites. While s2 has been a great improvement over s1.7 (not only) community wise, the fact is that most of us don't have a lot of time to spend on developing extensions if they are not required by our projects. Also, I find myself developing quick fixes to solve problems instead of developing a full extension that could also be applied easily to other projects. If I choose to pursue my design business after I graduate, the benefits of developing extensions would be much greater, and I would be glad to release them here (like you are doing with author access control). So, thanks already!

One idea that I think has been touched on before (maybe even in regard to Bauhouse's work) is the potential for modular applications that go beyond extensions, but have the ability to be integrated into an existing Symphony site. While an extension would be required to install such an app, the app itself would be comprised of Sections (new or linked to existing ones), datasources, and xsl templates (rather than the data being siloed into some extension's proprietary DB tables).

I envision an extension that could parse an application definition (such as an xml file) assembling the required Sections and DSs, and writing the necessary xsl files and other assets to the site. If an app's datasources could be namespaced, the associated XSL could be written for that namespace, avoiding xsl collisions.

Though it wouldn't be used in the transform itself, you could likewise namespace sections themselves (defining field types individually, but also a Section as a whole), to allow Apps to 'understand' what data is already on the site. In this way, for instance, a membership Section could be linked to by additional installed apps such as a blog's 'author' field.

I realize that Symphony's flexibility and customization are it's greatest strengths, so 'modules' might not seem like a good idea. I'm of the opinion, however, that the more idiosyncratic data modeling is done by extensions (i.e. outside the Section/DS interface) the less flexibility we'll be left with, and the more like a -gulp- normal CMS Symphony will become. That is of course NOT to say that the extensions being produced currently aren't awesome and of great value to Symphony.

@ashooner, I'm with you and Nils on the modular idea, although I'm not sure how it might be implemented. If it comes with flexibility trade-offs, then I'd probably opt for the flexibility and the extra work involved in customizing each custom field of the required sections. It's amazing how lazy we can become, when Symphony makes these tasks so easy.

Perhaps what we need is something that does the reverse of nickdunn's Section Schemas extension. Rather than build XML based on the Section Schemas, the extension could build the database tables and fields based on a supplied XML structure. It's then just a matter of passing around an XML file and the corresponding XSL stylesheets to install the module. Modify the XML and XSL if you need it customized a little differently.

@bauhouse, please email Alistair and see if you can get your hands on the already working membership extension. This extension is what we are using for the new Overture website that's currently in development.

@Allen, thanks. Email sent.

A membership extension?

All of us are waiting for this.

I think there is a dual requirement lurking in here and it will be complicated to satisfy both. It may require two extensions with some cross-over.

With the sites we build at Airlock we come across three broad requirements for user management: Symphony users (Authors) and site registrants (users). They both have subtle differences.

1. Symphony users (client author logins)

For the clients to manage their content we usually provide Symphony logins, with an Authors role. By locking down which sections are displayed on the Publish menu you can quite easily restrict their access. However once or twice we have had the requirement to add additional roles to this — to display sections or navigation options provided by extensions depending on this role.

To achieve this, rather nastily, we have used the Last Name field as the role so as not to affect other parts of Symphony reliant on the Author/Developer role value. This allows us to check the Last Name (role) in extensions and provide access accordingly.

This seems to be similar to what Bauhaus is after — a tighter user access mechanism within Symphony itself, to allow users or groups access to specific functionality within the CMS. I imagine this could be resolved by extending the roles drop down (currently Author or Developer) to make it dynamic, and the ability to choose which sections they have access to.

Some of us develop very complex workflows within Symphony itself, using Extensions. For this purpose, a Symphony user registration extension (the Author Registration extension) is what is required — storing users in the "sym_authors" table, as Symphony authors.

2. Front-end users

Many of our websites provide user registration such as competition entrants, user-restricted areas etc. There are generally more than one "type" of user. For example one recent site had two types of front end user — Band and Fan, so we created two sections (Bands, Fans) to store information related to these objects, and a generic Users section to hold the login-specific data (email, password). By sharing the Users section among types, the login system needs to query one section only.

The registration process inserts both entries (e.g. the Band along with their name, genre, track information; and the User with their email and password).

This second example fits the same concept as Rowan's Frontend Member Manager extension (I think) — when configuring the extension the developer decides which fields are the Username and Password fields in their desired Section.

3. Custom CMS users accounts

Some of the time the CMS requirements are too complex for the Symphony UI. In these instances we build our own UI layer using XSLT and Symphony Events to provide a custom CMS. These also require user accounts and we use #2 above, with a Users section and our own login scripts. However these systems also require access roles, and are usually achieved using a Role select box and checking its string value in XSLT to determine access rights to specific functionality.

This is what makes it very difficult to build a generic login system, because we all have our own unique requirements. I personally think these two types of user management should be kept discrete. I'm not keen on the idea of storing front-end users inside the Symphony authors table.

My thoughts:

Symphony access control

• a role based system (extending Authors and Developers) to provide granular control over which Sections an author can see
• even finer control perhaps over the ability to create, read, update and delete entries in each section?
• allowing Extensions to expose these options as well so that an Extension may limit its functionality based on whether the user has been granted Delete rights to it (although I can only think of very few where this might be required at present)

Front end user control

The requirements for this are probably best left to another discussion after the direction is chosen. But would likely include things such as: password hashing, register/login events, email confirmation, password reset etc.

Bump.

Sorry, Nick. Not trying to ignore you. Just a couple days of back and forth with Alistair, kicking the tires on the Members extension that is currently being used for the development of the new Overture forum. There were a few bumps in the road. The latest additions to the symphony-2 integration branch were fixes to get the extension working.

As this extension is not mine to release, I'll let the development team choose the time to release it. I asked the question:

Is there a particular reason this extension is not being released to the wider community?

The response:

No worries. The main reason was that, until a couple weeks ago, it was running on rev6 code. I had intentions of releasing it when the new overture site was complete.

I only just got the extension working last night using the latest integration commits, so I'll continue to kick the tires today. I'm building a client intranet using Symphony to build the prototypes. This extension might enable me to build the whole thing in Symphony. As the Members extension creates its own tables to manage users, it does not address the first case you outlined: 1. Symphony users (client author logins). But it looks like everything has been covered for the second case: 2. Front-end users.

That's good news that it covers front-end users. I'll sit tight and wait until it is released. With a bit of luck it'll be extensible so we can fork and add any missing features that we may need (password reset, custom welcome emails etc).

The extension can do custom welcome emails.

Woop :-) Looking forward to giving this a go when the time is right.

Wicked.

This looks awesome. I can't wait.

whoa.

Unfortunately, I haven't had a lot of time lately to do a lot with the Members extension so far, but anyone who wants to meet up at An Event Apart in Seattle can get a prerelease copy of the Members extension from me. See you tomorrow, Dave.