An idea for a Membership block ?!

[jbonlinea]

Hi there,

Roaming around here again, this PR #30 gave me an idea :)

Let me know what do you think ? I may do a big share of building it, with little help from you regarding the Civi side of it ;)

the context and the origin of the idea

the context will be the one describe in the pending PR, sumurised as the the need to differentiate :

• current members
• expired members
• past/cancel/excluded members

The approach I may have taken if I was in this situation :

• add a membership statute for past/cancel/excluded members, that would start 1 year after the end of membership (like Civi built-in expired statute) but with 1 year time span to fit the need of the PR
• use capabilities rather than roles
• conditionally display the membership form based on the capabilities

To conditionally display content, one may build a function that test if the user is logged in and has a give capabiity, and return true or false accordingly, then I see at least 3 options to use this fuction :

• use it in the page-tempalte : that's solid, but not super flexible
• use it - in block permission plugin : that's slightly flexible, but one need to know the name of the function, and if you have several membership types then you need to code again
• in your your own custom block -> this is where I have an idea

CiviWpMember-block

• The block would be a sort of "container" that display AAA if the condition is meet, and that if not.

• The block would have two parameters, one would be the civimember_ID and one would be civimember_ID_num.

  • A basic implementation would be to have a text field for each, that accept only one value in each.
  • Better, if it could accept an array of value.
  • Ideally, these bloc settings would be multi select with autocomplete field, the first one will retrieve active membership type and the second one the active membership statute type.

  I think I can make a plan to create the block with text fields, but would most certainly need you the have multi select with autocomplete field that get values from Civi !

Why such block

Well,

• I really like block permission plug-in, but we still to have to code the function that test if the condition is true or false
  • and you have to remember the name of your function to use it... that's ok, but when there is already the name of the capability which is much easier to "remember/rebuilt in our mind"
• members plug-in also has a block permission feature based on capabilities, but it only accept one capability and not an array of capability ; I've reported this a while ago, but n changed yet
• and why rely on a third party plug-in when it could be built in ? the idea is not to bloat Civi-cp-member-sync, but one crutial point of syncing membership is "selective" display right, so let's bundle this, we are in wp realm, with wp-users needs (editorially speaking)

What do you think ? I haven't though of it through the role sync option, as there is already many block that handle roles Do you think it is worth the effort and could find its place within civi-wp-member-sync ?

Regards

[christianwach]

@jbonlinea If I understand what you're after correctly, then it seems the Groups plugin already has the kind of functionality you're after:

The Groups Member block allows to restrict the visibility of its content to members of selected groups. The Groups Non-Member block hides its content from members of chosen groups. The blocks can be nested to provide multiple layers of access control to content.

This plugin is already compatible with Groups, so why not try that first?

[jbonlinea]

Hi @christianwach

groups : restrict content with shortcode --> issues

I gave try to the group plug-in a while ago, when it had no block yet, and we had to use shortcode to restrict content. This feature of group worked well to restrict basic content (paragraph, list, etc.) but messed up the ui when trying to restrict complex content (forms, civiforms, etc).

groups : restrict content wiht blocks --> works but, but incomplete feature

I've just re-tested the group plug-in which now do not break the ui. It's great, but

• do only a share of the job : it nails the member/non-member needs, as the capability civimember_ID or a selected role could, but not cover each membership statute as civimember_ID_num do
• require to use groups, so an external/extra plug-in. I have nothing against groups, but if the only user-grouping needs is based on membership, it may be better not to add an extra plug-in an rely on a "light-weight dedicated wp-Civi-member restrict content bloc" ? no ?

alternative solutions

• Again, if member restrict content block could handle more than one capability it would have gone this road.

• the same thing could probably be achieved by creating Wp-groups synced to Civi-groups, and creating Civi-Rules to add/remove member of this statute into a given Civi-Groups, but it would need a bunch of CiviRules (triggers for adding members, expiring members, changing statute from X to Y, then action to add/remove to/from groups, etc.). The downside is that it already require an relatively advanced knowledge of Civi, while the common wp editor just want to show/hide something base on membership statute and it may not have been planed beforehand so the guy who setup civi did orchestrated this crazy bunch of stuff needed.

• In the end, some month ago, my option was to use the restrict content block and my home made functions testing capabilities. but if you add a mebership type or a membership statute, extra coding is required

why this idea

I can do what I want, but not any of the site owners/editors/blablabla, event the more advanced one, could by their own, and it seems that this block could help. My priority is most of the time for the visitor experience, then the editor one, here it helps the editor to build a better visitor/member experience.

As you have replied in the PR #30, the actual feature of the plug-in answer most people's needs, and it will probably never cover 100% of everyone's needs. I think the hard work has been done to sync capabilities, but is not usable to it full potential by its own, while a "stupid" capability block would enable it. Then having multi-select rather than text field for the block settings is where we empower site editors.

I don't know if a block included in this plug-in is the right solution, but at the moment that all I have :)

situating this issue in a broader context

I don't like the profusion of block that do the same thing but slightly differently from vendor to vendor, but here the motive also come from the overall lack of intertwining between Civi and Wp when it comes to provide a sleek visitor/member browsing itinerary and providing a feedback of the membership/payment situation. I've recently done a detailed testing of Paid-Membership Pro, and well, this is what I'm basically asked for and I can only say that this is also what I would like to offer to membership-managers/editors/users in this respect.

A feature I really miss to is a civi-wp-membership statute. If someone register civiform to become a meber, he receive a mail, but there is no spot on the site where he could see his membership statute, I don't even speak of downloading his bill.

what I did is used civicrp-wp-ux to get some few field, it works okay, but is not translatable, create a form so the user can change he's details (email, postal address)(but it was with caldera and I'm not sure where we are going with that), etc. and I did it but a site editor couldn't

so a My membership block could also help a lot I think, well you get the broader idea

Cheers

In the civi-wp-block I think of, we could either define the membership type (or an array of membership types), or/and define membership statute (or an array of statute)

Now that I

Regards