Custom role names

[smcjones]

Hello,

First of all, thank you for creating this plugin.

I am interested in developing a slight addition: An option to set WordPress user roles that are named after member types. I was thinking something along the lines of civimember_student, for example, rather than civimember_1. Is this something already in the pipeline? I'm happy to fork and work on this.

Thanks,

Sean

[christianwach]

The problem I see with this is that Member Types can contain non alphanumeric characters. You could run them through sanitize_title() but that would require re-syncing this when anything changes, which could potentially break user caps on the WordPress side. It could also prevent the plugin from properly parsing caps which make use of the second parameter (which identifies the status of the membership) if the sanitized Member Type contains one or more underscores.

A workaround could be to use the Groups plugin (with which this plugin is compatible) to assign machine-readable caps to human-readable group names and then use that plugin for content restriction functionality.

I'm open to other suggestions, of course :-)

[smcjones]

I just tried out Groups per your recommendation. This is a great plugin and something I had not looked at using. Forget roles!

I think Groups does a good job at getting half the way there. I don't want to reinvent the wheel. What I am suggesting is that the role is an alphanumeric representation of a CiviCRM member type. So if a CiviCRM member type was "Member: Sustaining", the WordPress side could either automatically assign member_sustaining (stripping out whitespace), or, preferably, the WordPress settings allow changing the capability/role name manually. That way an automatic sync would not be necessary. It would be up to the admin to name (and rename) civimember_sustaining in the settings page.

A cross reference table in WordPress should help to make this easy to translate between CiviCRM and WordPress. I understand reluctance to create a new table but in this case I think it makes it a lot easier for your average run-of-the-mill WordPress user to understand what a capability is doing, and can effectively allow a user to be able to edit capabilities without being able to view CiviMember settings.

Does this make sense? I'm trying to think this through and appreciate the dialog!

[christianwach]

I think Groups does a good job at getting half the way there.

Help me out... where are you trying to get exactly?

I'm not sure I understand the problem with machine-readable capabilities, especially when there's an admin page which shows the associations between member types and capabilities - a page which you must have used to create the association rules in the first place. This is the "cross reference table" you mention, or am I missing something?

If you then assign these caps to groups with more descriptive names, you can effectively mask their existence and allow your "average run-of-the-mill WordPress user" to restrict content that way.