smd_bio : store additional biographical info about your users

whaleen · 2011-12-08 23:44:32

Bloke wrote:

But smd_bio is coded to only target the txp_users and smd_bio tables so, no, it won’t offer any help on the article side of things.

Good to know. I assumed this was so but wanted to be sure. :)

Ahem, I kind of half spotted this yesterday but didn’t get round to investigating fully before I threw the code out there. I’ll check it.

The aim is that using show_empty=“1” in your surrounding <smd_bio_info> tag enables you to show missing fields or empty content. Not sure if it’s working how I intended though so I’ll give it a grilling, thanks for reminding me.

<txp:smd_bio_info show_empty="1"> works as you intended on my end. Thanks for letting me know. Twas for the lack of it that it did not work as there was no it.

New Thought 1: How to offer an image upload/replace field to a edit profile page. In the land of ideals crop/edit too. I know Manfre has a image moderation form so with this form something along these lines is where my mind goes:

bypassing the moderation cue (cue ain’t even working in TXP4 though)
pushing the auto-approved image’s id into the image field in a bio edit form
javascripting out a one button approach

Do you have any ideas in mind for another approach or is there a smd_bio_image_edit tag? :)

Bloke · 2011-12-09 00:48:16

whaleen wrote:

How to offer an image upload/replace field to a edit profile page.

I never got mem_moderation_image to work right. I assumed pebkac on my part because I’m sure other people have used it successfully.

smd_bio takes the lowest common denominator approach wrt images: it assumes you have already uploaded images to Txp and references them by ID only. Everything else about fetching the actual images is mere trickery.

Clearly in the new public-facing direction that smd_bio is heading this is a problem because it becomes difficult to ask users to fill in their profile info but, by the way, you should just log into Txp, hop over to the Images tab, upload your image, assign it to the correct parent category and make a note of its ID then put that in the text box next to ‘Mugshot’. Yeuchk!

Although I’ve never done it with smd_bio I remain utterly impressed with uploadify and would hazard a guess that this would be your best bet for fulfilling this gap. The general user workflow becomes:

User sees a ‘Mugshot’ heading and placeholder image. This is just created from smd_bio’s Title and NOT the widget, since the widget for an image renders a text box. However, you add a hidden form field with the same name as the smd_bio field because that’s where the ID is going to go.
Next to the Mugshot is a Browse… button as supplied automatically by uploadify, after some pre-configuration on your part.
User clicks browse, finds required visage and says OK.
Uploadify uploads image via AJAX to Txp’s temp directory and hands over control to a custom PHP script on the server.
Script runs, inserts image meta data (width, height, category, etc) into txp_image, then moves file to /images dir and renames it NN.jpg. Thumbnail created too, if required.
Page (jQuery) is notified of AJAX response. The response simply contains the new image’s ID.
jQuery fashions a full http://site.com/images/NNt.jpg link and sets the placeholder image’s src attribute to that URL. It also injects the ID into the hidden ‘mugshot’ form field.
User continues to fill out bio data, hits Submit and all bio data is sent to the server.
The bio data includes the hidden value of the image ID that has already been inserted into the Txp database by uploadify, thus smd_bio stashes the ID in the ‘mugshot’ bio field and the plugin is happy that the image exists. Both admin-side and public functionality now work perfectly by fetching the image via its ID, as if you had uploaded the pic via Txp’s Images tab.

It sounds complicated when written out as a set of steps, but once it’s set up the user experience is seamless and natural. The slight spanner in the works is if the user decides they don’t like the image they first chose and wants to select a different image prior to saving the profile for the first time. How you handle this is down to you. Options:

upload a new image with a new ID and just leave the old unused pic floating around the system / database until one day you notice it and purge it.
send the ID of the first image that was uploadified in this session as custom data to uploadify’s PHP script. If this custom data is NOT present, assume you’re dealing with a brand new image and assign a new ID. If the data is passed in, do an UPDATE / replace file instead of an INSERT / create file.

There may be other tools out there that can do this kind of thing or slicken up the process, but uploadify has never let me down so I swear by it. If you’d like to get hold of an uploadify / Txp mem_form / PHP / jQuery script set for inserting images into the database and sending back the necessary data to make all this happen… ask jakob politely :-D I’ve probably got a version hiding on a drive somewhere, but he’s way more organised than I am so will likely be able to lay his hands on the code before I’ve even managed to shovel enough coal into the furnace to power my ageing computer.

whaleen · 2011-12-09 02:03:51

Bloke wrote:

ask jakob politely :-D

Dearest Jakob,

Might you let me glance at, if your not too busy, a copy of uploadify / Txp mem_form / PHP / jQuery script set for inserting images into the database and sending back the necessary data to make all this happen?

In TXP,
Josh

Sounds kind of heavy to have to run all that, but for the sake of keeping the power and flexibility of txp tags intact I reckon it’s worth it. Well worth it now that I’ve pondered that. I’m tempted to give users the option for a gravatar only if they are so keen on showing their face but that extra step cutting into their time so am hesitant.

Thanks for all your fine words Stef. I’ll be tinkering along with smd_bio and will let you know what I discover good or bad. Looks ship shape though so far. With the exception of the images fields requiring sending users into the back 40 I’ve been able to successfully test each kind of field in a form or another to be sure the user will give the db all their data without difficulty.

milosevic · 2011-12-12 18:58:51

Whaleen: Perhaps he will see your message before if you contact him by e-mail …

(Yes, I`m really interested too in his answer!).

Last edited by milosevic (2011-12-12 20:05:32)

whaleen · 2011-12-12 20:01:47

milosevic wrote:

Whaleen: Perhaps we will see your message before if you contact him by e-mail …

Thanks for the reminder. I got distracted with other parts of my project. Writing him now. I will post back when I get something working, hopefully with some help from Jakob.

jakob · 2011-12-12 22:04:46

Sorry missed this. I’ll have a look later tomorrow. It wasn’t in conjunction with smd_bio, though but with smd_query and mem_simple_form. It works pretty much as Stef describes but it was a few years back (2009) and the version of uploadify used may well be out of date…

Bloke · 2011-12-12 22:07:00

jakob wrote:

I’ll have a look later tomorrow

Thanks, I can’t for the life of me find the one you did for BISA. Might have purged that directory when I ran out of disk space, which is pretty lax of me. Sorry to put you on the spot like this.

aslsw66 · 2011-12-14 11:11:24

Damn! I feel the strong pull of cbe_frontauth, smd_bio, mem_form, maybe even smd_user_manager and a sprinkling of smd_query (as always) to completely re-engineer my user login and maintenance processes, instead of continuing with the hacked around version of ign_password_protect and ign_user table.

I know they always say “if it ain’t broke…” but it sounds like this can now do everything I want: (1) front-end login for registered users and (2) front-end user management for managers but with (3) easier database and Textpattern maintenance for me.

Bloke · 2011-12-14 11:33:00

aslsw66 wrote:

Damn! I feel the strong pull of cbe_frontauth, smd_bio, mem_form, maybe even smd_user_manager and a sprinkling of smd_query (as always) to completely re-engineer my user login and maintenance processes

You know it makes sense :-)

Slightly off-topic here but you can augment some of the stuff in cbe_frontauth with the new <txp:smd_um_has_privs> tag in smd_user_manager. As well as allowing you to check if the logged-in user has certain privs (or is below/above a certain priv level using the < and > syntax) you can also see if they have privs to custom priv areas you define from the admin side. e.g. in a Txp Section called ‘special’ you could put this on the Page template:

<txp:smd_um_has_privs area="special">
   <h1>Welcome to the Customer area</h1>
   blah blah exclusive options
<txp:else />
  Sign up now to get access to all this extra goodness:
  blah blah
</txp:smd_um_has_privs>
...

and when they sign up, make sure they’re put in a user group that has access to the ‘special’ priv area. That’s also a nice way to allow front-end managers to edit things. Fringe benefits:

it can be easier to debug/manage than “is user in user group xyz”
you can temporarily bump a group’s privileges to give them access to somewhere without giving them more admin rights than they need in other areas
you can phase in different parts of a site, e.g. adjust your access mechanism to <txp:smd_um_has_privs area="special, gold-club">, assign yourself to the gold-club priv area for testing, then when you’re ready to switch it on, just add it to the relevant user groups and pimp it in your marketing blurb

Bloke · 2011-12-14 16:07:49

Just updated the beta plugin yet again. This version:

Fixes a couple of minor rendering bugs when using widgets
Adds more HTML 5-esque input types:
- number (with min/max/step sizes)
- range for input sliders (with min/max/step sizes)
- email
- URL
- more date formats: date, time, month, week as well as the original datetime, which has now been upgraded from a boring text type in compatible browsers

I think the only missing ones right now are search, datetime-local and color. If they’re high on anyone’s hit list I’ll try and add them, although I think only Opera supports them properly (and makes a damn fine job of it, I might add). Chrome seemed to render the date/time widgets in an earlier version but I just updated it to 17.some.such and they’ve all gone. Odd, but Google: meh.

Enjoy the new types. This must be getting close to a release by now but I keep finding little niggles as I stretch it… hopefully not too long now, thanks for your patience and heaps of thanks for the people willing to use the many many many betas and report their findings.

Last edited by Bloke (2011-12-14 16:11:48)

milosevic · 2011-12-15 16:39:12

Bloke: I trying the widget mode with the last beta (broken link in your post) and it rocks!

What I miss is a bit more of power to control the form HTML output. Cover all posibilities is really hard, but I think an “inputclass” param to style de HTML input/select/textarea elements will be fantastic.

Last edited by milosevic (2011-12-15 16:41:54)

Bloke · 2011-12-16 15:52:08

milosevic wrote:

I trying the widget mode with the last beta (broken link in your post) and it rocks!

Thanks. The link works for me now: perhaps my hoster was having a problem when you tried it.

an “inputclass” param to style de HTML input/select/textarea elements will be fantastic.

You can sort of do this by adding the breakclass attribute to the surround smd_bio_info. It’ll add that class to each <txp:smd_bio_data> item. Admittedly it’s not very smart yet and uses the same class for every element. I noticed this drawback the other day when I came to use it so I’m thinking about some way to fix this but it won’t be for a few days.

Textpattern CMS

Textpattern CMS support forum

#169 2011-12-08 23:44:32

Re: smd_bio : store additional biographical info about your users

#170 2011-12-09 00:48:16

Re: smd_bio : store additional biographical info about your users

#171 2011-12-09 02:03:51

Re: smd_bio : store additional biographical info about your users

#172 2011-12-12 18:58:51

Re: smd_bio : store additional biographical info about your users

#173 2011-12-12 20:01:47

Re: smd_bio : store additional biographical info about your users

#174 2011-12-12 22:04:46

Re: smd_bio : store additional biographical info about your users

#175 2011-12-12 22:07:00

Re: smd_bio : store additional biographical info about your users

#176 2011-12-14 11:11:24

Re: smd_bio : store additional biographical info about your users

#177 2011-12-14 11:33:00

Re: smd_bio : store additional biographical info about your users

#178 2011-12-14 16:07:49

Re: smd_bio : store additional biographical info about your users

#179 2011-12-15 16:39:12

Re: smd_bio : store additional biographical info about your users

#180 2011-12-16 15:52:08

Re: smd_bio : store additional biographical info about your users

Board footer