What?

Create a minimum viable product of the notification plugin.

Why?

There is still a lot to learn, but we need a minimally functional system to explore the possiblities.

How?

Combines PRs:

• feature(mvp): Stage 4 add item and collection schemas to rest api #178
• feature(mvp): Stage 4 - add activator and uninstaller #298
• feature: add basic Logger class #204
• feature: add seed channels command #214
• feature(mvp): Stage 3 - add channel registry #291
• ci: remove php 7.2 add 8.1 and 8.2 #255
• build: update composer packages #256

Necessary functionality for MVP*

• Activate
• Uninstall
• Classes
  • Channel
  • Channel_Registry
  • Message
  • Message_Factory
  • Notice
  • Notice_Factory
  • Subscription
  • Subscription_Factory
• Database
  • Messages table
  • Queue table
  • Subscriptions table
  • Message_Repository
  • Notice_Repository (the queue table)
  • Subscription_Repository
• REST API
  • Notification_Controller wp-notifications/v1/notifications
    • GET /notifications/
    • GET /notifications/{id}
    • POST /notifications/{id}
    • PUT /notifications /{id}
    • DELETE /notifications /{id}
  • Subscription_Controller wp-notifications/v1/subscriptions
    • GET /subscriptions/
    • GET /subscriptions/{id}
    • POST /subscriptions/{id}
    • PUT /subscriptions /{id}
    • DELETE /subscriptions /{id}
• CLI Command
  • Seed users
  • Seed subscriptions
  • Seed notification messages
  • List registered channels
  • List user's notifications
  • List user's subscriptions

• Only a rough outline right now, and heavily concentrated on the backend.

This is looking phenomenal already, thanks for the hard work here!

@Sephsekla thanks, it feels like its coming a long well. Right now I'm going for simple, a lot will need adjusting to make the rest api function the way I would expect. Right now I don't have the right features in the models/factories/repositories for supporting _embed or _fields parameters in the rest api. But I am saving optimization and streamlining for later. For right now, we really just need to basic CRUD actions to get off the ground.

@johnhooks when you have a sec, do you mind having a look at these merge conflicts? I'd like to try and get this rolling again by splitting out some of the remaining work (and possibly merging this one to development as is), but I'm not sure how to reslve things.

@Sephsekla this branch should actually be closed, all of the features of this branch have already been merged in. I brought all of this into develop through smaller PRs.