Un ottimo e, forse, l’esempio pi\u00f9 popolare di un sistema CRUD \u00e8 phpMyAdmin<\/a>. PHPMyAdmin \u00e8 uno strumento utilizzato da quasi tutti gli sviluppatori web per gestire i dati MySQL online. \u00c8 diventato cos\u00ec ampiamente diffuso che attualmente pu\u00f2 essere definito uno strumento standard per la gestione dei database MySQL. Al giorno d’oggi \u00e8 preinstallato su quasi tutti gli strumenti CPanel dei provider di hosting.<\/p>\n Esistono migliaia di casi d’uso standard per i sistemi CRUD. Ad esempio, quasi tutti i cataloghi, i registri delle voci, le informazioni statistiche. Fondamentalmente, qualsiasi cosa relativa alla memorizzazione delle informazioni richiederebbe l’aggiunta, la modifica e la rimozione di bit di informazioni. \u00c8 qui che entrano in gioco i sistemi CRUD.<\/p>\n Lo stesso WordPress \u00e8 un potente CMS (Content Management System), che \u00e8 anche un caso speciale del sistema CRUD. Come sai, gli utenti del sito WordPress possono aggiungere post e pagine, modificarli o eliminarli. Ma a volte si verifica una situazione in cui \u00e8 necessario gestire alcuni dati del database direttamente dal front-end di WordPress che generalmente non \u00e8 pubblicato o correlato alla pagina e non si adatta bene alle tassonomie di WordPress. Tra le altre pu\u00f2 essere una di queste situazioni in cui avresti bisogno di un sistema CRUD indipendente in WordPress:<\/p>\n E richieste simili.<\/p>\n Primo: assicurati di averne davvero bisogno.<\/strong> Molte delle attivit\u00e0 non sono uniche e probabilmente puoi trovare un plug-in adatto alle tue esigenze. Ad esempio, se hai bisogno di un bug tracker, come menzionato sopra, puoi controllare e scaricare questo<\/a> o questo<\/a>.<\/p>\n E se hai bisogno di qualcosa di pi\u00f9 generico, come modificare diverse tabelle MySQL dal front-end di WordPress, prova il nostro plugin wpDataTables<\/a> che \u00e8 fondamentalmente un sistema CRUD in WordPress. Puoi vedere l’elenco delle funzioni e degli esempi di come funziona qui<\/a>. O anche provare una versione Lite gratuita nel repository dei plugin di WordPress<\/a>.<\/p>\n Vale la pena notare che wpDataTables non impone alcuna limitazione alla struttura dei dati, alla quantit\u00e0 di colonne o righe, supporta molti tipi di dati<\/a> e diversi tipi di input dell’editor<\/a>. Ad esempio alcuni tipi specifici come allegati o DateTime<\/a>. Inoltre, consente di modificare i dati tramite un editor di moduli popup<\/a>, con un editor inline<\/a> o anche con un editor di fogli di calcolo simile a Excel<\/a>.<\/p>\n Se ritieni ancora di dover creare un sistema CRUD personalizzato in WordPress, dovresti prepararti per un po’ di programmazione seria per farlo.<\/p>\n Se pensi che nessun plugin soddisfi le tue esigenze, creane uno tuo! Potrebbe non essere cos\u00ec spaventoso come sembra a prima vista. Inizia leggendo questo bel tutorial<\/a> sulla creazione di un plugin per WordPress da zero. E ovviamente anche questo<\/a> nel codice di WordPress.<\/p>\n Il primo passo iniziale quando crei un plug-in, incluso un sistema CRUD in un plug-in di WordPress, \u00e8 strutturare i file correttamente. Possono essercene di pi\u00f9 (controller, gestori di shortcode e altri), ma \u00e8 un minimo per cominciare.<\/p>\n Prima di tutto, avresti bisogno della parte di back-end: uno script PHP che farebbe effettivamente i lavori CRUD. Per questo, dovresti connetterlo con WordPress DB (oggetto globale $ wpdb). Puoi leggere un bel tutorial qui<\/a> sull’utilizzo del database di WordPress e dell’oggetto $wpdb nei tuoi plugin.<\/p>\n Se utilizzi un DB esterno, dovrai ad esempio utilizzare una connessione PDO<\/a> separata o semplicemente funzioni PHP MySQLi<\/a> integrate (se il tuo motore DB \u00e8 MySQL).<\/p>\n Il tuo compito in questo passaggio \u00e8 preparare un insieme di classi e metodi che accetteranno i dati dal front-end in una forma prevista, li convalideranno e li sanificheranno<\/a> (la sanificazione di tutti gli input \u00e8 una misura di sicurezza molto importante per tutti i sistemi CRUD) ed eseguiranno le azioni INSERT<\/strong>, UPDATE<\/strong> e DELETE<\/strong> sul tuo database.<\/p>\n Come descritto nel passaggio precedente, questi file "core" apparterrebbero alla cartella "source" del tuo nuovo plugin CRUD WordPress.<\/p>\n Quando le classi e i metodi di gestione del database sono preparati, il tuo plug-in avrebbe bisogno di un’interfaccia front-end per l’utente con il tuo nuovo sistema CRUD in WordPress. La soluzione migliore sarebbe quella di preparare una serie di modelli nei nuovi file di plug-in e riprodurli dove necessario con uno shortcode.<\/p>\n Ha senso mantenere sempre separati i modelli HTML dal codice (approccio MVC) e preparare file di modello separati logicamente, ad esempio: “edit.tpl.php”, “delete.tpl.php”, “list.tpl.php “, ecc. \u2013 un modello per ogni pagina o azione CRUD.<\/p>\n Qui<\/a> puoi leggere un ottimo articolo del codice sull’API Shortcode di WordPress.<\/p>\n Naturalmente, puoi farlo "stile vecchia scuola", con semplici invii di moduli e ricaricamento della pagina. Tuttavia, al giorno d’oggi non \u00e8 pi\u00f9 un approccio comune. L’uso di AJAX \u00e8 invece un approccio standard, tramite jQuery o altre librerie come Angular. Quindi la nostra raccomandazione \u00e8 di dedicare del tempo e esaminare l’utilizzo di AJAX nei plug-in di WordPress, ecco<\/a> un ottimo articolo del Codex su come utilizzare AJAX nei plug-in, sia lato amministratore che front-end.<\/p>\n Puoi inserire il codice JS nella cartella "assets" che hai preparato nel primo passaggio.<\/p>\n Al termine della parte di implementazione, prenditi del tempo e testa il tuo nuovo sistema CRUD in WordPress. Non puoi individuare tutti i bug dall’inizio, ma ripetere pi\u00f9 volte le azioni di routine CRUD con esempi diversi (casi "edge" preferibili, ad esempio quantit\u00e0 molto grandi di dati, fare clic pi\u00f9 volte sullo stesso pulsante, ecc.) ti aiuter\u00e0 sempre per intercettare la maggior parte dei bug \u2013 e questi si verificano sempre quando si implementa qualcosa di nuovo.<\/p>\n REST \u00e8 uno stile architettonico per la creazione di applicazioni in rete basate su un protocollo di comunicazione client-server, stateless e memorizzabile nella cache, ovvero il protocollo HTTP. CRUD \u00e8 l’acronimo di CREATE, READ, UPDATE e DELETE, le funzioni di base della memorizzazione persistente nella programmazione.<\/p>\n Le operazioni CRUD, cio\u00e8 CREATE, READ, UPDATE, DELETE, sono simili ai comandi di base REST, cio\u00e8 GET, PUT, POST, DELETE, il che crea confusione tra i due. Cos’\u00e8 CRUD? Cos’\u00e8 il RIPOSO? In CRUD vs REST, qual \u00e8 la definizione CRUD? REST \u00e8 una semplice copia carbone di CRUD?<\/p>\n Queste sono tutte domande molto pertinenti a cui questo articolo intende rispondere in dettaglio!<\/p>\n Non \u00e8 possibile comprendere termini come API REST, servizi REST, matrice CRUD o database CRUD o programmazione REST se non si comprende la differenza tra i due processi per quanto riguarda il modo in cui funzionano. La confusione scomparir\u00e0 una volta che conosci questa differenza.<\/p>\n Puoi lavorare REST su qualsiasi risorsa, che si tratti di un file multimediale, documento, sito Web, ecc. Non ci sono restrizioni su ci\u00f2 su cui puoi lavorare REST; puoi usare HTML solo come protocollo di comunicazione per evidenziare le risorse. REST \u00e8 l’acronimo di Representational State Transfer.<\/p>\n REST indica che ogni URL distintivo rappresenta un oggetto, a cui \u00e8 possibile accedere tramite HTTP GET, nonch\u00e9 modificarlo ed eliminarlo tramite HTTP POST, PUT o DELETE.<\/p>\n Puoi applicare CRUD solo ai record del database e non puoi creare API CRUD come crei API REST. L’applicazione CRUD \u00e8 limitata ai database, motivo per cui CRUD, a differenza di REST, non \u00e8 uno stile di architettura, ma un ciclo. Le app e i siti Web contengono tutti cicli CRUD diversi.<\/p>\n Ad esempio, un visitatore di un sito di e-commerce pu\u00f2 CREARE un account, AGGIORNARE l’account, LEGGERE le informazioni ed ELIMINARE l’account. Questo \u00e8 un ciclo CRUD completo che include ogni operazione CRUD.<\/p>\n Ad esempio, sullo stesso sito di e-commerce, un visitatore pu\u00f2 CREARE un articolo nell’e-cart, quindi completare l’intero ciclo CRUD LETTURA, AGGIORNAMENTO e persino CANCELLAZIONE dell’articolo.<\/p>\n I comandi di base di Representational State Transfer – l’acronimo REST – ruotano attorno a un oggetto o una risorsa, che pu\u00f2 essere descritto come qualsiasi cosa che puoi rivelare usando il protocollo HTTP. Esempi di risorse REST: immagine, sito Web, documento, servizio. Il cielo \u00e8 il limite.<\/p>\n REST \u00e8 un’interfaccia di programmazione delle applicazioni, o API, o un’architettura destinata alla multimedialit\u00e0 distribuita. Un’API \u00e8 un servizio Web che segue i principi dell’architettura REST. Pertanto, REST chiama ciascuna API tramite uno dei metodi di richiesta HTTP, GET, PUT, POST e DELETE.<\/p>\n Il mandato client-server sottolinea il fatto che REST rappresenta un metodo distribuito che si basa sulla natura della separazione client-server. Un servizio REST comporta diverse funzionalit\u00e0 e si occupa delle richieste. Il client effettua le richieste e il server le accetta o le rifiuta.<\/p>\n L’apolidia limita il tipo di richieste che possono essere inviate tra consumatore e server. In effetti, \u00e8 la richiesta che avvia la comunicazione client-servizio, in cui la richiesta contiene tutte le informazioni necessarie al server per rispondere.<\/p>\n Lo scopo della memorizzazione nella cache di una richiesta non \u00e8 mai dover inviare la stessa richiesta due volte perch\u00e9 la memorizzazione nella cache indica al server di etichettare le risposte come memorizzabili nella cache o meno. Di conseguenza, la memorizzazione nella cache riduce i vincoli o le restrizioni generati dall’apolidia.<\/p>\n Il contratto uniforme esclude l’uso di diverse interfacce indipendenti all’interno di un’interfaccia di programmazione dell’applicazione o API. REST si attiene ai principi di un contratto uniforme. Pertanto, un’interfaccia REST \u00e8 condivisa tramite connessioni ipermediali.<\/p>\n Un sistema a pi\u00f9 livelli utilizza diversi livelli indipendenti per sviluppare ed estendere l’interfaccia. Poich\u00e9 i livelli non possono vedersi l’uno nell’altro, \u00e8 possibile inserire nuove richieste e middleware che non influiranno sui comandi iniziali e sul funzionamento client-server.<\/p>\n Sebbene Client-Server, Caching, Statelessness, Uniform Contract e Layered System siano indispensabili per le app RESTful, Code-On-Demand non \u00e8 obbligatorio. Tuttavia, Code-on-Demand consente alla logica all’interno dei client di rimanere indipendente e quindi aggiornata separatamente dalla logica del server.<\/p>\n CRUD comporta le operazioni essenziali eseguite nell’archiviazione di dati statici o nei database, come la gestione di record o oggetti passivi. CRUD essenzialmente manipola i dati di base.<\/p>\n REST si basa sulla rappresentazione delle risorse tramite URL univoci, dove le risorse sono astrazioni di oggetti, in cui il commento di un utente pu\u00f2 essere una risorsa, ad esempio.<\/p>\n In quanto tale, REST comporta pi\u00f9 di un record in una tabella dei commenti. REST riguarda la relazione del record con la risorsa utente e il post\/commento a cui \u00e8 allegato. REST \u00e8 uno stile API di altissimo livello che interagisce con un sistema complesso.<\/p>\n Naturalmente, questo articolo non era un tutorial completo, dal momento che ci sarebbero volute venti pagine per scriverne uno. Ma facci sapere se hai qualche domanda o se vorresti vedere un esempio passo dopo passo specifico e ne creeremo uno per te.<\/p>\n Speriamo sia stato utile in qualche modo.<\/p>\n Grazie per aver letto!<\/p>\n Fonte immagine: http:\/\/www.tyseo.net<\/a><\/p>\nPerch\u00e9 dovresti aver bisogno di un sistema CRUD in WordPress?<\/h2>\n
\n
Come integrare un sistema CRUD in un sito WordPress?<\/h2>\n
La soluzione pi\u00f9 semplice: prova a trovare un plug-in adatto<\/h3>\n
Avvia un nuovo plugin per WordPress<\/h3>\n
\nL’approccio abituale consiste nel posizionare il file del punto CRUD della voce principale nella directory principale del plug-in e preparare diverse sottocartelle:<\/p>\n\n
Crea editor back-end (classi PHP)<\/h3>\n
Crea un’interfaccia front-end (HTML, JS, PHP)<\/h3>\n
Connetti front-end e back-end con le chiamate AJAX (JS)<\/h3>\n
Testare, perfezionare ed eseguire il debug<\/h3>\n
CRUD vs REST: qual \u00e8 la differenza<\/h2>\n
Come funziona il REST?<\/strong><\/h3>\n
Come funziona CRUD?<\/strong><\/h3>\n
Il fondamento ei principi del REST<\/strong><\/h3>\n
I sei principi guida dell’architettura RESTful<\/strong><\/h3>\n
\n
Mandato client-server<\/strong><\/h3>\n<\/li>\n<\/ol>\n
\n
Apolidia<\/strong><\/h3>\n<\/li>\n<\/ol>\n
![\"Creazione](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-205612-61e8cbbce0972.jpg\")
<\/a><\/p>\n\n
Memorizzazione nella cache<\/strong><\/h3>\n<\/li>\n<\/ol>\n
\n
Contratto uniforme<\/strong><\/h3>\n<\/li>\n<\/ol>\n
\n
Sistema a strati<\/strong><\/h3>\n<\/li>\n<\/ol>\n
\n
Opzionale: codice su richiesta<\/strong><\/h3>\n<\/li>\n<\/ol>\n
Considerazioni finali su CRUD vs REST<\/strong><\/h3>\n
\n