smd_bio : store additional biographical info about your users

Bloke · 2014-10-23 14:23:52

v0.41 released with the fix for the bug as reported by aslsw66 above.

Development shifted to github. You may also download the release .txt files there if you prefer, from the Releases page.

Bloke · 2014-10-23 14:27:37

aslsw66 wrote #285086:

it’s the plugins area which trips over into 403 errors all the time

Yeah, a royal pain. My best guess is that when you save a plugin, the host’s filters are set such that the massive injection of code onto a server for which they assume 90% of users would normally be posting text causes their filters to panic because they assume malicious intent. *sigh*

aslsw66 · 2014-12-09 13:01:36

Still playing around with this plugin…

I’m now trying to use the “widget” feature to allow users to update their details from the front-end, as a replacement for my customised forms using mem_form and smd_query. As I’m using Bootstrap as the basis of the design, I really want to be able to pass some classes (and ids as well) through to the form that the widget feature outputs, but I find the that the class on the txp:smd_bio_data tag isn’t passed through the form field when using item=widget. Instead, the plugin generates it’s own class name.

I’ve dug into the plugin code, but I stand in awe of its complexity. I had a go at modifying it, but I can’t really see where the “widget” creates a form field with the class attached – if I could see that, then I would be on my way. Oh, and I note the comment suggesting that this is on a ‘to-do’ list but still, it would be nice to be able to make it work.

[EDIT]

I’ve figured out most of these issues by playing around with classes. What confused me was that the breakclass attribute on <txp:smd_bio_info> gets passed to the child <txp:smd_bio_data> fields.

However, the only exception is for any widget which includes a select input type. I traced this down to the fact that the selectInput function in TXP doesn’t support classes as an attribute. To get around this, I hacked the smd_bio plugin to add the class to the id attribute (properly spaced out).

It works, but modifying plugins isn’t my preferred approach.

Last edited by aslsw66 (2014-12-16 16:41:51)

Destry · 2015-08-08 00:39:54

Bloke wrote #250008:

[I’m intending to enhance smd_bio again in the near future to allow you to easily build input forms on the public side for capturing extended bio data at registration time, so that’ll require integration with mem_self_reg / mem_form].

I’m pulling that quote from the cbe_frontauth thread, something you posted a while ago. I’m just wondering if what is said there about capturing front-side user data at registration time is possible now?

More specifically, what does one need these days to have a setup that allows:

front-side registration and log in,
auto-assigning the roles/privs of those users, and
enabling those users to post specific article data via a predefined form (after front-side reg/log in), so they don’t have to see the scary admin-side.

As much as I’d love a single plugin to manage all of this, I realize I’ll probably need several. But beyond smd_user_manager, smd_bio, mem_self_register, and maybe mem_form, I’m not sure what the exact ingredients for this cocktail is. And where does cbe_frontauth come in, and ign_password_protect? Are they relevant in this case?

A nice overview (top-level) article about extending Txp user management for various multi-user scenarios would be a very useful and popular .com blog article (or mag article, if we can squeeze another issue out of that).

jakob · 2015-08-10 10:20:49

Destry wrote #294021:

More specifically, what does one need these days to have a setup that allows:

front-side registration and log in,

auto-assigning the roles/privs of those users, and

enabling those users to post specific article data via a predefined form (after front-side reg/log in), so they don’t have to see the scary admin-side.

I’m just working on converting a very old site with a custom multi-user setup, so I can provide some answers. I’ve not done it all yet but perhaps this is of some help:

You’ll need mem_self_register for front-side registration. It is now able to interact with smd_bio / smd_user_manager together with mem_form to allow you to acquire further information. See Example 6 in the smd_bio help.

In the mem_self_register install wizard (you need to run it from the links in the help docs page), you can set the default new_user_priv level. After you’ve run that install wizard, you can then change those settings under Admin > Prefs > Advanced.

Get Manfre’s most recent versions from his bitbucket repo. They’re not pre-compiled so you’ll need to install them with ied_plugin_composer.

To do the frontside editing, you need mem_form + mem_simple_form (I think there’s also mem_public_article but I can’t remember if that still works). You’ll need to build you own equivalents of the “Content > Articles” and the “Content > Write” and “Content > Edit” pages (essentially identical, but for the edit page you need to populate the fields and make sure it edits the existing article rather than creating a new article). I’ve used smd_query for that in the past. IIRC, I think you also need to build in safety checks, for example if you want to prevent a user from editing another article id by editing the url (i.e. check that the logged in user is also the author of the article / the article is in the editable section, else reject them).

If you need other things like image and file upload, you’ll need to create the corresponding forms there too.

To prevent anyone from accessing these frontside editing pages, you need to place them behind a frontside login and that’s …

Where … cbe_frontauth come in, and ign_password_protect?

They both do similar things: provide a way for users to login so that you can create a sign-in accessible area on the front side. ign_password_protect can use its own separate user database and mem_self_register can optionally use that too. I’m not sure if (= I don’t think) smd_bio can use ign_users user table, though.

jakob · 2015-08-10 10:32:53

Stef,

Is there a way to restrict the editing of smd_bio fields to certain priv levels. I’d like to set certain fields as the admin that the individual users are unable to edit themselves. If not, maybe that could be added to the “more” twisty section of the “Extensions > Bio config” pane”.

Another thing I’d like to do is group the fields in fieldsets (or divs if more practical than fieldsets to realise), so that I can style a more structured user edit pane (e.g. in two-columns or tab-panes). A sort order for the fieldset/div group would be useful too. Would that be feasible?

One other thing: rather than doing my own front-side edit panels (as described above), I’m looking at providing users with a certain privs level access to a dumbed-down version of the txp admin area. For that they should only be able to edit their own files, their own images and their own articles. In the previous (very old) version of the site, I edited the core files. I guess a lot of that can now be done with pluggable_ui? Would it be possible to make the image select in smd_bio also pluggable, to restrict the list of images to only those belonging to that user. Alternatively, perhaps as a setting in the “Extensions > Bio config”?

Destry · 2015-08-18 10:09:38

jakob wrote #294043:

… I can provide some answers. I’ve not done it all yet but perhaps this is of some help:

Thanks very much, Jakob. This will help me get started for sure. I’m just back from vacation, so sorry about the delay in response.

jakob · 2015-08-23 08:11:43

Hi Stef,

I’m having a problem with textiling output from smd_bio_data when it comes from a multiline text field. After much investigation, it seems smd_bio_data (or the doWrap function) outputs carriage returns with a   which then prevents textile from properly recognising the paragraph breaks. I’ve got around it by first removing the   from the tag’s output and then textiling:

<txp:smd_wrap transform="replace|string|<br />|,textile"><txp:smd_bio_data field="about" /></txp:smd_wrap>

Is this something that could be suppressed for multiline output? Or alternatively with an attribute for smd_bio_data if that presents other problems?

Bloke · 2015-08-23 09:07:53

Sorry for neglecting this thread recently. Here goes…

Destry wrote #294021:

front-side registration and log in

As jakob says, cbe_frontauth combined with mem_self_register is the traditional way to do this. There is, however, another kid on the block that I sometimes employ, mck_login which does both in one plugin. Jukka has an updated version available that fixes a truckload of security issues and extends it into a power house of considerable force, so I’d recommend giving that version a serious look.

auto-assigning the roles/privs of those users, and

With smd_user_manager installed you can add a new user Group and use mem_self_register’s prefs to set that group ID as the one to assign for sign-ups. Not sure how that would work under mck_login, but it has a bunch of callbacks available so if it doesn’t do it out of the box it may be possible for us to write a few lines of code to do it.

enabling those users to post specific article data via a predefined form

You can build this yourself on the front-side using the mem_* suite as jakob suggests. An alternative is to employ smd_tabber alongside smd_user_manager, because that gives you control over a pseudo-admin-side. For example, you could make a new user role that hides every bit of contemporary admin-side functionality — no tabs, menu, nothing — and simply add some tabs under a new top-level menu. In there you can write (in Pages/Forms/Stylesheets) your own cut-down article management system. You can use the mem_* suite here or etc_query. If you skin the back end in a similar way to the front side, your users may never realise they’re on the admin side: I’ve seen it done (ask jakob — he’s a master at it!)

You do need to be mindful of security concerns, however, so bear in mind that you shouldn’t trust anything passed in from the forms. Sanitize, sanitize, sanitize.

And where does cbe_frontauth come in, and ign_password_protect? Are they relevant in this case?

I don’t advocate ign_password_protect any more. It served its time, there are better alternatives now.

jakob wrote #294045:

Is there a way to restrict the editing of smd_bio fields to certain priv levels.

Not at present, sadly. The privs aren’t granular enough to do that.

Another thing I’d like to do is group the fields

That should be doable with some code changes. Might just require a new column called, I dunno, family or something. Exposing that would allow you to define your own names for each item. Not sure how that would work on the Admin->Users panel though. Hmmm. But on the front side, if the sort order was altered to family, position when rendering the bio data it might be possible to extend smd_bio_data to somehow offer wraptag / class for the family groups too. Not sure, haven’t thought it through. Sounds a bit messy. Any ideas, please throw them this way and I’ll see what I can do.

only be able to edit their own files, their own images and their own articles.

Yes, this can now be done better with callback hooks — at least on the current admin side. A few lines of code similar to mrd_for_your_eyes_only will do the trick.

make the image select in smd_bio also pluggable, to restrict the list of images to only those belonging to that user.

Absolutely, I can add that for you no problem.

smd_bio_data (or the doWrap function) outputs carriage returns with a  

Ah yes. Your workaround is perfectly valid, but it’d be nice to not have to worry about it. Not sure exactly what can be done, as some people might well want the line breaks to prevail. I wonder if there’s a way to add an option to strip them or something. Hmmmm. Ideas welcome.

jakob · 2015-08-23 21:07:41

Bloke wrote #294316:

> Is there a way to restrict the editing of smd_bio fields to certain priv levels.

Not at present, sadly. The privs aren’t granular enough to do that.

Is there really no way at all? A simple if group of $txpuser is not “1” (publisher) don’t display this field (or if it has to be included, show as hidden field) would suffice. The use case is: I’m assigning a section to each user on which their profile is shown and in which their articles are shown. I set this once on signup, and thereafter they should not be able to change it.

> Another thing I’d like to do is group the fields

That should be doable with some code changes … Not sure how that would work on the Admin->Users panel though. Hmmm. But on the front side, if the sort order was altered to family, position when rendering the bio data it might be possible to extend smd_bio_data to somehow offer wraptag / class for the family groups too. Not sure, haven’t thought it through. Sounds a bit messy. Any ideas, please throw them this way and I’ll see what I can do.

I was hoping to simply to style the Admin->Users panel rather than create a new smd_tabber tab. Example: Group all contact details in one fieldset, all user login details in a fieldset, and all descriptive “about this institute” details in a fieldset. Then I’d style them to appear in separate blocks as part of the admin theme, or perhaps make each fieldset a tab using some javascript.

> make the image select in smd_bio also pluggable

Absolutely, I can add that for you no problem.

Brilliant. That would be perfect.

> smd_bio_data (or the doWrap function) outputs carriage returns with a  

Ah yes. Your workaround is perfectly valid, but it’d be nice to not have to worry about it. Not sure exactly what can be done, as some people might well want the line breaks to prevail. I wonder if there’s a way to add an option to strip them or something. Hmmmm. Ideas welcome.

If the only relevant use situation for stripping   is for textiling the output, it might be simpler to skip the stripping attribute and offer an attribute textile="1" or transform="textile" for smd_bio_data itself.

Destry · 2015-12-10 16:16:48

Stef,

Once upon a time in TXP Mag land, we used gbp_permanent_links in relation to smd_bio to manage smd_bio-powered bio URLs. I’m not sure why gbp_pl was needed, but…

I modeled the CSF site’s bio pages the same way. Recently we’ve been doing some “cleaning up” of needless forms and plugins, and, not remembering what gbp_pl was for, it didn’t seem needed — thus got axed. The bio pages promptly started throwing 404s, but not noticed until a couple+ weeks after. ;)

So, we can recoup the old plugin data, but I’m wondering if smd_bio will be updated to skirt having to rely on gbp_pl, which is seemingly abort-ware now. Any counsel?

Could there be something from gbp_pl that you throw into a next edition of smd_bio that could make that work without the extra plugin?

Apparently we can fake this with dud articles too, to use their resulting URLs only, but the idea of having dud articles in the Articles list for that reason only doesn’t appeal to me. Clean freak here.

Bloke · 2015-12-10 18:53:55

Destry wrote #297048:

I’m not sure why gbp_pl was needed

Because we didn’t have “real” user accounts for everyone. If everyone has a physical login to Txp, you can use the usual example.org/author/Destry+Wion links, and bio pages work out of the box. It’s only because the endpoint was fake that we had to tell Txp not to throw a 404 via gbp_pl.

Could there be something from gbp_pl that you throw into a next edition of smd_bio that could make that work without the extra plugin?

Offhand, I don’t know, but suspect it’s a lot of work. I’d rather put the energy into revamping Txp’s core URL behaviour than retrofitting one plugin to do it.

Textpattern CMS

Textpattern CMS support forum

#253 2014-10-23 14:23:52

Re: smd_bio : store additional biographical info about your users

#254 2014-10-23 14:27:37

Re: smd_bio : store additional biographical info about your users

aslsw66 wrote #285086:

#255 2014-12-09 13:01:36

Re: smd_bio : store additional biographical info about your users

#256 2015-08-08 00:39:54

Re: smd_bio : store additional biographical info about your users

Bloke wrote #250008:

#257 2015-08-10 10:20:49

Re: smd_bio : store additional biographical info about your users

Destry wrote #294021:

#258 2015-08-10 10:32:53

Re: smd_bio : store additional biographical info about your users

#259 2015-08-18 10:09:38

Re: smd_bio : store additional biographical info about your users

jakob wrote #294043:

#260 2015-08-23 08:11:43

Re: smd_bio : store additional biographical info about your users

#261 2015-08-23 09:07:53

Re: smd_bio : store additional biographical info about your users

Destry wrote #294021:

jakob wrote #294045:

#262 2015-08-23 21:07:41

Re: smd_bio : store additional biographical info about your users

Bloke wrote #294316:

#263 2015-12-10 16:16:48

Re: smd_bio : store additional biographical info about your users

#264 2015-12-10 18:53:55

Re: smd_bio : store additional biographical info about your users

Destry wrote #297048:

Board footer