Så här implementerar du övergångsstatusövergångar för anpassade webbapplikationer

WordPress använder inlägg och sidor för att ge det dynamiska innehållet för applikationer. Införandet av anpassade posttyper har ökat möjligheten att utveckla komplexa applikationer med WordPress.

Vanligtvis går normala inlägg genom ett väldefinierat arbetsflöde innan de publiceras på webbplatsen eller på ansökan. Under detta arbetsflöde tilldelas olika statuser till inlägg och hanteras internt av WordPress.

Inläggsstatuser kan användas som en kraftfull teknik för hantering av status i en anpassad webbapplikation. I den här artikeln kommer vi att diskutera hur man använder WordPress anpassade inläggsstatuser och övergångar för att bygga program som går utöver de vanliga webbplatser eller bloggar.

Har du erfarenhet av att arbeta med anpassade poststatusövergångar? Alla är välkomna att diskutera dina erfarenheter.


Förstå WordPress Post Status

WordPress använder wp_posts bord för att lagra både inlägg och sidor. Status för ett inlägg definierar ett tillfälligt tillstånd tills det publiceras på webbplatsen. Vanligtvis startar en inläggs status som en förslag och växlar mellan befintliga statuser tills det kommer till publicerat status. Låt oss ta en titt på den befintliga WordPress-poststatuslistan och deras roller.

  • publicera - Ett inlägg anses vara publicerat och kommer att vara offentligt tillgängligt på webbplatsen.
  • avvaktan - Ett inlägg väntar på granskning från en högre användarroll. Denna status kommer huvudsakligen att finnas på webbplatsen där du har flera författare eller användare som kan skapa poster på wp_post tabell.
  • förslag - Ett inlägg sparas tillfälligt och författaren kan göra ytterligare ändringar innan den publiceras.
  • auto-utkast - Ett inlägg sparas tillfälligt utan innehåll och författaren kan göra ytterligare ändringar innan publicering.
  • framtida - Ett inlägg är planerat att publiceras vid ett framtida datum. Det här är en vanlig teknik som används för att upprätthålla konsistens av inlägget.
  • privat - Ett inlägg är bara synligt för inloggade användare.
  • ärva - Detta anses vara en översyn av ett inlägg. WordPress tillåter flera ändringar av samma post.
  • skräp - Ett inlägg anses vara raderat.

Vanligtvis börjar varje post med a förslag eller auto-utkast status och fortsätter att utvecklas tills den når det önskade slutliga tillståndet. I nästa avsnitt ska vi titta på statusövergångar för WordPress och deras användning.


Arbetar med Post Status Transitions

Post status övergång är processen att växla mellan en status till en annan status. Vanligtvis hanteras befintliga postövergångar och deras respektive funktionalitet internt av WordPress. Men det finns många effektiva sätt att lägga till funktioner med postövergångar. Som ett resultat ger WordPress nu krokar för att arbeta med alla övergångsstatusövergångar; Därför kan vi dynamiskt lägga till nya funktioner vid övergången till ett inlägg.

Låt oss se hur det verkligen fungerar.

Antag att vi vill göra något när inläggsstatusen ändras från förslag till framtida. Följande kod visar hur du genomför en övergångsstatusövergång för föregående krav.

 funktion callback_function_name ($ new_status, $ old_status, $ post) // Kod här add_action ('draft_to_future', 'callback_function_name', 10, 3);

WordPress ger en åtgärdskrok av formatet Gamla status _to_ nya status för varje postövergång. Vi kan använda en återuppringningsfunktion för att tillhandahålla anpassad funktionalitet. Den här anpassade funktionen tar den gamla statusen, den nya statusen och det ändrade postobjektet som parametrar.

I det föregående avsnittet diskuterade vi åtta fördefinierade inläggsstatuser. Här har vi nio poststatuser för övergångar, inklusive en status som heter ny. Innan posten sparas betraktas den som ny. Så snart posten sparar till databasen kommer övergången att ske från new_to_ anpassad status.

Låt oss nu se postövergångarna för att publicera ett inlägg under normala omständigheter.

Föregående skärm visar postövergångarna på en webbplats med en enda författare. I grund och botten kan vi arbeta med statusövergångar mellan statuserna förenade med pilar. På en enda författarwebbplats är postövergångar enklare jämfört med flera författarwebbplatser.

Så låt oss ta en titt på processen för multi author webbplats.

På en webbplats med flera författare ändras processen något, eftersom alla inlägg måste granskas och godkännas av en auktoriserad person innan den publiceras Därför har flera författarwebbplatser ett ytterligare steg i övergångsprocessen efter övergången.

Hittills har vi tittat på standard övergångsstatusövergångar på en WordPress-webbplats. Nu är frågan hur är dessa övergångar kommer att vara användbara?

Det finns många sätt att använda övergångsstatusövergångar i applikationer. Låt oss titta på några av de vanliga funktionerna i statusövergångar.

  • Förslag till Avvaktan - Meddela redaktören för att granska inlägget.
  • Avvaktan till Framtida - Meddela författaren.
  • Avvaktan till Framtida - Lägg till inlägget i postkalendern på webbplatsen.
  • Framtida till Publicera - Meddela abonnenter via e-post.

Dessa är några av de mest grundläggande och gemensamma funktionerna som gjorts under postövergångar. Fram till nu har vi tittat på övergångsprocessen för statusöverföring för fördefinierade statyer.

Det verkliga värdet av poststatusövergångar kommer med användandet av anpassade poststatus. Nästa avsnitt beskriver detaljerna om att arbeta med anpassade inläggsstatuser för anpassade webbapplikationer.


Introduktion till anpassad poststatus

WordPress blir långsamt ett ramverk för att utveckla webbapplikationer genom att gå utöver det allmänna innehållshanteringssystemet. Anpassad poststatus blir avgörande för utvecklingen av komplexa applikationer. WordPress tillåter oss att skapa egna poststatuser och stöder övergångar mellan de här statuserna. Låt oss ta en titt på följande kod för att skapa en anpassad poststatus.

 funktion add_custom_post_status () register_post_status ('custom_status', $ args);  add_action ('init', 'add_custom_post_status');

Anpassade inläggsstatuser kan definieras med hjälp av register_post_status funktion, som tar ett poststatusnamn som den obligatoriska parametern. Den här syntaxen liknar den kod som används för skapandet av anpassad posttyp. Vi kan också vidarebefordra ytterligare argument baserat på våra preferenser. Du kan hitta en komplett argumentlista i WordPress Codex. När ovanstående kod används kommer den nya anpassade poststatusen att läggas till den befintliga listan.

Tyvärr har WordPress 'adminpanel inte det inbyggda stödet för anpassade inläggsstatuser. Därför måste vi hitta alternativa sätt att lägga till anpassade poststatus till administratörspanelen.

Att förklara processen för att integrera anpassad poststatus i administratörspanelen ligger utanför ramen för den här artikeln, så jag ska använda ett existerande plugin för att visa dig hur man arbetar med anpassade statuser.


Integrering av anpassad poststatus i administratörspanelen

I grund och botten måste vi anpassa den befintliga administrationsposten lämna in metabox för att visa anpassade poststatus i Status nedrullningsfältet. På detta stadium är WordPress-stöd för denna funktion mycket begränsad och det är därför svårt att hitta kvalitets plugins för att arbeta med anpassade poststatus.

Vi kan använda ett plugin som heter Redigera flöde för hantering av anpassade inläggsstatuser. Du kan ta en kopia av det här pluginet från http://wordpress.org/plugins/edit-flow/. När du är aktiverad, navigera till Anpassade statyer avsnitt under Redigera flöde menyn och du får en skärm som liknar följande.

Vi kan använda denna blankett för att skapa nya anpassade inläggsstatuser. Detta plugin använder internt register_post_status funktionen för att definiera den anpassade statusen och lagra den i wp_terms tabell. All statushantering görs internt av plugin.

Helst skulle vi vilja se dessa funktioner tillgängliga inom WordPress-kärnan. När du väl skapat hittar du listan över nya statuser som visas på följande skärm.

Nu är statuserna klara och du kan gå till bildskärmen och välja den nödvändiga statusen innan du sparar posten. Då kan du implementera statusövergångar på posten för att lägga till fler funktioner eller hantera befintliga funktioner.


Använda statusövergångar i anpassade webbapplikationer

Vi behöver använda egna posttyper i anpassade webbapplikationer. Anpassade inläggsstatuser spelar en viktig roll vid hantering av anpassade posttyper.

Vanligtvis har befintliga posttyper en mycket begränsad betydelse i arbetet med anpassade posttyper. Därför måste vi använda anpassade statusövergångar för att hantera statusen för anpassade inlägg. Låt oss titta på praktiska scenarier för att förstå behovet av anpassade poststatuser.

Online produktförsäljningssystem

Dessa dagar säljs de flesta produkter på nätet med hjälp av kundvagnar. Det finns gott om befintliga WordPress-webbplatser för att sälja produkter. I ett sådant system behöver vi ha en anpassad posttyp som heter Produkter för att lagra all information om produkter.

Tänk nu hur vi kan matcha de befintliga poststatuserna till produkter. Statuses like förslag, framtida, och avvaktan har ingen betydelse i samband med produkter. Så vi behöver anpassade statuser för att tillgodose sådana scenarier. Låt oss tänka på möjliga statuser för produkter.

Vanligtvis kan vi använda status som I lager, Beordrade, levereras, levereras, och Returnerad för produkter. Låt oss titta på följande skärm för möjliga statusövergångar.

Produkten börjar med en status på I lager, och slutar med en status på levereras eller Returnerad. Varje statusövergång kan användas för att utföra olika uppgifter. Till exempel när produktstatus ändras från I lager till Beordrade, Vi kan uppdatera aktievärdena. Så den åtgärd som ska användas för detta scenario är I lager _till_ beställt. Vi kan göra liknande aktiviteter på andra statusövergångar för att förbättra processen.

Biblioteksledningssystem

Detta är ett annat scenario där anpassade statuser blir mycket viktiga. I ett bibliotekssystem ändras statusen för en bok enligt de aktiviteter som utförs av biblioteksmedlemmar. I ett sådant system kan en bok ha statuser som Lånad, Förnyad, Tillgängliga, och Försenad. Låt oss överväga följande skärm för möjliga statusövergångar.

I detta scenario har statusövergångar blivit mycket mer komplexa jämfört med föregående scenario. En bok startar sin process från Tillgängliga status och växlar mellan andra statuser tills den återgår till Tillgängliga status. Låt oss överväga ett scenario för att använda poststatusövergångar i det här systemet.

I allmänhet finns det en gräns för antalet förnyelser av en enda bok. Så när bokens status ändras från Förnyad till Tillgängliga, Vi kan kontrollera medlemskontot för att se om medlemmen redan har nått gränsvärdet och blockera medlemmen från att förnya ytterligare.

Här diskuterade vi två scenarier för behovet av anpassade statusövergångar. Verkliga applikationer är mycket mer komplexa och därmed hittar du många tillfällen för behovet av anpassade statusövergångar.


Sammanfatta

Post status övergångar är ett mycket kraftfullt sätt att lägga till nya funktioner eller hantera arbetsflödet i applikationer, men det finns vissa nackdelar med denna teknik. Tänk på en situation där du måste skicka ett stort antal meddelanden i en övergångsstatus för en post.

I sådana fall kan du inte slutföra statusövergången tills alla meddelanden skickas, så det blir svårt att publicera inlägg. Generellt bör övergångsstatusövergångar inte användas för omfattande processer som tar lång tid. Det är upp till dig att välja klokt baserat på kraven.

Nu har jag några frågor till dig, och jag hoppas att alla kan dela din kunskap genom att svara på dessa frågor:

  1. Vill du att WordPress ska stödja anpassade statuser som standard? och varför?
  2. Vilka är de andra verkliga praktiska scenarierna för att använda post-statusövergångar?
  3. Vilka typer av funktioner du vill tillhandahålla med statusövergångar efter överföring?
  4. Hur skulle du planera att genomföra en omfattande process med övergångsstatusövergångar?

Ser fram emot att höra från dig.