Hi Kate,


I'm seeing a bunch of different things that are causing the issues. I'll get them corrected tomorrow (Sunday). If you hadn't already seen it this User Guide article explains how Users & Roles work in Member Splash: https://membersplash.com/user-guide/user-roles-permissions/

I thought it would help clear things up to explain about the changes to how we're handling roles and permissions. This is going to run pretty long so you might want to pour a glass of wine first but at the end it should all make more sense!

WordPress by default creates a number of user roles -- Admin, Editor, Author, etc. -- that are designed with content management in mind. An Admin can peform administrative functions such as installing plugins or changing settings as well as all other capabilities such as creating new pages. An Editor can't touch the plugins or settings but can fully manage content. An Author can submit but not publish content and can only edit content they created. It's a cascading system where Admin can do anything and each role below it can do a bit less.

Within those roles there are a LOT of capabilities. For example, an Author has "edit own posts," which allows them to edit their content, but not "edit others posts." There are dozens of these capabilities out of the box in a completely fresh WordPress install.

Plugins may or may not create additional capabilities. Member Splash (which is written as a plugin to WordPress) adds a number of custom capabilities. However many plugins choose to just piggy back on the capabilities that already exist. The news ticker plugin author, for example, might decide that anyone with an Editor role should be able to create and manage new tickers since that's comparable to creating and managing other content like posts and pages. 

And here's what it starts to get messy. A role in WordPress is just an arbitrary name you assign to a grouping of capabilities. I might choose to give the Editor role on my site different capabililties than you choose to give it on yours. Or, in the case of Member Splash, the Editor role might not even exist b/c it isn't applicable. So anytime you are coding something and want to control who has access you look for a specific capability. The news ticker author is envisioning the Editor role being able to use it. The default Editor role has the "edit others posts" capability. So rather than checking for the role editor, they check for the capability edit others posts. Where this starts to get problematic is when a club decides they want their manager to be able to update their news ticker, but they don't want them to be able to edit the calendar or pages. All three of those things might be checking for the same capability.

The final challenge this system presents is that many things that require a specific capability inherently rely on another. As an example, suppose you wanted to create a user role called Trashman and the only thing this role could do was delete old posts, events and pages. So you give them the capabilities delete posts and delete others posts. When they log in they see ... nothing. Because the menu items for Posts, Pages and Events are only visible if you have the capability view posts.

Almost done!

Given all of the above and the nature of our clients -- we only serve community swim clubs so the roles and needs tend to be very similar -- we decided the best approach was to simply create some logical default roles and assign appropriate permissions. Our system expects there to be a single role per user and just like the default WordPress roles, for the capabilities to cascade. The staff user can do only a few things; the manager can do all of those plus some more; the board can do everything manager can do plus more.


When we add new features to Member Splash that involve permissions they are automatically assigned as appropriate to the default roles we create. Any other roles a club may have added we have no way of knowing about or updating automatically.

With board members rotating every couple of years and with the number of clubs we serve growing 50% + per year it wasn't working to have everyone have free reign over roles and capabilities. We were getting lots of tickets saying X or Y wasn't working and ultimately tracking it down to incorrectly configured roles. 

All that said, we've migrated most of our clubs into a network of sites and WordPress handles network users differently than standalone site users. Your site is still currently a stand alone site and I found a couple of things that aren't working as expected in terms of adding / editing users because of it. If you can bear with the current user accounts for tomorrow (Sunday) I'll push an update after you've closed that corrects those and you should be good to go. I learned the hard way last year about pushing code changes on opening weekend!