Make membership administration somewhat usable

[jonathanstegall]

This is related to:

• 49 ✅

• 4 ✅

• 55 ✅

• 19

Notes

Places in code that use our member levels in a hardcoded way:

• themes/minnpost-largo/inc/user-accounts.php (has an array of member roles)
• A few css files
• plugins/blocked-content-template/blocked-content-template.php (has an array of member levels with a number)
• MinnPost Salesforce plugin (hardcodes the actual member level roles as they are in Salesforce)

[jonathanstegall]

Possible ways of structuring this:

One big membership plugin

1. Make a folder level Membership plugin
2. Deal with settings
   • Store main settings - member levels, amounts, names, frequencies - in a separate database table because they would get used by so many different plugins and it'd be nice to not have to repeat the settings everywhere
3. Content it would have to handle by itself, eventually
   • Partner offers (front end and back end admin)
   • Fan club (front end and back end admin)
   • Other benefits people might redeem on site or that we might distribute on site)
   • Support pages (default, benefit structured, plus explanatory pages for partner offers/fan club stuff)
4. Things it would probably need to facilitate via hooks or whatever
   • Blocked content template, so it could show users what they can do to see the blocked content, based on their current logged in/membership status (i.e. they can log in if they aren't, if they are but they're not eligible they can join or upgrade support level)
   • Sending users to update their payment info/switch payment methods
   • Donation history/tax statements
   • Upcoming pledges and scheduled payments
   • donor recognition (this would probably be widgets, I imagine)
   • on-site notifications to users
   • Member drives/communication on site with users

A bunch of small plugins - maybe still under a big membership folder-level heading in admin

1. One for all financial stuff - main support pages, update payment method, see active donations, etc.
2. One for benefits - explaining them and redeeming them
3. still probably would need something with over arching settings like member levels, frequencies, amounts
4. One for member drives

[jonathanstegall]

Stuff that makes this all complicated:

• the stuff this needs to handle for our membership program is constantly evolving and expanding in scope, at least theoretically. It never really simplifies or appears to have a roadmap.
• In Drupal there's not yet a usable, unified front end for users or a unified back end for admins.
• Partner offers are complicated because a partner can have multiple offers, each of which can have multiple instances that can be claimed
• Fan club votes are tied to an API's list of Minnesota 501c3s.

[jonathanstegall]

Well, putting a plugin for this stuff in this repo: https://github.com/MinnPost/minnpost-membership

[jonathanstegall]

Pages this thing has to cover (at least):

1. https://www.minnpost.com/support/ ✅
2. https://www.minnpost.com/support/member-benefits ✅
3. https://www.minnpost.com/support/member-benefit-details ✅
4. https://www.minnpost.com/support/fan-club ✅
5. https://www.minnpost.com/support/partner-offers ✅

1 and 2 are related to #4.

Also:

The message that shows when a user tries to read a post their membership does not allow (which is the entirety of #49) ✅

[jonathanstegall]

Dealing with the first two line items above solves #4.

[jonathanstegall]

To finish this, it does seem like we'll also have to create content types for partners, partner offers, partner offer instances.

[jonathanstegall]

This is certainly related to #55 because we will need to allow this plugin to tell the popups whether users are eligible for fan club/partner offer benefits. That is not a usermeta field.

[jonathanstegall]

This is a useful piece on custom post types that are children of other custom post types. http://typecode.digital/wordpress-custom-post-types-and-parent-child-relationships/

[jonathanstegall]

Possible displays:

Before or after offers are claimable

• status message showing when the offers will be claimable on all offers (text as plugin setting)
• No button

During claimable times

No user action has happened

No instances are available

• No status message
• "All Claimed" as disabled button on all offers (text as plugin setting)

User is eligible

• No status message
• Button for Claim Now on all offers (text as plugin setting)

User is not eligible based on member status

• Status message showing user's and required membership info on all offers (text as plugin setting)
• No button

User is not eligible based on a previous claim

• Status message showing what the user last claimed and when on all offers (text as plugin setting, if possible)
• No button

User has claimed an offer in this period

• Status message showing what the user claimed on the single offer they claimed; no message on other offers (text as plugin setting, maybe?)
• Disabled button on the single offer they claimed that says "Already claimed" (text as plugin setting)

User has tried to claim

• Show a label on the button the user clicked that says "processing" while waiting for a response from the server. (text as plugin setting)
• Disable all the other claim buttons until the server responds.

No instances are available

• Add status message that no instances are available on the offer the user tried to claim; user should try to claim another offer. (text as plugin setting)
• "All Claimed" as disabled button on all offers without available claims (text as plugin setting)

Successful claim

• Show status message that shows what user received, tells them they will get an email about it with more details. (text as plugin setting)
• Send that same status as an email to user.
• Send email to admin if enabled.
• Keep all claim buttons as disabled; change the one the user claimed to "Successfully claimed" (text as plugin setting)

User is not eligible based on member status

• Status message showing user's membership info and what they need to have (text as plugin setting)
• No button

User is not eligible based on when they last claimed

• Status message showing what the user last claimed and when (text as plugin setting)
• No button