Création d’un système CRUD dans WordPress – Plugin de tables wpDataTables

Cet article sur la création d’un système CRUD dans WordPress a été publié en 2014. Cependant, nous avons remarqué que ce sujet devenait encore plus actuel, nous avons donc décidé de lui donner un nouveau look.

Qu’est-ce qu’un système CRUD, comment intégrer un système CRUD pour MySQL dans votre site WordPress, quels sont les avantages et les inconvénients d’utiliser différentes approches ?

Qu’est-ce qu’un système CRUD ?

L’abréviation CRUD vient de C reate, L ead, U pdate, D elete. Ce qui, en d’autres termes, signifie un système de gestion des données. Sur le Web, cela signifierait très probablement un logiciel qui gère les entrées de votre base de données. Habituellement, il fait référence à MySQL, PostgreSQL, MS SQL ou à d’autres moteurs de base de données.

Un bon exemple, et peut-être le plus populaire, d’un système CRUD est phpMyAdmin. PHPMyAdmin est un outil utilisé par presque tous les développeurs Web pour gérer les données MySQL en ligne. Il s’est tellement répandu qu’il peut actuellement être qualifié d’outil standard pour la gestion des bases de données MySQL. De nos jours, il est préinstallé sur presque tous les outils CPanel chez les hébergeurs.

Il existe des milliers de cas d’utilisation standard pour les systèmes CRUD. Par exemple – presque n’importe quel catalogue, journal d’entrée, informations statistiques. Fondamentalement, tout ce qui concerne le stockage d’informations nécessiterait d’ajouter, de modifier et de supprimer des bits d’information. C’est alors que les systèmes CRUD entrent en jeu.

Pourquoi auriez-vous besoin d’un système CRUD dans WordPress ?

WordPress lui-même est un puissant CMS (Content Management System), qui est également un cas particulier du système CRUD. Comme vous le savez, les utilisateurs du site WordPress peuvent ajouter des articles et des pages, les modifier ou les supprimer. Mais parfois, vous rencontrez une situation où vous devez gérer certaines données de base de données directement à partir du front-end WordPress qui ne sont généralement pas publiées ou liées à la page et ne correspondent pas bien aux taxonomies WordPress. Entre autres, cela peut être l’une de ces situations où vous auriez besoin d’un système CRUD indépendant dans WordPress :

• Vous aimeriez avoir un outil de suivi des bogues, un journal des entrées ou un autre outil de saisie de données sur votre site WordPress ;
• Ou, par exemple, vous souhaitez autoriser certains utilisateurs à modifier certaines données commerciales à partir du front-end de votre site sans leur donner accès au panneau d’administration du site WordPress, ou peut-être même sans divulguer le fait que le site fonctionne sur WordPress ;
• Un autre exemple est une exigence pour permettre à certains utilisateurs de modifier une table de base de données. Par exemple, modifier une commande passée, modifier certaines données personnelles, etc.

Et demandes similaires.

Comment intégrer un système CRUD dans un site WordPress ?

La solution la plus simple – essayez de trouver un plugin approprié

Tout d’abord, assurez-vous que vous en avez vraiment besoin. De nombreuses tâches ne sont pas uniques et vous pouvez probablement trouver un plugin qui répondrait à vos besoins. Par exemple, si vous avez besoin d’un outil de suivi des bogues, comme mentionné ci-dessus, vous pouvez vérifier et télécharger celui -ci ou celui-ci.

Et si vous avez besoin de quelque chose de plus générique, comme l’édition de différentes tables MySQL à partir du front-end WordPress, essayez notre plugin wpDataTables qui est essentiellement un système CRUD dans WordPress. Vous pouvez voir la liste des fonctionnalités et des exemples de leur fonctionnement ici. Ou même essayez une version Lite gratuite dans le référentiel de plugins WordPress.

Il convient de noter que wpDataTables n’impose aucune limitation sur la structure des données, le nombre de colonnes ou de lignes, prend en charge de nombreux types de données et différents types d’entrée d’éditeur. Par exemple, certains types spécifiques comme les pièces jointes ou DateTime. En outre, il permet d’éditer des données via un éditeur de formulaire contextuel, avec un éditeur en ligne ou même avec un éditeur de tableur de type Excel.

Si vous pensez toujours que vous avez besoin de créer un système CRUD personnalisé dans WordPress, vous devez vous préparer à un codage sérieux pour le faire.

Démarrer un nouveau plugin WordPress

Si vous pensez qu’aucun plugin ne correspond à vos besoins, créez le vôtre! Ce n’est peut-être pas aussi effrayant qu’il n’y paraît à première vue. Commencez par lire ce joli tutoriel sur la création d’un plugin WordPress à partir de zéro. Et aussi bien sûr celui-ci dans WordPress Codex.

La première étape initiale lorsque vous créez un plugin – y compris un système CRUD dans un plugin WordPress – consiste à structurer correctement les fichiers.
L’approche habituelle consiste à placer le fichier de point d’entrée CRUD principal dans le répertoire racine du plugin et à préparer plusieurs sous-dossiers :

• Actifs – tous les javascript, feuilles de style, polices, images et autres actifs statiques qui seront nécessaires pour votre système CRUD ;
• Source – dossier pour les classes PHP "core" qui exécuteront toutes les fonctionnalités CRUD dans le back-end ;
• Lib – dossier pour tous les composants tiers que vous souhaitez utiliser dans votre système CRUD ;
• Modèles – dossier pour les modèles HTML qui seront l’interface utilisateur de votre système CRUD.

Il peut y en avoir plus (contrôleurs, gestionnaires de codes courts et autres) – mais c’est un minimum pour commencer.

Créer le back-end de l’éditeur (classes PHP)

Tout d’abord, vous auriez besoin de la partie back-end : un script PHP qui effectuerait réellement les tâches CRUD. Pour cela, vous devez le connecter à la base de données WordPress (objet global $wpdb). Vous pouvez lire ici un joli tutoriel sur l’utilisation de la base de données WordPress et de l’objet $wpdb dans vos plugins.

Si vous utilisez une base de données externe, vous devrez par exemple utiliser une connexion PDO séparée ou simplement des fonctions PHP MySQLi intégrées (si votre moteur de base de données est MySQL).

Votre tâche à cette étape est de préparer un ensemble de classes et de méthodes qui accepteront les données du front-end sous une forme attendue, de les valider et de les nettoyer (la désinfection de toutes les entrées est une mesure de sécurité très importante pour tous les systèmes CRUD) et d’effectuer les actions INSERT, UPDATE et DELETE sur votre base de données.

Comme décrit à l’étape précédente, ces fichiers "de base" appartiendraient au dossier "source" de votre nouveau plugin CRUD WordPress.

Créer une interface frontale (HTML, JS, PHP)

Lorsque les classes et les méthodes de gestion de base de données sont préparées, votre plugin aurait besoin d’une interface frontale pour l’utilisateur avec votre nouveau système CRUD dans WordPress. La meilleure solution serait de préparer un ensemble de modèles dans vos nouveaux fichiers de plug-in et de le sortir où vous en avez besoin avec un shortcode.

Il est logique de toujours garder les modèles HTML séparés du code (approche MVC) et de préparer des fichiers de modèles séparés logiquement, par exemple : "edit.tpl.php", "delete.tpl.php", "list.tpl.php". », etc. – un modèle pour chaque page ou action CRUD.

Ici, vous pouvez lire un excellent article du codex sur l’API WordPress Shortcode.

Connectez le front-end au back-end avec les appels AJAX (JS)

Bien sûr, vous pouvez le faire "à l’ancienne", avec de simples soumissions de formulaires et le rechargement de pages. Cependant, de nos jours, ce n’est plus une approche courante. L’utilisation d’AJAX est plutôt une approche standard, soit via jQuery, soit via d’autres bibliothèques comme Angular. Notre recommandation est donc de prendre un peu de temps et d’examiner l’utilisation d’AJAX dans vos plugins WordPress, voici un excellent article du Codex sur la façon d’utiliser AJAX dans vos plugins – à la fois côté administrateur et côté frontal.

Vous pouvez mettre le code JS dans le dossier "assets" que vous avez préparé à la première étape.

Tester, affiner et déboguer

Lorsque la partie mise en œuvre est terminée, prenez un peu de temps et testez votre nouveau système CRUD dans WordPress. Vous ne pouvez pas repérer tous les bogues dès le début, mais répéter plusieurs fois les actions de routine CRUD avec différents exemples (cas "périphériques" préférables – par exemple, de très grandes quantités de données, cliquer plusieurs fois sur le même bouton, etc.) vous aidera toujours. pour attraper la plupart des bugs – et ceux-ci se produisent toujours lorsque vous implémentez quelque chose de nouveau.

CRUD vs REST : quelle est la différence ?

REST est un style architectural de création d’applications en réseau basé sur un protocole de communication client-serveur, sans état et pouvant être mis en cache, c’est-à-dire le protocole HTTP. CRUD est un acronyme pour CREATE, READ, UPDATE et DELETE, les fonctions de base du stockage persistant en programmation.

Les opérations CRUD, c’est-à-dire CREATE, READ, UPDATE, DELETE, sont similaires aux commandes de base REST, c’est-à-dire GET, PUT, POST, DELETE, ce qui conduit à une confusion entre les deux. Qu’est-ce que CRUD? Qu’est-ce que le REPOS ? Dans CRUD vs REST, quelle est la définition CRUD ? Est-ce que REST est une simple copie carbone de CRUD ?

Autant de questions très pertinentes auxquelles cet article entend répondre en détail !

Comment fonctionne REST ?

Vous ne pouvez pas comprendre des termes tels que API REST, services REST, matrice CRUD, base de données CRUD ou programmation REST si vous ne comprenez pas la différence entre les deux processus en ce qui concerne leur fonctionnement. La confusion disparaîtra une fois que vous connaîtrez cette différence.

Vous pouvez travailler REST sur n’importe quelle ressource, qu’il s’agisse d’un fichier multimédia, d’un document, d’un site Web, etc. Il n’y a aucune restriction quant à ce sur quoi vous pouvez travailler REST ; vous pouvez utiliser HTML uniquement comme protocole de communication pour pointer les ressources. REST signifie Representational State Transfer.

REST indique que chaque URL distinctive représente un objet auquel vous pouvez accéder via un HTTP GET, ainsi que le modifier et le supprimer via HTTP POST, PUT ou DELETE.

Comment fonctionne CRUD ?

Vous ne pouvez appliquer CRUD que sur des enregistrements de base de données et vous ne pouvez pas créer d’API CRUD comme vous créez des API REST. L’application CRUD est limitée aux bases de données, c’est pourquoi CRUD, contrairement à REST, n’est pas un style d’architecture, mais un cycle. Les applications et les sites Web contiennent tous des cycles CRUD différents.

Par exemple, un visiteur sur un site Web de commerce électronique peut CRÉER un compte, METTRE À JOUR le compte, LIRE les informations et SUPPRIMER le compte. C’est un cycle CRUD complet qui inclut toutes les opérations CRUD.

Par exemple, sur le même site Web de commerce électronique, un visiteur peut CRÉER un article dans le panier électronique, puis terminer le cycle CRUD complet en LISANT, METTRE À JOUR et même SUPPRIMER l’article.

Le fondement et les principes de REST

Les commandes de base du Representational State Transfer – l’acronyme REST – tournent autour d’un objet ou d’une ressource, qui peut être décrit comme tout ce que vous pouvez révéler à l’aide du protocole HTTP. Exemples de ressources REST : image, site Web, document, service. Le ciel est la limite.

REST est une interface de programmation d’application, ou API, ou une architecture destinée au multimédia distribué. Une API est un service Web qui suit les principes de l’architecture REST. Ainsi, REST appelle chaque API via l’une des méthodes de requête HTTP, GET, PUT, POST et DELETE.

Les six principes directeurs de l’architecture RESTful

1. Mandat client-serveur

Le mandat client-serveur met l’accent sur le fait que REST représente une méthode distribuée qui repose sur la nature de la séparation client-serveur. Un service REST implique plusieurs fonctionnalités et répond aux demandes. Le client fait les demandes et le serveur les accepte ou les refuse.

2. Apatridie

L’apatridie limite le type de requêtes pouvant être soumises entre le consommateur et le serveur. En effet, c’est la demande qui initie la communication client-service, où la demande contient toutes les informations nécessaires pour que le serveur réponde.

3. Mise en cache

Le but de la mise en cache d’une requête est de ne jamais avoir à soumettre la même requête deux fois, car la mise en cache demande au serveur d’étiqueter les réponses comme pouvant être mises en cache ou non. Par conséquent, la mise en cache réduit les contraintes ou les restrictions générées par l’apatridie.

4. Contrat uniforme

Le contrat uniforme exclut l’utilisation de plusieurs interfaces indépendantes à l’intérieur d’une interface de programmation d’application ou d’une API. REST s’en tient aux principes d’un contrat uniforme. Par conséquent, une interface REST est partagée via des connexions hypermédias.

5. Système en couches

Un système en couches utilise plusieurs couches indépendantes pour développer et étendre l’interface. Comme les couches ne peuvent pas se voir, de nouvelles requêtes et intergiciels peuvent être insérés qui n’auront pas d’impact sur les commandes initiales et le fonctionnement client-serveur.

6. Facultatif : Code à la demande

Alors que le client-serveur, la mise en cache, l’apatridie, le contrat uniforme et le système en couches sont indispensables pour les applications RESTful, le code à la demande n’est pas obligatoire. Cependant, Code-on-Demand permet à la logique des clients de rester indépendante et donc mise à jour séparément de la logique du serveur.

Fin des réflexions sur CRUD vs REST

CRUD implique les opérations essentielles effectuées dans le stockage de données statiques ou les bases de données, telles que la gestion d’enregistrements ou d’objets passifs. CRUD manipule essentiellement des données de base.

REST s’appuie sur la représentation des ressources via des URL uniques, où les ressources sont des abstractions d’objets, où le commentaire d’un utilisateur peut être une ressource, par exemple.

En tant que tel, REST implique plus qu’un enregistrement dans une table de commentaires. REST concerne la relation de l’enregistrement avec la ressource utilisateur et le message/commentaire auquel il est attaché. REST est un style d’API de très haut niveau qui interagit avec un système complexe.

---

Bien sûr, cet article n’était pas un tutoriel complet – puisqu’il faudrait vingt pages pour en écrire un. Mais faites-nous savoir si vous avez des questions ou si vous souhaitez voir un exemple spécifique étape par étape, et nous en créerons un pour vous.

Nous espérons que cela a été utile d’une certaine manière.

Merci pour la lecture!

Source photo: http://www.tyseo.net