Den här artikeln om att skapa ett CRUD-system i WordPress publicerades redan 2014. Men vi märkte att detta ämne blev ännu mer aktuellt, så vi bestämde oss för att ge det ett nytt utseende.

Vad är ett CRUD-system, hur integrerar man ett CRUD-system för MySQL i din WordPress-webbplats, vilka är för- och nackdelarna med att använda olika tillvägagångssätt?

Vad är ett CRUD-system?

Förkortningen CRUD kommer från C reate, R ead, U pdate, D elete. Vilket med andra ord innebär ett datahanteringssystem. På webben skulle det med största sannolikhet betyda en mjukvara som hanterar poster i din databas. Vanligtvis hänvisar det till MySQL, PostgreSQL, MS SQL eller andra DB-motorer.

Ett bra, och kanske, det mest populära exemplet på ett CRUD-system är phpMyAdmin. PHPMyAdmin är ett verktyg som används av nästan alla webbutvecklare för att hantera MySQL-data online. Det blev så utbrett att det för närvarande kan kallas ett standardverktyg för att hantera MySQL-databaser. Numera är det förinstallerat nästan på alla CPanel-verktyg hos värdleverantörer.

Det finns tusentals standardanvändningsfall för CRUD-system. Till exempel – nästan vilken katalog som helst, inträdeslogg, statistisk information. I grund och botten skulle allt relaterat till lagring av information kräva att man lägger till, modifierar och tar bort informationsbitar. Det är då CRUD-system kommer in i bilden.

Varför skulle du behöva ett CRUD-system i WordPress?

WordPress i sig är ett kraftfullt CMS (Content Management System), vilket också är ett specialfall av CRUD-system. Som ni vet kan WordPress-användare lägga till inlägg och sidor, redigera eller ta bort dem. Men ibland stöter du på en situation när du behöver hantera en del databasdata direkt från WordPress-gränssnittet som i allmänhet inte är postat eller sidrelaterat och inte passar bra i WordPress-taxonomier. Det kan bland annat vara en av dessa situationer när du skulle behöva ett oberoende CRUD-system i WordPress:

Du skulle vilja ha en buggspårare, inmatningslogg eller något annat verktyg för datainmatning på din WordPress-webbplats;
Eller till exempel, du vill tillåta några av användarna att redigera vissa affärsrelaterade data från din webbplats front-end utan att ge dem åtkomst till WordPress webbplatsens adminpanel, eller kanske till och med utan att avslöja det faktum att webbplatsen körs på WordPress;
Ett annat exempel är ett krav på att tillåta vissa användare att redigera en DB-tabell. Till exempel, ändra en beställning, redigera vissa personuppgifter, etc.

Och liknande önskemål.

Hur integrerar man ett CRUD-system i en WordPress-webbplats?

Den enklaste lösningen – försök hitta en lämplig plugin

Först – se till att du verkligen behöver en. Många av uppgifterna är inte unika och du kan förmodligen hitta ett plugin som skulle passa dina behov. Om du t.ex. behöver en buggspårare, som nämnts ovan, kan du kontrollera och ladda ner den här eller den här.

Och om du behöver något mer generiskt, som att redigera olika MySQL-tabeller från WordPress-gränssnittet, prova vårt plugin wpDataTables som i grunden är ett CRUD-system i WordPress. Du kan se listan med funktioner och exempel på hur det fungerar här. Eller till och med prova en gratis Lite-version i WordPress-pluginförrådet.

Det är värt att notera att wpDataTables inte lägger några begränsningar på datastruktur, antal kolumner eller rader, stöder många datatyper och olika editorinmatningstyper. Till exempel vissa specifika typer som bilagor eller DateTime. Det tillåter också redigering av data via en popup-formulärredigerare, med en inline-redigerare eller till och med med en Excel-liknande redigerare för kalkylblad.

Om du fortfarande känner att du behöver bygga ett anpassat CRUD-system i WordPress, bör du förbereda dig på lite seriös kodning för att få det gjort.

Starta ett nytt WordPress-plugin

Om du tror att ingen plugin passar dina behov, skapa din egen! Det kanske inte är så läskigt som det verkar vid första anblicken. Börja med att läsa den här trevliga handledningen om att skapa ett WordPress-plugin från början. Och naturligtvis även denna i WordPress Codex.

Det första första steget när du skapar ett plugin – inklusive ett CRUD-system i ett WordPress-plugin – är att strukturera filerna ordentligt.
Det vanliga tillvägagångssättet är att placera CRUD-punktfilen för huvudingången i plugin-programmets rotkatalog och att förbereda flera undermappar:

Tillgångar – alla javascript, stilmallar, typsnitt, bilder och andra statiska tillgångar som kommer att vara nödvändiga för ditt CRUD-system;
Source – mapp för "core" PHP-klasserna som kommer att utföra all CRUD-funktionalitet i back-end;
Lib – mapp för alla tredjepartskomponenter som du kanske vill använda i ditt CRUD-system;
Mallar – mapp för HTML-mallar som kommer att vara användargränssnittet för ditt CRUD-system.

Det kan finnas fler (kontrollanter, kortkodshanterare och andra) – men det är ett minimum till att börja med.

Skapa editorback-end (PHP-klasser)

Först och främst skulle du behöva back-end-delen: ett PHP-skript som faktiskt skulle göra CRUD-jobben. För detta måste du ansluta den till WordPress DB (globalt $wpdb-objekt). Du kan läsa en trevlig handledning här om hur du använder WordPress-databasen och $wpdb-objektet i dina plugins.

Om du använder en extern DB behöver du t.ex. använda en separat PDO-anslutning, eller bara inbyggda PHP MySQLi- funktioner (om din DB-motor är MySQL).

Din uppgift i detta steg är att förbereda en uppsättning klasser och metoder som kommer att acceptera data från front-end i någon förväntad form, validera och sanera den (sanering av all input är en mycket viktig säkerhetsåtgärd för alla CRUD-system) och utföra åtgärderna INSERT, UPDATE och DELETE på din databas.

Som beskrivits i föregående steg skulle dessa "kärn"-filer tillhöra mappen "källa" i ditt nya CRUD WordPress-plugin.

Skapa ett front-end-gränssnitt (HTML, JS, PHP)

När databashanteringsklasserna och metoderna är förberedda, skulle ditt plugin behöva ett front-end-gränssnitt för användaren att med ditt nya CRUD-system i WordPress. Den bästa lösningen skulle vara att förbereda en uppsättning mallar i dina nya plugin-filer och mata ut den var du än behöver med en kortkod.

Det är vettigt att alltid hålla HTML-mallarna åtskilda från koden (MVC-metoden), och att förbereda logiskt separerade mallfiler, t.ex.: "edit.tpl.php", "delete.tpl.php", "list.tpl.php". ", etc. – en mall för varje CRUD-sida eller åtgärd.

Här kan du läsa en bra codex-artikel om WordPress Shortcode API.

Anslut front-end med back-end med AJAX-samtal (JS)

Naturligtvis kan du göra det "gammaldags stil", med enkla formulärinlämningar och omladdning av sidan. Men nuförtiden är det inte ett vanligt tillvägagångssätt längre. Att använda AJAX är en standardmetod istället, antingen genom jQuery eller andra bibliotek som Angular. Så vår rekommendation är att ta lite tid och undersöka hur du använder AJAX i dina WordPress-plugins, här är en bra Codex-artikel om hur du använder AJAX i dina plugins – både admin och front-end-sidan.

Du kan lägga JS-koden i mappen "tillgångar" som du förberedde i det första steget.

Testa, förfina och felsöka

När implementeringsdelen är klar – ta lite tid och testa ditt nya CRUD-system i WordPress. Du kan inte upptäcka alla buggar från början, men att upprepa CRUD rutinåtgärder flera gånger med olika exempel (föredragna "edge"-fall – t.ex. mycket stora mängder data, att klicka flera gånger på samma knapp, etc.) kommer alltid att hjälpa dig att fånga de flesta av buggarna – och dessa händer alltid när du implementerar något nytt.

CRUD vs REST: Vad är skillnaden

REST är en arkitektonisk stil för att bygga nätverksbaserade applikationer baserade på ett klient-server, tillståndslöst, cachebart kommunikationsprotokoll, dvs HTTP-protokollet. CRUD är en akronym för CREATE, READ, UPDATE och DELETE, de grundläggande funktionerna för beständig lagring i programmering.

CRUD-operationer, dvs CREATE, READ, UPDATE, DELETE, liknar REST grundläggande kommandon, dvs GET, PUT, POST, DELETE, vilket leder till förvirring mellan de två. Vad är CRUD? Vad är REST? Vad är CRUD-definitionen i CRUD vs REST? Är REST bara en kopia av CRUD?

Dessa är alla mycket relevanta frågor som den här artikeln avser att besvara i detalj!

Hur fungerar REST?

Du kan inte förstå termer som REST API, REST-tjänster, CRUD-matris eller CRUD-databas eller REST-programmering om du inte förstår skillnaden mellan de två processerna när det gäller hur de fungerar. Förvirringen kommer att försvinna när du känner till denna skillnad.

Du kan arbeta REST på vilken resurs som helst, oavsett om det är en mediafil, dokument, webbplats, etc. Det finns inga begränsningar för vad du kan arbeta REST på; du kan bara använda HTML som kommunikationsprotokoll för att peka ut resurserna. REST står för Representational State Transfer.

REST indikerar att där representerar varje distinkt URL något objekt, som du kan komma till via en HTTP GET, samt modifiera och ta bort den via HTTP POST, PUT eller DELETE.

Hur fungerar CRUD?

Du kan bara tillämpa CRUD på databasposter, och du kan inte skapa CRUD API:er som du skapar REST API:er. CRUD-applikationen är begränsad till databaser, varför CRUD, till skillnad från REST, inte är en arkitekturstil, utan en cykel. Appar och webbplatser innehåller alla olika CRUD-cykler.

En besökare på en e-handelswebbplats kan t.ex. SKAPA ett konto, UPPDATERA kontot, LÄSA informationen och RADERA kontot. Det är en fullständig CRUD-cykel som inkluderar varje CRUD-operation.

På samma e-handelswebbplats kan en besökare t.ex. SKAPA en vara i e-vagnen och sedan slutföra hela CRUD-cykeln genom att LÄSA, UPPDATERA och till och med RADERA varan.

Grunden och principerna för REST

De grundläggande kommandona för Representational State Transfer – REST akronymen – kretsar kring ett objekt eller en resurs, vilket kan beskrivas som vad som helst som du kan avslöja med hjälp av HTTP-protokollet. Exempel på REST-resurser: bild, webbplats, dokument, tjänst. Endast fantasin sätter gränser.

REST är ett applikationsprogrammeringsgränssnitt, eller API, eller en arkitektur avsedd för distribuerad multimedia. Ett API är en webbtjänst som följer principerna för REST-arkitektur. Således anropar REST varje API via en av HTTP-begäransmetoderna, GET, PUT, POST och DELETE.

De sex vägledande principerna för RESTful arkitektur

Klient-servermandat

Klient-servermandatet betonar det faktum att REST representerar en distribuerad metod som förlitar sig på typen av klient-serverseparation. En REST-tjänst innebär flera möjligheter och tar hand om förfrågningar. Klienten gör förfrågningarna och servern accepterar eller nekar dem.

Statslöshet

Statslöshet begränsar vilken typ av förfrågningar som kan skickas mellan konsument och server. I själva verket är det begäran som initierar klient-tjänstkommunikation, där begäran innehåller all information som behövs för att servern ska kunna svara tillbaka.

Cachning

Syftet med att cachelagra en begäran är att aldrig behöva skicka in samma begäran två gånger eftersom cachning instruerar servern att märka svar som cachebara eller inte. Som ett resultat minskar cachelagring de begränsningar eller restriktioner som genereras av tillståndslöshet.

Enhetligt kontrakt

Uniform Contract utesluter användningen av flera oberoende gränssnitt i ett applikationsprogrammeringsgränssnitt eller API. REST håller sig till principerna för ett enhetligt kontrakt. Därför delas ett REST-gränssnitt via hypermediaanslutningar.

System i lager

Ett lagersystem använder flera oberoende lager för att utveckla och utöka gränssnittet. Eftersom lager inte kan se in i varandra kan nya förfrågningar och mellanprogram infogas som inte kommer att påverka de initiala kommandona och klient-serverns funktion.

Valfritt: Code-On-Demand

Medan Client-Server, Caching, Statelessness, Uniform Contract och Layered System är måsten för RESTful-appar, är Code-On-Demand inte obligatoriskt. Code-on-Demand tillåter dock att logiken inom klienterna förblir oberoende och därmed uppdateras separat från serverlogiken.

Avslutande tankar om CRUD vs REST

CRUD innebär de väsentliga operationerna som utförs i statisk datalagring eller databaser, såsom hantering av passiva poster eller objekt. CRUD manipulerar i huvudsak grundläggande data.

REST förlitar sig på att representera resurser via unika URL:er, där resurser är objektabstraktioner, där kommentaren från en användare till exempel kan vara en resurs.

Som sådan innebär REST mer än en post i en kommentarstabell. REST handlar om postens relation till användarresursen och inlägget/kommentaren som den är bifogad. REST är en API-stil på mycket hög nivå som interagerar med ett komplext system.

Naturligtvis var den här artikeln inte en komplett handledning – eftersom det skulle ta tjugo sidor att skriva en. Men låt oss veta om du har några frågor eller vill se ett specifikt steg-för-steg-exempel, så skapar vi ett åt dig.

Vi hoppas att det var till hjälp på något sätt.

Tack för att du läste!

Bildkälla: http://www.tyseo.net

Inspelningskälla: wpdatatables.com