smd_bio : store additional biographical info about your users

Destry · 2010-11-16 17:35:55

Note a couple of corrections above just discovered.

hablablow · 2011-01-16 22:01:26

Stef,

Is it simple technically to insert the smd_bio fields for a user registered as managing editor, or any profile that is not an admin, not under the admin tab, but under the write tab and so let him change his info from there… I’m using the bot_privs plugin to disallow access to this type of profile to the admin tab.

Thanks.

Last edited by hablablow (2011-01-16 23:11:21)

Bloke · 2011-01-16 22:53:01

hablablow wrote:

Is it simple technically to insert the smd_bio fields for a user registered as managing editor, or any profile that is not an admin, not under the admin tab, but under the write tab and so let him change his info from there

Sadly it’s not trivial. The plugin relies (quite heavily) on the Admin->Users tab because that’s where it hooks into the Create / Edit User steps. If you shift those away then you’d have to clone the existing Users tab code in the plugin.

Believe it or not a simpler alternative is to let your users configure their bio info from the public side using mem_form / mem_simple_form / mem_self_register / rvm_privileged. You can always write a simple admin-side stub (about 3 lines of code) that redirects from Write -> Bio to a page on the public side. With some clever CSS you could even make it look a bit like the admin side — or at least theme them similarly to make it appear more integrated.

hablablow · 2011-01-16 23:11:06

Thanks for your answer Stef and for the advices… I’ll look into this direction…

Last edited by hablablow (2011-01-16 23:12:05)

hablablow · 2011-01-17 11:35:08

Just a quick thought related to yesterday’s post: would it be a possible feature to display only certain bio items for certain users, under the user tab: John would only see certain fields, Jacy other fields etc… And certain fields would be visible to all… For each field added this could be an option in a dropdown: visible to John, Jacy or all…

Last edited by hablablow (2011-01-17 11:35:48)

Bloke · 2011-01-17 11:52:15

hablablow wrote:

Just a quick thought related to yesterday’s post: would it be a possible feature to display only certain bio items for certain users

That’s more feasible. And actually a pretty good idea.

But for making it a generic toolset I’m not quite sure how it’d be configured, especially given that you might have 1000+ users on a community site. It would make the page heavy to have a dropdown containing all those names and also quite difficult for an admin to decide who has what — it’d have to be a multi-select dropdown which are not great at the best of times with long lists.

Perhaps a better approach for the plugin might be to optionally tag certain fields with the priv level when the fields are defined. Then you could simply assign John and Jacy to different groups if you wanted them to see different things. That’s more manageable and with TXP 5’s planned improvements to user and rights management (under the hood, so that plugins can add entire user and priv management systems if they wish) it means there’s no limit to the number of groups you can create.

As a proof of concept / short term measure (until I can look into making it an official feature) we could try using jQuery to grab the current user ID and compare it against a static list of fields that you want to be visible for that user, just hiding the other fields. How’s your jQuery?!

hablablow · 2011-01-17 12:01:04

Thanks Stef.
Yes until nothing has been specified for a precise author and for a certain field, it is visible to anyone. The usual dropdown will fit the bill in the case we want to make something only visible to Jacy… If we want to switch 20 users at a time for a certain feature, you could use the abitlity to select multiple authors in a list, in the same fashion as the rss_unlimited _categories does.

Specifying a default user we land on when accessing the user tab would be very crisp as well.

A side question related to your plugin: Is there any reason why a Google maps url will always be cut at a certain length even a higher limit has been specified for a text field ?
For example this url:
http://maps.google.fr/maps?f=q&source=s_q&hl=fr&geocode=&q=le+grand+palais+paris&sll=46.75984,1.738281&sspn=14.077708,27.663574&ie=UTF8&hq=le+grand+palais&hnear=Paris,+Ile-de-France&ll=48.865198,2.313314&spn=0.0033,0.006754&z=18&iwloc=B

Will never make it through and will always be cut at:
http://maps.google.fr/maps?f=q&source=s_q&hl=fr&geocode=&q=le+gr

Is that for security reasons ?

Last edited by hablablow (2011-01-17 12:30:43)

maverick · 2011-01-17 14:41:23

Bloke wrote:

a simpler alternative is to let your users configure their bio info from the public side using mem_form / mem_simple_form / mem_self_register / rvm_privileged. You can always write a simple admin-side stub (about 3 lines of code) that redirects from Write -> Bio to a page on the public side. With some clever CSS you could even make it look a bit like the admin side — or at least theme them similarly to make it appear more integrated.

Just inspired to brainstorm by this . . .

A while back I vaguely recall a plugin that allowed the use of txp tags on the admin side (in a dashboard type page for example.)

With the new “Home” tab functionality, could there be a way to use smd_bio tags, and mem_form tags to create the desired functionality, and be able to skip the mem_self register, rvm_priviligeged, the redirect, and css look-alike step?

Bloke · 2011-01-17 15:11:45

hablablow wrote:

If we want to switch 20 users at a time for a certain feature, you could use the abitlity to select multiple authors in a list, in the same fashion as the rss_unlimited _categories does.

A multi-select list? Too unwieldy for 1000 users. I don’t want to click a few hundred times each time I want to create a user-specific field — imagine if you wanted a field accessible by a few users beginning with ‘a’, some beginning with ‘b’, 25 from the ‘c’ section and so on. Scroll-click-scroll-click-click-click-click-scroll-click…

Using groups (privs) is more elegant, easier to manage and more akin to how people set up user accounts. I’ll look into this when I fix the plugin to address…

Is there any reason why a Google maps url will always be cut at a certain length

… this. It’s a stupid limit imposed in the plugin. Find function smd_bio_meta_add() in the plugin and look for the TODO items. Notice:

if ($type == 'textarea') {
	$asize = '4096'; //TODO: Find a way to user specify this
	$coltype = 'text';
} else {
	$asize = '64'; //TODO: Find a way to user specify this
	$coltype = 'varchar';
}

The ‘64’ is the problem. Try increasing that value in the plugin (I think 255 is the maximum a varchar can hold: not sure on that as it might be dependent on your version of MySQL), then deleting your field and recreating it. If you’ve already started using your field, run something like this SQL to change it:

ALTER TABLE MODIFY google_map VARCHAR(255);

(or whatever you named your field).

Sorry about that. I’d forgotten that stupid limit was in there. I must fix that.

maverick

In theory yes. I think mem_admin_parse does it but it’s a function not a tag so you’d need some PHP.

Last edited by Bloke (2011-01-17 15:13:30)

hablablow · 2011-01-17 15:20:16

Crispy stuff, thanks again Stef !

merz1 · 2011-01-17 15:35:08

Is there any reason why a Google maps url will always be cut at a certain length

Workaround: Use a URL shortening service of your choice for long URLs.

hablablow · 2011-01-17 15:40:27

Switching value to 255 as you said Stef solved the problem.

Is there any chance we can by default land on a specific user’s page when browsing to this tab ?

Markus, of course but the commmon internet user doesn’t know what a url shortening service is and it involves on step +.

Last edited by hablablow (2011-01-17 15:43:21)

Textpattern CMS

Textpattern CMS support forum

#73 2010-11-16 17:35:55

Re: smd_bio : store additional biographical info about your users

#74 2011-01-16 22:01:26

Re: smd_bio : store additional biographical info about your users

#75 2011-01-16 22:53:01

Re: smd_bio : store additional biographical info about your users

#76 2011-01-16 23:11:06

Re: smd_bio : store additional biographical info about your users

#77 2011-01-17 11:35:08

Re: smd_bio : store additional biographical info about your users

#78 2011-01-17 11:52:15

Re: smd_bio : store additional biographical info about your users

#79 2011-01-17 12:01:04

Re: smd_bio : store additional biographical info about your users

#80 2011-01-17 14:41:23

Re: smd_bio : store additional biographical info about your users

#81 2011-01-17 15:11:45

Re: smd_bio : store additional biographical info about your users

#82 2011-01-17 15:20:16

Re: smd_bio : store additional biographical info about your users

#83 2011-01-17 15:35:08

Re: smd_bio : store additional biographical info about your users

#84 2011-01-17 15:40:27

Re: smd_bio : store additional biographical info about your users

Board footer