smd_bio : store additional biographical info about your users

Bloke · 2009-08-09 16:36:35

Requires TXP 4.2.0+

Collect additional data about each TXP author in your Textpattern site. Think of it like Custom Fields for authors.

This plugin allows you to completely customise extended bio information for your user base. From simple text-based input controls such as phone numbers and addresses, to radio, checkbox and select lists of items. Even add an image/mugshot using an integrated dropdown image picker.

You are advised to, in this order:

Read the (thankfully fairly short!) docs ;-)
Visit the Extensions->Bio Config tab and configure additional fields of data you wish to collect
Visit the Admin->Users tab to see all the extra input fields for your authors to fill in
Go nuts

Please be aware that, although this has been implemented on live sites, it’s still rather beta-ish so don’t get too attached to your user data. Or if you do, keep a backup ;-)

At the moment — under the hood — things are pretty much all stored as either VARCHAR or TEXT. This is fine but it would be nice for the plugin to be a bite more intelligent and store things in an appropriate data type. If I do manage to do this I’ll try and migrate your data on upgrade but I can’t guarantee it. Then again, I might not be able to manage it and the plugin remains as it is. Bit of a gamble!

The plugin makes extensive use of callbacks and wet’s spiffing new pluggable_ui() system to do all the clever stuff, so my hats off to him for making this possible. It really is awesome what you can do with 4.2.0, and much more efficiently than before.

What I’m especially interested in at the moment is any areas of improvement in the workflow, the configuration management, and the client tag. Any feedback from this is much appreciated.

As extension homework I’d like to know if it’s possible using mem_simple_form / mem_form / mem_self_register to populate the bio data from the client side. The input fields can, in theory, be determined from the smd_bio_meta table so you could probably build the input widgets on-the-fly such that they always reflect the current admin side widgets. If anyone is willing to experiment with this I’d love to know how you get on and if the plugin / tables can be improved to ease this task — here’s looking at you, johnstephens :-D

So, go and grab yourself a copy, and get all bio-like.

Revision history
————————

All available versions and changes are listed here. Each entry indexes the relevant post(s) in the thread to learn about the features.

14 Jul 09 | 0.1 | Initial (non-public) release
21 Aug 09 | 0.2 | First beta release ; removed image/thumb output ; experimental options attribute removed ; container/form accepts TXP tags ; fixed textbox size limit (thanks MattD)
31 Aug 09 | 0.3 | Removed item attribute ; fixed warning message if using single items ; hidden pref smd_bio_sanitize_name forces sanitized login names
08 Jun 10 | 0.31 | Javascript only appears on admin/bio tabs (thanks redbot/Gocom)

Last edited by Bloke (2011-01-19 16:44:22)

wet · 2009-08-09 17:08:54

Nice use of a few very new features. What about PLUGIN_LIFECYCLE_NOTIFY for the table setup and PLUGIN_HAS_PREFS as a launcher for the extension tab, just FTW?

MattD · 2009-08-09 17:54:08

I set the size to 100 but maxlength on the input is 25.

Bloke · 2009-08-09 17:58:32

wet wrote:

Nice use of a few very new features.

Thanks. It’s a breeze developing under 4.2.0 once you know the names of the hooks. I’ll have a go a documenting them somewhere on Textbook at some point as a study aid for budding/veteran plugin writers.

What about PLUGIN_LIFECYCLE_NOTIFY for the table setup and PLUGIN_HAS_PREFS as a launcher for the extension tab, just FTW?

You’re right. Since the new version of ied_plugin_composer has checkboxes for the new flags, it’d be rude not to tick them! I’ll need to do that anyway if I make any table mods in the next revision. Auto-updating on plugin install is miiiiighty handy.

MattD

When creating a standard text box the physical width is the first Size value and MAXLENGTH is the second. Perhaps I should make the 2nd default to the first value as well if it’s omitted, eh? D’oh, good catch, thanks!

Last edited by Bloke (2009-08-09 18:00:34)

iblastoff · 2009-08-09 20:56:08

Bloke wrote:

I’ll have a go a documenting them somewhere on Textbook at some point as a study aid for budding/veteran plugin writers.

that would be great! i’ve been away from any sort of development work for quite a while but have had some free time lately. currently have no idea what ‘pluggable_ui’ is and am finally getting around to playing with admin theming. not sure why its php class based but ahh well!

Bloke · 2009-08-09 23:03:58

iblastoff wrote:

currently have no idea what ‘pluggable_ui’ is

OT: Well the what it is bits aren’t quite finished yet, but I’ve ~~made a start on~~ put together the list of callbacks. No excuse not to flex your plugin mojo now ;-)

Last edited by Bloke (2009-08-10 00:15:00)

Bloke · 2009-09-01 14:11:44

New official unbeta Beta version available. I say unbeta because it’s in use on at least one live site (mine) and will be in use on at least one more next month.

I’ve taken the step of making v0.3 an official download because I’m happy that it does what it says on the tin. If you disagree, let me know.

One additional feature in this version which is quite useful for neatness hounds is the ability to remove dodgy characters from the login name. As it stands, TXP allows spaces and punctuation characters in login names which is great until you want to use them in URLs, then it gets messy.

smd_bio has a hidden preference which you can switch on that governs whether the login name someone enters is silently converted to a web-safe equivalent. Thus if they enter CoLIn McS£$%^qwerty! as their login name on the Admin->Users tab, it would be converted and saved as colin-mcsqwerty in both the txp_user table and the smd_bio table.

To switch this feature on, add smd_bio_sanitize_name to your prefs. Or run this SQL on your database:

INSERT INTO `txp_prefs`
(`prefs_id`, `name`, `val`, `type`, `event`, `html`, `position`, `user_name`)
VALUES ('1', 'smd_bio_sanitize_name', '1', '2', 'smd_bio', 'text_input', '0', '');

Toggle the value back to 0 to restore the original system.

N-joi!

maverick · 2009-09-01 18:38:55

Very cool sounding plugin. I’m looking forward to trying it out as soon as I have time.

In the meantime:

Bloke wrote:

if they enter CoLIn McS£$%^qwerty! as their login name on the Admin->Users tab, it would be converted and saved as colin-mcsqwerty in both the txp_user table and the smd_bio table.

Consequentially, the user would need to use “colin-mcsqwerty” as their log-in and not the form they originally entered? (Or is there some magic that translates the log-in each time?)

If their chosen log-in is changed from the form originally entered, is there a notification mechanism so the user knows what to use in the future?

Thanks

Mike

Last edited by maverick (2009-09-01 18:39:27)

Bloke · 2009-09-01 19:45:48

maverick wrote:

Consequentially, the user would need to use “colin-mcsqwerty” as their log-in and not the form they originally entered?

Correct, it will be in the modified form based on what they or someone else created on their behalf.

The good news is that it alters the login name before TXP gets its mitts on it and thus before the e-mail is sent out containing the login credentials. So the e-mail notification should (in theory at least, I was testing it locally and didn’t have sendmail installed) contain the sanitized name. Hopefully the recipient will therefore be none-the-wiser that they’ve been homogenised!

Last edited by Bloke (2009-09-01 19:46:41)

whaleen · 2009-09-12 08:37:18

I have a smd_bio item called subscriptions. It is a list of 50 states of which I can select multiple using the checkboxes that are there when editing a user. I also have a section for each of the 50 states and was sure to keep the spellings (character string) identical.

I can display articles now to registered (logged in) users which are within their ‘subscription plan’. A “subscription plan’ is the something that lets them read articles published under any state(s) which they have subscribed to.

<txp:article_custom section="<txp:smd_bio_info author="whoeverisloggedin" items="subscriptions" label="" />" />

whoeverisloggedin should be easy enough to determine using an existing plugin (once they are made TXP 4.2 ready). ign, mem_profile, and rvm are not working for me unfortunately – even when they stand alone outside of the article_cutom and smd_bio tags.

If one were able to use a mem_self_edit plugin to allow their users to update smd_bio data from the front end, as Bloke had hinted at previously, then we’re talking some seriously awesome potential. I’m imagining a user going to a section called settings where they could set all kinds of preferences. They could say I don’t want to see things in the red section… or I want to only read articles in the green and blue category, section, timeframe, etc….

mem plugin is likely capable of almost if not completely allowing this. Getting the logged in user into the author attribute automatically should be easy enough to accomplish.

I just wanted to share this train of thought/discovery. It’s really cool being able to uncheck a state (Oregon, etc…) from the subscription item and see articles belonging to the same-named section disappearing from the website. I love it!

whaleen · 2009-09-15 22:58:03

<txp:smd_bio_info author="<txp:mem_profile var="name" />" items="avatar" label="" />

Uses <txp:mem_profile var="name" /> to get the author attribute in order to use the logged in user to determine whose stuff to show.
The avatar item is an image field defined with smd_bio.
Successfully returns 6 in my rendered HTML

Now to slap all that into <txp:thumbnail id="here" />:

<txp:thumbnail id="<txp:smd_bio_info author="<txp:mem_profile var="name" />" items="avatar" label="" />" />

Funny thing is that this shows <txp:thumbnail id="6" /> when I view source. But apparently the txp tag is not getting parsed and I’ve never seen one make it to the final browser view.

Questions:

1. Is their a better way to pull a users stuff based on who is logged in?
2. Am I thinking to far beyond the scope of this plugin? Would it be better to use another plugin or something to get stuff from the smd_bio table.
3. Is it reasonable to think that the author attribute can be thought of as a container supplied by the rvm, ign, mem plugins of the world in order to trick it into to thinking that it’s talking about an author of articles rather than a user of their account?

johnstephens · 2009-09-15 23:01:40

<txp:thumbnail id='<txp:smd_bio_info author='<txp:mem_profile var="name" />' items="avatar" label="" />' />

Single quotes are required to parse txp:tags within txp:tags.

Last edited by johnstephens (2009-09-15 23:03:15)

Textpattern CMS

Textpattern CMS support forum

#1 2009-08-09 16:36:35

smd_bio : store additional biographical info about your users

#2 2009-08-09 17:08:54

Re: smd_bio : store additional biographical info about your users

#3 2009-08-09 17:54:08

Re: smd_bio : store additional biographical info about your users

#4 2009-08-09 17:58:32

Re: smd_bio : store additional biographical info about your users

#5 2009-08-09 20:56:08

Re: smd_bio : store additional biographical info about your users

#6 2009-08-09 23:03:58

Re: smd_bio : store additional biographical info about your users

#7 2009-09-01 14:11:44

Re: smd_bio : store additional biographical info about your users

#8 2009-09-01 18:38:55

Re: smd_bio : store additional biographical info about your users

#9 2009-09-01 19:45:48

Re: smd_bio : store additional biographical info about your users

#10 2009-09-12 08:37:18

Re: smd_bio : store additional biographical info about your users

#11 2009-09-15 22:58:03

Re: smd_bio : store additional biographical info about your users

#12 2009-09-15 23:01:40

Re: smd_bio : store additional biographical info about your users

Board footer