smd_bio : store additional biographical info about your users

Bloke · 2011-07-25 13:11:26

Destry wrote:

not the list article form

Odd.

Stab-in-the-dark: you are pulling out the twitter and linkedin fields into your smd_bio_info tag, right?

<div id="bio-list">
  <txp:smd_bio_info fields="url_only_title, headshot, linkedin, twitter" label="">
...

Destry · 2011-07-25 13:16:47

Not the first instance of it (like you’re showing there), but I am in the instance where the conditionals come into play, just like in you’re previous code suggestion.

Should I put them in the first instance?

Bloke · 2011-07-25 13:25:38

Destry

Ah, ok, no ignore my suggestion: that’s just me being stupid. So that form up there is your entire list form?

In which case it is odd: if it’s pulling out the headshot and other bio info correctly above the <txp:body />, then it should also do the same with the bio info below it. Can you do me a favour and throw debug="1" in either of the <txp:smd_if_bio> conditionals and see what you get back. You should see an array with the data in it if the relevant field exists, and should see an empty array() for those people in which it’s missing. If you can post some sample output (obfuscated of course) then that might help me pinpoint the problem. Ta.

Destry · 2011-07-25 13:47:25

I get something curious, actually. I’ll send you an email cause it’s full of privvy data, but here’s what I’m seeing.

There’s an instance of one guy who does not have a Twitter ID. That should be an empty array. But, in fact, it’s showing up with a Twitter value that belongs with another account; so the twitter ID is showing in to two places even thought it’s not really like that in their account profiles.

I have a sneaking suspician it’s due to the Twitter field title I used.

Email coming.

Last edited by Destry (2011-07-25 13:48:37)

Bloke · 2011-07-25 14:23:30

Thanks Destry. Bug confirmed. New beta for anyone using the current version.

Bloke · 2011-07-27 23:41:47

I know I promised to release v0.40 in tandem with smd_user_manager but I dont have time right now to polish it so here’s yet another beta.

It now integrates more smoothly with smd_user_manager (there’s a beta of smd_prognostics v0.20 available as well to go with this) and I’ve begun work on an experimental feature for capturing data from the public side.

The following holds true about this version of the plugin:

Without smd_user_manager, only Publishers can edit a user’s Bio from the admin side
With smd_user_manager, individual users are given access to their bio data on the admin side
With smd_tabber and mem_form you can create your own custom interface for administering bio data on either the admin or public sides (although it’s not easy)

This latest beta introduces a new item type to <txp:smd_bio_data> (or replacement tag): item="widget". So this, slightly wordy code:

<txp:smd_bio_info show_empty="1">
   <br /><txp:smd_bio_data field="department" item="title" />
   : <txp:smd_bio_data field="department" item="widget" />
   <br /><txp:smd_bio_data field="jobtitle" item="title" />
   : <txp:smd_bio_data field="jobtitle" item="widget" />
</txp:smd_bio_info>

will render labels for the department and jobtitle fields, and alongside those items it will put input fields to allow them to be edited. The default value of the input fields will be set to whatever the current values are (I’m considering allowing multiple items with a wraptag/class/break to reduce typing bt haven’t got that far yet).

Why not just create your own fields with mem_form, I hear you cry? Well, you could, but you have to get everything just perfect. And you need to know the types of data in advance because they have to be hard coded in the form. Not with smd_bio. It always renders the appropriate type of input control to match the definition of the field on your Bio Config page. If your department is a select list, that’s what you’ll see when you display the widget. If you change it to a radio set, you get those instead.

In theory the output is HTML 5 compliant because it renders things like type="datetime", type="email" and so on. Older browsers will revert to boring type="text" but HTML 5 aware browsers can take advantage of the new input controls and render advanced input features. I’ve not enabled all the types yet (and it still outputs self-closed tags), but you can start to play around a bit.

What this means in practice is undecided. I’m not sure if you can integrate this with mem_form because I think mem_form/mem_simple_form need to be told what fields to expect. And they can only update one table unless you start hooking plugins into the callbacks: smd_bio uses (potentially) two tables which need to be updated simultaneously.

However, you may be able to utilise smd_query to fashion an INSERT based on the values submitted when you hit a Save button you create on the page. While this solution won’t have mem_form’s nonce stuff built in and all the lovely goodness that comes with a Manfre joint, it might be a poor man’s public-side bio editor.

I’ll be exploring ways to improve this over the coming months but I’d be interested to hear how you get on with it. Although the rest of the plugin is beta, the widget stuff is definitely alpha code as I only finished it ten minutes ago. Please report any findings here, as well as ways it could be improved or bugs (I know of one so far: see code) and I’ll see what I can do before v0.40 officially hits the streets.

Destry · 2011-07-28 07:09:05

Whoa! Stunned. Ecstatic!

I’ll report once I’ve had a chance to play a bit more.

brunodario · 2011-08-01 23:04:34

Can´t wait to the public side editing capabilities to be released. I tried a lot of ways to integrate a public side form to smd_bio, allowing users to edit their own data from the public site, with no success. So far so close now. The widget feature may be a north to take (when i first read your instructions i thought that the widget would actually generate a full form, not only the input fields…)
Anyway, has anyone managed to do something at least similar? Any advice (any at all) will be great.

wet · 2011-08-24 06:47:58

I found this patch quite useful:

@@ -564,7 +564,7 @@
 					$parent = $widget['val'];
 					$val = ($vals && isset($vals[$widget['name']])) ? $vals[$widget['name']] : '';
 					$where = ($parent) ? "category='".doSlash($parent)."'" : '1=1';
-					$tree = safe_rows('*', 'txp_image', $where);
+					$tree = safe_rows('*', 'txp_image', $where. ' ORDER BY name');
 					$selv = array();
 					foreach ($tree as $row) {
 						$selv[$row['id']] = $row['name'];

Bloke · 2011-08-24 11:40:49

wet wrote:

I found this patch quite useful:

Good call, thanks. Fixed and beta download updated.

milosevic · 2011-08-25 07:48:11

brunodario dijo:

Can´t wait to the public side editing capabilities to be released. I tried a lot of ways to integrate a public side form to smd_bio, allowing users to edit their own data from the public site, with no success. So far so close now. The widget feature may be a north to take (when i first read your instructions i thought that the widget would actually generate a full form, not only the input fields…)
Anyway, has anyone managed to do something at least similar? Any advice (any at all) will be great.

This is my “under construction” code for editing user data at de front and it runs ok with smd_bio v0.31 (not with v0.4) ….but now I will wait for v0.4 in order to simplify this terrible form. Lots of thanks Stef :-D

<h2>My personal data</h2>


<txp:mem_simple_form table="smd_bio" id_field="user_ref" id_insert="0">
<txp:mem_form_secret name="string_user_ref" value='<txp:mem_profile var="name" />'/>
<div class="campo"><txp:mem_form_text name="string_tipo" default=''<txp:mem_profile var="name" />' label="Tipo" required="1" break="" class="dato"/></div>
<div class="campo"><txp:mem_form_select name="string_pais" delimiter="," items="España,otros" values="Spain,Others" selected='<txp:smd_bio_info author=''<txp:mem_profile var="name" />'' items="pais" label="" />' label="País" break="" class="dato"/></div>
<div class="campo"><txp:mem_form_select name="string_provincia" delimiter="," items="No resido en España,A Coruña,Álava,Albacete,Alicante,Almería,Asturias,Ávila,Badajoz,Barcelona,Burgos,Cáceres,Cádiz,Cantabria,Castellón,Ceuta,Ciudad Real,Córdoba,Cuenca,Girona,Granada,Guadalajara,Guipuzcoa,Huelva,Huesca,Illes Balears,Jaén,La Rioja,Las Palmas,León,Lleida,Lugo,Madrid,Málaga,Melilla,Murcia,Navarra,Ourense,Palencia,Pontevedra,Salamanca,Santa Cruz de Tenerife,Segovia,Sevilla,Soria,Tarragona,Teruel,Toledo,Valencia,Valladolid,Bizkaia,Zamora,Zaragoza" values=",A CORUÑA,ALAVA,ALBACETE,ALICANTE,ALMERIA,ASTURIAS,AVILA,BADAJOZ,BARCELONA,BURGOS,CACERES,CADIZ,CANTABRIA,CASTELLON,CEUTA,CIUDAD REAL,CORDOBA,CUENCA,GIRONA,GRANADA,GUADALAJARA,GUIPUZCOA,HUELVA,HUESCA,ILLES BALEARS,JAEN,LA RIOJA,LAS PALMAS,LEON,LLEIDA,LUGO,MADRID,MALAGA,MELILLA,MURCIA,NAVARRA,OURENSE,PALENCIA,PONTEVEDRA,SALAMANCA,SANTA CRUZ DE TENERIFE,SEGOVIA,SEVILLA,SORIA,TARRAGONA,TERUEL,TOLEDO,VALENCIA,VALLADOLID,VIZCAYA,ZAMORA,ZARAGOZA" selected='<txp:smd_bio_info author=''<txp:mem_profile var="name" />'' items="provincia" label="" />' label="Provincia" break="" class="dato"/></div>
<div class="campo"><txp:mem_form_text name="string_localidad" default='<txp:smd_bio_info author=''<txp:mem_profile var="name" />'' items="localidad" label="" />' label="Localidad" break="" class="dato"/></div>
<div class="campo"><txp:mem_form_text name="string_direccion" default='<txp:smd_bio_info author=''<txp:mem_profile var="name" />'' items="direccion" label="" />' label="Dirección" break="" class="dato"/></div>
<div class="campo"><txp:mem_form_text name="string_cp" default='<txp:smd_bio_info author=''<txp:mem_profile var="name" />'' items="cp" label="" />' label="Código Postal" break="" class="dato"/></div>
<div class="campo"><txp:mem_form_text name="string_telefono" default='<txp:smd_bio_info author=''<txp:mem_profile var="name" />'' items="telefono" label="" />' label="Teléfono" break="" class="dato"/></div>
<br />
<txp:mem_form_submit />
</txp:mem_simple_form>

Last edited by milosevic (2011-08-28 07:08:29)

trenc · 2011-09-20 15:05:42

Hi stef,

I’m currently playing around with your smd_bio. I had some difficuties to set cyrillc and arabic chars in the meta fields. By an export of the database I found that smd_bio smd_bio_meta (and other smd_ tables) are created with CHARSET=latin1 and not utf8 as the other Textpattern tables.

That’ strange!

Is that intentional and I have missed something?

Bloke · 2011-09-20 15:11:06

trenc wrote:

By an export of the database I found that smd_bio smd_bio_meta (and other smd_ tables) are created with CHARSET=latin1 and not utf8 as the other Textpattern tables…. Is that intentional and I have missed something?

Uhhh, it’s not intentional. I just thought a CREATE TABLE would use the current charset in force for the DB. Guess not and I should be more careful in my SQL CREATE statements to define the charset expliticly.

Thanks for spotting it. I fixed smd_tags to switch it over to UTF-8 on upgrade so I can probably apply the same fix here before official release.

whaleen · 2011-12-07 20:38:36

Bloke wrote:

…before official release.

Any sort of pre-release, might-do-what-it-will-well-enough, maybe-will-explode, super-beta? :) I’m in a might-explode-phase of a project so I could help report explosions. I’m running v0.40 now but am referring to a public-side-editing-capable beta version as typing out some of the mem_form related stuff to do this can make your eyes say yikes.

Don’t feel obligated to reply in a hyphenated sort-of-way unless that is fun for you too.

Bloke · 2011-12-08 00:11:02

whaleen wrote:

Any sort of pre-release, might-do-what-it-will-well-enough, maybe-will-explode, super-beta?

You’re in luck. I was working on the mem_form side of things on Monday and had it poised for action, then got waylaid by stuffing more features into yab_shop.

I’ve just uploaded the bleeding edge beta and it’s a cracker. No docs yet but the general idea is this:

Step 1: install mem_form.
Step 2: Set up one of these containers:

<txp:mem_form type="smd_bio">
<txp:mem_self_user_edit>
<txp:mem_self_register>

Step 3: Inside the containers you can use regular mem_form tags if you want to update the txp_user / ign_user tables, and/or use <txp:smd_bio_data field="some_field" type="widget" /> to render input fields for your bio items. Remember to wrap a <txp:smd_bio_info> tag around them.

Step 4: Add a <txp:mem_submit /> to the form
Step 5: Take a look at your HTML form in the browser. Edit details, hit save and the data will be stuffed into the correct tables.

An example:

<txp:rvm_if_privileged>

<txp:mem_form type="smd_bio">
   <txp:smd_bio_info>
      <br /><txp:smd_bio_data field="RealName" item="title, widget" break=": " />
      <br /><txp:smd_bio_data field="phone" item="title, widget" break=": " />
      <br /><txp:smd_bio_data field="cell" item="title, widget" break=": " />
      <br /><txp:smd_bio_data field="biog" item="title, widget" break=": " />
   </txp:smd_bio_info>
   <txp:mem_submit />
</txp:mem_form>

<txp:else />
Go away
</txp:rvm_if_privileged>

A few caveats:

Remember that to successfully work on a bio you need an author name. Thus you must either:
1. be logged in and have $txp_user set
2. be editing an individual article and wrap <txp:smd_bio_articles> around the <txp:mem_form>
3. wrap <txp:smd_bio_author> around the <txp:mem_form>
There’s no concept of ‘required’ fields (yet)
Similarly the fields aren’t validated yet either

If you can live with those limitations then by all means take it for a spin and let me know how you get on.

Last edited by Bloke (2011-12-08 00:12:38)

Textpattern CMS

Textpattern CMS support forum

#151 2011-07-25 13:11:26

Re: smd_bio : store additional biographical info about your users

#152 2011-07-25 13:16:47

Re: smd_bio : store additional biographical info about your users

#153 2011-07-25 13:25:38

Re: smd_bio : store additional biographical info about your users

#154 2011-07-25 13:47:25

Re: smd_bio : store additional biographical info about your users

#155 2011-07-25 14:23:30

Re: smd_bio : store additional biographical info about your users

#156 2011-07-27 23:41:47

Re: smd_bio : store additional biographical info about your users

#157 2011-07-28 07:09:05

Re: smd_bio : store additional biographical info about your users

#158 2011-08-01 23:04:34

Re: smd_bio : store additional biographical info about your users

#159 2011-08-24 06:47:58

Re: smd_bio : store additional biographical info about your users

#160 2011-08-24 11:40:49

Re: smd_bio : store additional biographical info about your users

#161 2011-08-25 07:48:11

Re: smd_bio : store additional biographical info about your users

#162 2011-09-20 15:05:42

Re: smd_bio : store additional biographical info about your users

#163 2011-09-20 15:11:06

Re: smd_bio : store additional biographical info about your users

#164 2011-12-07 20:38:36

Re: smd_bio : store additional biographical info about your users

#165 2011-12-08 00:11:02

Re: smd_bio : store additional biographical info about your users

Board footer