smd_bio : store additional biographical info about your users

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.

Destry · 2015-12-10 22:24:13

Bloke wrote #297053:

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.

Excellent.

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.

Indeed. And it seems no need on my account anyway as it’s all real user accounts in CSF.

Thanks.

Destry · 2015-12-11 15:17:43

Well, I thought I knew what you were talking about, and figured you meant domain/people/destry-wion, which is what the URL’s are supposed to be, but maybe I misunderstood.

If you go here, you see various people. If you click on one of their profiles, you get a 404. That has just started happening after I removed gbp_pl.

As I look at the form (now flattened out via rah_flat), I’m not exactly sure 1) where the URL paths you speak of should go, and 2) whether or not smd_if is needed now that gbp_pl has been removed from the equation, but smd_if currently adds an if/else conditional in the form, so the who thing might need a little refactoring to simplify, but I don’t know for sure. I also don’t quite understand those URL path structures you indicate, that’s new to me.

Here’s the form code, can you (or anyone) suggest where I might make some changes?

<txp:smd_if field="pretext:permlink_regex_member, pretext:permlink_regex_member" operator="defined, not" value=",rss">

<txp:hide>** INDIVIDUAL CONTRIBUTOR **</txp:hide>

<txp:smd_bio_author author="SMD_PRIVS:1:2:3:4:5:6">

<txp:hide>
Accounts w/ no rights (SMD_PRIVS:0) not included, so don't output.</txp:hide>

    <txp:smd_bio_info>
        <txp:smd_if_bio field="url_title" value="{smd_if_permlink_regex_member}" case_sensitive="0">

<article class="principle profile grid" itemscope itemtype="http://schema.org/Person">
  <h1 itemprop="name">{smd_bio_RealName}</h1>
  <section itemprop="description" class="c10 m">
    <txp:smd_wrap transform="textile">
      <txp:smd_bio_data fields="bio" />
    </txp:smd_wrap>
    <txp:smd_wrap labeltag="h2" label='CSF Articles'>
      <txp:smd_bio_articles wraptag="ul" break="li" author="{smd_bio_name}" section="articles"><txp:permlink><txp:title /></txp:permlink></txp:smd_bio_articles>
    </txp:smd_wrap>
  </section>

<figure class="biofigure c6">
  <txp:smd_if_bio fields="author_photo">
    <txp:image width="0" height="0" id='<txp:smd_bio_data fields="author_photo" />' />
  <txp:else />
  <txp:image name="nohead.png" width="0" height="0" />
  </txp:smd_if_bio>
<figcaption class="headcap">
  <txp:smd_if_bio fields="caption">
    <txp:smd_bio_data fields="caption" />
  </txp:smd_if_bio>
  <txp:smd_wrap_all wraptag="ul" class="biocaptionlinks">
    <txp:smd_wrap wraptag="li" transform="link|Website">
      <txp:smd_bio_data fields="website" />
    </txp:smd_wrap>
    <txp:smd_if_bio fields="twitter">
        <txp:smd_if fields="{smd_bio_twitter}" operator="begins" value="http">
            <txp:smd_wrap wraptag="li"><a href="<txp:smd_bio_data fields="twitter" />">Twitter</a></txp:smd_wrap>
        <txp:else />
          <txp:smd_wrap wraptag="li" transform="replace||@"><a href="http://twitter.com/<txp:smd_bio_data fields="twitter" />">Twitter</a></txp:smd_wrap>
        </txp:smd_if>
    </txp:smd_if_bio>
    <txp:smd_wrap wraptag="li" transform="link|Google+">
      <txp:smd_bio_data fields="gplus" />
    </txp:smd_wrap>
  </txp:smd_wrap_all>
</figcaption>
</figure>
</article>

<txp:variable name="bio_found" value="1" />
      </txp:smd_if_bio>
    </txp:smd_bio_info>
</txp:smd_bio_author>

  <txp:hide> ** CHECK IF A PERSON MATCHED ** </txp:hide>
  <txp:if_variable name="bio_found" value="1">
  <txp:else />
    <h1>Seems to be a problem</h1>
    <p>Can't seem to pull up that profile. Let us know about it.</p>
  </txp:if_variable>

<txp:else />

<txp:hide>  THIS IS WHAT YOU SEE IF YOU HIT THE /people LANDING PAGE FIRST </txp:hide>

<h1>People power</h1>

<p>Are you missing here? <a href="<txp:site_url />docs/article-contributions">Get yourself added!</a></p>

<txp:smd_bio_author author="SMD_PRIVS:1:2:3:4:5:6" sort="RealName asc" wraptag="ul" class="grid people">
	<txp:smd_bio_info fields="url_title, RealName, author_photo">
	<li class="c33 m">
		<a href="<txp:site_url /><txp:section name="people" />/{smd_bio_url_title}">
			<span class="people-photo"><img src="/images/{smd_bio_author_photo}.jpg" alt="{smd_bio_RealName}" /></span>
			<span class="people-name">{smd_bio_RealName}</span>
		</a>
	</li>
	</txp:smd_bio_info>
</txp:smd_bio_author>

</txp:smd_if>

Destry · 2015-12-11 15:23:45

Oh, btw, these files are all on Github too, which might be easier for you.

Bloke · 2015-12-11 21:22:46

Destry wrote #297059:

Well, I thought I knew what you were talking about, and figured you meant domain/people/destry-wion, which is what the URL’s are supposed to be, but maybe I misunderstood.

If you’re doing that, you need a real, physical Section called people and articles for each person, otherwise you’ll get 404s. But if you change <txp:section name="people" /> to read just author and then pass in the real name of the users to build up the URL, then it’ll work. Txp understands the /author/Real+Name URL pattern by default as a special pattern. So this should work:

<a href="<txp:site_url />author/{smd_bio_realname}"> ... </a>

btw, the smd_if at the top is just to extract a field from gbp_pl, so without the plugin you won’t need the smd_if call.

But the above uses an ‘author’ URL pattern. If you don’t like that and prefer the ‘people’ pattern, there is another way to approach this using some trickery.

Since you know that any author link is going to result in a 404, you can actually trap that situation and exploit it. To do so, you’ll first need to change your author links (at the bottom of people.misc.txp) to be their real login names instead of the smd_bio_url_title:

<a href="<txp:site_url /><txp:section name="people" />/<txp:smd_bio_data field="name" />"> ... </a>

OK, so that will render your anchors as domain/people/login. What you do next is create a new Txp Page called error_404. This will be rendered whenever anyone hits a non-existent site link. In that Page template you do some smd_if jiggery pokery to detect if the URL contains /people and act accordingly:

<txp:smd_if field="svrvar:REQUEST_URI" operator="contains" value="/people/">
   <txp:smd_bio_author author='<txp:smd_wrap_all transform="split|/||last">{smd_if_REQUEST_URI}</txp:smd_wrap_all>'>
      <txp:smd_bio_info
        fields="name, RealName, phone, website" />
   </txp:smd_bio_author>
<txp:else />
   I'm a regular 404: write error template code here. 
</txp:smd_if>

So all that does is check if the URL is a bio link (/people/), uses smd_wrap to split the URL at slash, takes the last part (the login name) and plugs it into the author attribute of the <txp:smd_bio_author> tag. Once that’s done, in the smd_bio_author container you’re free to output whatever you like: I’ve just used <txp:smd_bio_info> in the example to pull out some random bio fields. What you probably want to do is move most of the bio field display stuff out of the top of your current people.txp.misc Form and stick it there. Decorate the error_404 template with whatever other markup you like (doctype, head, body, divs, whatever).

The top of your people.misc.txp Form is pretty much redundant at this point as it’ll never be called so that Form can start with:

<h1>People power</h1>

as it’ll only ever be hit to render the list of mugshots.

I’ve tested this approach on my server and it works fine, so give it a go, but if you get hopelessly lost due to my pants instructions then holler again letting me know how far you’ve got and we’ll go from there.

EDIT: one thing to be aware of is that Txp will probably still throw a 404 header so I don’t know what this does to indexing/spidering algorithms in search engines.

michaelkpate · 2015-12-12 03:50:44

Bloke wrote #297063:

If you’re doing that, you need a real, physical Section called people and articles for each person, otherwise you’ll get 404s. But if you change <txp:section name="people" /> to read just author and then pass in the real name of the users to build up the URL, then it’ll work. Txp understands the /author/Real+Name URL pattern by default as a special pattern. So this should work:

There actually is another way. I did a bit of hacking on my mkp_url_parameters plugin and came up with:

if (class_exists('Textpattern_Tag_Registry')) {
Txp::get('Textpattern_Tag_Registry')
->register('mkp_url_person')
;
}


function mkp_url_person()
{

	global $variable;

	$parts = explode('/', preg_replace("|^https?://[^/]+|i", "", serverSet('REQUEST_URI')), 2);

	if ('person' == $parts[1]) {

	// person will be true and the variable will be set to the biographical url
		$variable['person'] = $parts[2];

	} else {

	// person will be false and the variable will be set to null
		$variable['person'] = null;

	} 

	return null;
}

You then insert something like this at the top of your error_default page (or error_404 if you have one):

<txp:mkp_url_person />

<txp:if_variable name="person">

{custom bio code}

<txp:else />

{regular error page code}

</txp:if_variable>

The 404 error still happens but the person browsing the site gets the content they were looking for. I had been thinking about a way to do AMP in Textpattern and that gave me the idea.

Destry · 2015-12-12 09:38:06

Bloke wrote #297063:

But if you change <txp:section name="people" /> to read just author and then pass in the real name of the users to build up the URL, then it’ll work.

Okay.

Just a thought… what if we did it like that and then used mod_rewrite in .htaccess to mask the actual URLs to the original /people pattern?

I’ve no clue what the rewrite rules might be. Any experts in that area?

Barring that, I guess we’d just have to go with /author URLs and then do 301 redirects, yeah? That would be fine with me too.

Textpattern CMS support forum

#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:

#265 2015-12-10 22:24:13

Re: smd_bio : store additional biographical info about your users

Bloke wrote #297053:

#266 2015-12-11 15:17:43

Re: smd_bio : store additional biographical info about your users

#267 2015-12-11 15:23:45

Re: smd_bio : store additional biographical info about your users

#268 2015-12-11 21:22:46

Re: smd_bio : store additional biographical info about your users

Destry wrote #297059:

#269 2015-12-12 03:50:44

Re: smd_bio : store additional biographical info about your users

Bloke wrote #297063:

#270 2015-12-12 09:38:06

Re: smd_bio : store additional biographical info about your users

Bloke wrote #297063:

Board footer