Membership management tool

jakob · 2010-07-16 17:46:12

There are different approaches to membership or community sites and some are better dealt with as a separate password-protected section and some could conceivably be handled through the core. It very much depends on the amount of editing functionality you want to offer to your members and whether they should use (or can be expected to cope with) the textpattern admin area, plus perhaps additionally what user management facilities you need (that is better handled externally, see below). For example:

it makes little sense to duplicate most of the backend in a password protected area. In this case it may be better to style and dumb down the backend instead to remove extraneous items. For an example, see Gil’s Q4T site infos.
if only user input is required without membership, e.g. article submissions, try mem_moderation which allows you to direct data input into a front-end to particular fields in textpattern. See here for an example.
If you have a very specific workflow or need to provide only specific functionality, a password-protected area that offers just that functionality can make sense so that user’s don’t have to get to grips with the whole backend.

Three examples of different approaches (sorry recycling some of the aforementioned but with the intention of comparing approaches):

This site allows different authors to contribute to a common site using txp’s admin area. They only see their own articles, their own images, their own files and can publish only to their own section. Depending on the categories they choose the content appears together with content from other staff publishers on the same site. There’s a custom plugin used for the user profile and for creating the user’s section when they sign up. You can see how it works on the help pages. It runs on a slightly modified installation of txp with the addition of a few new privs (some but not all of which are now in the core) to allow the listing/saving/deleting of own articles, images and files only. An additional plugin replaces the section drop-down. In effect a single textpattern installation can be used by multiple authors at once like a series of blogs within a common site. Some of what I did back then is now possible with plugins (e.g. smd_bio) or the new txp pluggable-ui (restricted section drop-down). Currently this is, I think, not all doable with plugins alone but all the core would need is a few privs and respective handling to list only one’s own articles, images, files.
The BISA conference site Stef linked to isn’t strictly conceived as a membership site – in that particular case it is more about facilitating a rather specific workflow, but it could be used that way. The principle is not dissimilar to Dale’s client section proposal even if the implementation is different (we used rvm_if_privileged to get around a specific problem but ign_password_protect worked fine for the edit panes too). mem_simple_form + mem_form are used to allow you to write directly to the database from a front-end form and smd_query is used to retrieve existing data from the database to pre-fill the form when editing. There are a number of hurdles to overcome in detail but that is essentially the principle. Manfre has since released mem_public_article that may make that all a bit easier now. In essence you write your own edit forms for a particular purpose and just need to password protect those areas.
Jonathan’s Protennis jobs and classifieds site does handle subscriptions using an external subscription/membership script to deal with account handling, payments, renewal etc. and essentially then hands over to a protected area of the txp-based site. I believe he’s using mem_moderation (+ _image) for that particular site. Again he’s supporting a particular workflow with limited input options for the users hidden behind a password-protected area.

To come back to your questions:

How is it possible to use these plugins and have a area where people input their own data – I’m not getting that yet :(?

See the mem_simple_form / mem_form + smd_query combo above or try mem_public_article. mem_moderation is also an option if you want a moderated workflow.

How is it possible to ask a client to perceive a category as a person, or product, or whatever… is there a way to alter this?

Because with the above plugins you design your form how you want it to be, you can word it how you want. With mem_simple_form you specify the database field that the submitted form data should write to so you could make a simple drop-down called, say, “Director” with the options “Martin Scorcese, Woody Allen, Ridley Scott…” and make the submitted form allocate the choice to Category1 (which you would have to set up in advance of course). The visitor need not know that they are choosing a category at all.

Last edited by jakob (2010-07-16 17:50:19)

maverick · 2010-07-16 20:59:23

jakob wrote:

There are different approaches to membership or community sites and some are better dealt with as a separate password-protected section and some could conceivably be handled through the core. It very much depends on the amount of editing functionality you want to offer to your members and whether they should use (or can be expected to cope with) the textpattern admin area, plus perhaps additionally what user management facilities you need (that is better handled externally, see below).

It seems to me there are perhaps three inherent considerations related to members/users/authors:

A “Primal” Consideration – Is Txp primarily a Content (Article) writing and Content Publishing System that also has some content management capabilities or is it primarily a Content Management System? Given it’s philosophy, awesome tag language, and approach in having articles be the primary content, I’d say the former. (W/out imply whether that is good or bad). This has implications regarding how Txp should approach the scope and breadth of various other content.
Less primal, but implicit in “user/member/author” interaction with a site – Should there be a differentiation between “front end” and “back end” and what should it be? The more involved a website becomes, the more blurred the lines seem to become. There used to be a plugin that allowed txp tags in the (some?) admin pages. That conceptually begins to erase the line. Personally, I find the idea of blending the two widely flexible and intriguing. “Back end” customization with Txp tag flexibility. Be still my heart.
Directly relevant to this discussion – To what extent, if any, are members/users/authors “content” to be managed? Simple authors have minimal “content” application – basic grouping around the article author for example. Members, users, etc. become more like “content” that has to be managed. Personal data, contact info, biographies, etc. Bloke’s smd_author_bio plug begins to move us there. If users/members are content to be managed, and Txp is a Content Management System, then they probably should be better integrated into the core. On the other hand, if Txp is a Content Publishing System with a primary focus on publishing articles with additional capabilities for supporting content, then the current status and plugins are probably the way to go.

A side note, fwiw, I personally dislike having to intall an additional user database in order to take advantage of all the power of some of the plugins. I’d prefer the core txp database table for users be structured to allow plugins to enhance it.

Mike

Bloke · 2010-07-16 21:47:48

Thanks all. Seems we are on the same sort of wavelength then. That’s a relief!

So, content publishing by authors is done on the admin side. For those authors that don’t / can’t handle the power of the entire admin side (even with a limited user account), you build something custom for them. By its nature this involves plugin(s); be they admin-side tweaks to turn off visual paraphernalia and streamline the worfklow or some custom, less scary front-end interface to do specific jobs.

User / profile management — either by an administrator or self-managed — can be approached in the same way. Again, plugins should be able to spring up to help here. The core’s job should be to allow it / not get in the way too much. Thus if there’s something lacking in the core that can really help open this area up to plugins, someone please raise a feature request / patch and we’ll see what’s feasible.

On this subject of users I originally thought, as I posted above, that searching the user table would be fairly useful. But thinking about it further in the last hour or so, I wonder how many people routinely have more than a handful of TXP users? Having 100s/1000s of users is the domain of a more customised solution than TXP is designed for out of the box so it should be feasible for a plugin to offer this rather than it being built in. Perhaps another callback somehow might be useful on this tab to allow plugin authors to offer searching/filtering? Of course, searching/filtering is always available on the front-end with some smd_query magic :-)

Also remember that an increase in the number of users adds an increased security risk to your site because you can guarantee that a large percentage of them will choose crap passwords :-p This leads me to…

I personally dislike having to intall an additional user database in order to take advantage of all the power of some of the plugins. I’d prefer the core txp database table for users be structured to allow plugins to enhance it.

Do you mean third party subscriber systems like aMember? Or the fact that smd_bio and ign_password_protect (for example) install their own user tables? From my perspective, smd_bio could have extended the existing txp_user table but I wanted to keep away from it simply because if anything did go wrong somewhere, the raw user data is shielded from the plugin.

“Back end” customization with Txp tag flexibility. Be still my heart.

:-) I’ve had a few thoughts on this and made one stab at a very specific admin-side tag (sort of) and it’s rather useful. There’s a long way to go before I consider it worthy of even showing to the world though! In this one case I can see it being of immense value to plugin authors, but this kind of thing really is the domain of ‘complete admin-side rethink’ rather than ‘incremental change’ so don’t expect this idea to take off. At least in TXP.

Last edited by Bloke (2010-07-16 21:48:53)

maverick · 2010-07-18 21:45:58

Bloke wrote:

Do you mean third party subscriber systems like aMember? Or the fact that smd_bio and ign_password_protect (for example) install their own user tables? From my perspective, smd_bio could have extended the existing txp_user table but I wanted to keep away from it simply because if anything did go wrong somewhere, the raw user data is shielded from the plugin.

I am thinking in terms of simplicity. Specifically in terms of ign_password and smd_bio. Even more so, though, for something like aMember. aMember adds a lot of power features, but with it comes much more complexity in trying to get two unrelated software installs to cooperate – and upgrades that may or may not break the link.

W/ ign_password and smd_bio, though, some of the same variables remain. It is much more likely an upgrade process will go well, and compatibility will be retained. However, if user info is in specialized plugin tables, and that plugin ceases development or is super ceded by something greater and better . . . you have a bunch of data to migrate. If all the plugins are working from the same data table, then migration and forward compatibility is more probable (then again, perhaps that’s an idyllic wish rather than a cold hard probability).

Of course, hopefully you and igniter never leave the txp fold. But life has taken Dean, zem, rob sable, and several other heavy weight developers/plugin developers who were “cornerstones” in new pursuits, and it’s silly to imagine that it will never happe again.

:-) I’ve had a few thoughts on this and made one stab at a very specific admin-side tag (sort of) and it’s rather useful. There’s a long way to go before I consider it worthy of even showing to the world though! In this one case I can see it being of immense value to plugin authors, but this kind of thing really is the domain of ‘complete admin-side rethink’ rather than ‘incremental change’ so don’t expect this idea to take off. At least in TXP.

such a txp tag tease! :P

Of course I love complete “re-thinks”. It helps keep methods and applications fresh and relevant. Provided the underlying purpose and values remain constant.

Perhaps part of the tension is the edge cases are trying to push txp into more of a application framework that allows txp to be a development tool for designing a relational database, a development tool for the user interface for that database, and the publishing tool for the content of that database.

For example – at my last job I would have loved to have developed Txp into a Church Management Software (ChMS). With enough mods, it could do a lot of it. But there would be a lot of custom fields and plugins to design the database, and a lot of customizing to create user interface for the membership interface, all to use the beauty of txp tags. I may still try it some day to see if I can do it to my satisfaction, but txp really isn’t designed for this.

Wistful sigh.

:)

Bloke · 2010-07-18 23:11:37

maverick wrote:

If all the plugins are working from the same data table

Where’s the fun in that? ;-)

then migration and forward compatibility is more probable

Hmmm, not sure the location of the data makes a difference to a developer’s wish to take something on, but it causes more fundamental problems. For example, ign_password_protect has the phone field which — in your one-table scenario — would be added to the txp_users table. In smd_bio, someone could decide they want to collect a phone number and call it ‘phone’. Clash-tastic. At that point you have to choose whether you want your users to be able to maintain their phone number from smd_bio, along with their other bio data, or they have to visit a different admin-side tab to edit their phone number. Or you have to rename your phone field in smd_bio and tell them not to use the one on the ign_pw_protect config screen. Or, worst case, you have to uninstall ign_password_protect and find/write another plugin to handle member logins (or vice-versa, uninstall smd_bio).

So having stuff in custom tables that augment the existing structure — besides being safer — does enable plugins with similar feature sets to co-exist. smd_tags and tru_tags is another example, and in the upcoming version I’ve gone to the trouble of allowing you to migrate (copy or move) your tru_tags or rss_unlimited_categories into smd_tags so you don’t have to start from scratch.

I would have loved to have developed Txp into a Church Management Software (ChMS)… I may still try it some day to see if I can do it to my satisfaction, but txp really isn’t designed for this.

Correct. TXP is not the tool for this at present. As it matures into a more capable platform — where plugins can do more and more useful stuff — you will be able to get closer.

But for these types of project you may simply be better off investing some time into a system I am aware of (that I can’t reveal at the moment, sorry) that can use its front-of-house tags to build the admin interface. Shhhmokin’!

maverick · 2010-07-19 17:36:26

Bloke wrote:

having stuff in custom tables that augment the existing structure — besides being safer — does enable plugins with similar feature sets to co-exist. smd_tags and tru_tags is another example,

Totally makes sense from that standpoint, and is the reasonable course of action consequently.

My thought was more along the lines of “what if”. . . .

Like, what if someday “users” were treated more like specialized content — like links or files. And what if we could associate custom fields (including glz_custom_fields) on the “specialized content” pages. Then there would be no need for specialized user plugins to add additional fields. . . But that as your examples show, the plugins work.

As it matures into a more capable platform — where plugins can do more and more useful stuff — you will be able to get closer.

cool.

But for these types of project you may simply be better off investing some time into a system I am aware of (that I can’t reveal at the moment, sorry) that can use its front-of-house tags to build the
admin interface. Shhhmokin’!

Your making my heart beat fast! :D It’s like waiting for Christmas morning until you can reveal it! :)

Textpattern CMS

Textpattern CMS support forum

#25 2010-07-16 17:46:12

Re: Membership management tool

#26 2010-07-16 20:59:23

Re: Membership management tool

#27 2010-07-16 21:47:48

Re: Membership management tool

#28 2010-07-18 21:45:58

Re: Membership management tool

#29 2010-07-18 23:11:37

Re: Membership management tool

#30 2010-07-19 17:36:26

Re: Membership management tool

Board footer