Erfaringsresumé

Til det platform CMS, jeg selv byggede, har medlemsabonnementsdelen altid været "simpel at implementere". I weekenden omstrukturerede jeg denne del og udviklede kernedelen.

1. Metode

Generelt omfatter medlemskabsabonnement hovedsageligt tre dele: medlemskabsabonnementsplan og køb, medlemstilladelseskontrol og medlemsadministration.

1. For medlemskabsabonnementer og køb

Bare forbered dig på at lave nogle udvidelser baseret på det eksisterende indkøbscentersystem.

2. For medlemstilladelseskontrol,

Dette skal nævnes specielt. Vi planlægger ikke at gøre det baseret på et rolletilladelsessystem, men et separat medlemskontrolleret system.

Med udgangspunkt i rolleautoritetssystemet laves medlemmer om til en rolleserie, og hver type medlem laves til en rolle i denne rollerække. Det lyder fornuftigt. Men i dette tilfælde er det meget besværligt at gøre eller bruge, især når der er mange forretninger, de forskellige logikker vil være meget komplicerede, og alle former for forvirring vil opstå, hvis du ikke er forsigtig. Og det er ikke fleksibelt nok.

Desuden er medlemskabsabonnementsdelen af mange fremragende systemer faktisk ikke rollebaseret. I stedet implementeres tilladelseskontrol baseret på "mærker" eller ordrer. Mange velsælgende medlemskabsabonnement plug-ins, herunder WordPress, er lavet på denne måde.

Baseret på "brugertag":

I bund og grund er det samme princip som karaktersystemet. Det er for at definere nogle "mærker" af medlemmer. Brugere, der køber medlemskabsabonnementet, der er forbundet med dette "mærke", vil blive "mærket med dette mærke", så kontrollen af medlemstilladelser kan opnås.

Baseret på ordre:

Køb et medlemskabsabonnement og lav en ordre Efter betaling vil udløbstiden blive skrevet ind i ordren. Derfor kan du ud fra rækkefølgen vurdere, om brugeren er medlem, hvad det er for et medlem, og om det er udløbet. På denne måde kan du kontrollere medlemstilladelser.

Jeg har tidligere lavet en ordrebaseret metode, og denne gang planlægger jeg at bruge "brugertags".

Der er ikke noget galt i at være baseret på ordrer, men ordresystemet i platformen CMS, jeg bygger nu, understøtter mange ordretyper, hvilket gør ordremodellen relativt "stor, jeg har ikke planer om at "lægge vægt" på den længere. så jeg valgte Baseret på "brugertags".

3. Medlemsstyring

Baseret på den eksisterende brugerstyringsudvidelse planlægger vi ikke at lave medlemsstyring alene.

2. Gældende scenarier

1. Grundscenarie

Hele produktet har en eller flere abonnementsplaner, som brugerne køber og nyder godt af medlemstjenester.

Definer medlemsmærker globalt. Hvert medlemsmærke indeholder mindst tre felter: navn, slug og tilhørende abonnementsplan-id.

Når en bruger køber en abonnementsplan med et medlemsmærke, vil medlemsmærket og udløbstiden blive skrevet ind i brugerens metadata.

2. Platform/multi-lejer scenario

For platforme og SAAS med flere lejere er der et meget vigtigt scenarie: abonnementsplanen leveret af leverandøren selv.

Definer leverandørens medlemstag i leverandørens brugers metadata. Nøglen til leverandørens medlemstag kan ikke være den samme som nøglen til det globale medlemstag.

Når en bruger køber et abonnement hos denne udbyder, vil det tilsvarende medlemsmærke og udløbsdato blive skrevet til den købende brugers metadata.

Denne iteration implementerer kun grundlæggende scenarier, men den skal kunne udvides til platforms- og multilejerscenarier.

3. Find ud af, om medlemskabet er udløbet, når du logger ind

Når brugeren logger ind, vurderes det, om det er udløbet. Hvis det er udløbet, opdateres medlemsmærket i metadataene til falsk og udløbsdatoen til falsk.