Este artículo sobre la creación de un sistema CRUD en WordPress se publicó en 2014. Sin embargo, notamos que este tema se volvió aún más actual, por lo que decidimos darle una nueva mirada.

¿Qué es un sistema CRUD, cómo integrar un sistema CRUD para MySQL en su sitio de WordPress, cuáles son las ventajas y desventajas de usar diferentes enfoques?

¿Qué es un sistema CRUD?

La abreviatura CRUD proviene de Crear, Leer, Actualizar, Eliminar. Lo que, en otras palabras, significa un sistema de gestión de datos. En la web, lo más probable es que signifique una pieza de software que administra las entradas en su base de datos. Por lo general, se refiere a MySQL, PostgreSQL, MS SQL u otros motores de base de datos.

Un excelente y, quizás, el ejemplo más popular de un sistema CRUD es phpMyAdmin. PHPMyAdmin es una herramienta que utilizan casi todos los desarrolladores web para administrar datos MySQL en línea. Se difundió tanto que actualmente puede llamarse una herramienta estándar para administrar bases de datos MySQL. Hoy en día viene preinstalado en casi cualquier herramienta CPanel de los proveedores de hosting.

Hay miles de casos de uso estándar para los sistemas CRUD. Por ejemplo, casi cualquier catálogo, registro de entrada, información estadística. Básicamente, cualquier cosa relacionada con el almacenamiento de información requeriría agregar, modificar y eliminar bits de información. Ahí es cuando entran en juego los sistemas CRUD.

¿Por qué necesitarías un sistema CRUD en WordPress?

WordPress en sí mismo es un potente CMS (Sistema de gestión de contenido), que también es un caso especial del sistema CRUD. Como sabe, los usuarios del sitio de WordPress pueden agregar publicaciones y páginas, editarlas o eliminarlas. Pero a veces se encuentra con una situación en la que necesita administrar algunos datos de la base de datos directamente desde el front-end de WordPress, que generalmente no se publica ni está relacionado con la página y no encaja bien en las taxonomías de WordPress. Entre otras puede ser una de estas situaciones en las que necesitarías un sistema CRUD independiente en WordPress:

Le gustaría tener un rastreador de errores, un registro de entrada o alguna otra herramienta de entrada de datos en su sitio de WordPress;
O, por ejemplo, desea permitir que algunos de los usuarios editen algunos datos relacionados con el negocio desde el front-end de su sitio sin proporcionarles acceso al panel de administración del sitio de WordPress, o tal vez incluso sin revelar el hecho de que el sitio se ejecuta en WordPress;
Otro ejemplo es un requisito para permitir que algunos usuarios editen una tabla de base de datos. Por ejemplo, modificar un pedido realizado, editar algunos datos personales, etc.

Y solicitudes similares.

¿Cómo integrar un sistema CRUD en un sitio de WordPress?

La solución más fácil: intente encontrar un complemento adecuado

Primero, asegúrese de que realmente necesita uno. Muchas de las tareas no son únicas y probablemente pueda encontrar un complemento que se adapte a sus necesidades. Por ejemplo, si necesita un rastreador de errores, como se mencionó anteriormente, puede verificar y descargar este o este.

Y si necesita algo más genérico, como editar diferentes tablas MySQL desde el front-end de WordPress, pruebe nuestro complemento wpDataTables, que es básicamente un sistema CRUD en WordPress. Puedes ver la lista de características y ejemplos de cómo funciona aquí. O incluso pruebe una versión Lite gratuita en el repositorio de complementos de WordPress.

Vale la pena señalar que wpDataTables no impone ninguna limitación en la estructura de datos, la cantidad de columnas o filas, admite muchos tipos de datos y diferentes tipos de entrada del editor. Por ejemplo, algunos tipos específicos como archivos adjuntos o DateTime. Además, permite editar datos a través de un editor de formularios emergentes, con un editor en línea o incluso con un editor de hojas de cálculo tipo Excel.

Si aún siente que necesita crear un sistema CRUD personalizado en WordPress, debe prepararse para una codificación seria para hacerlo.

Inicie un nuevo complemento de WordPress

Si crees que ningún plugin se ajusta a tus necesidades, ¡crea el tuyo propio! Puede que no sea tan aterrador como parece a primera vista. Comience leyendo este buen tutorial sobre cómo crear un complemento de WordPress desde cero. Y también, por supuesto, este en WordPress Codex.

El primer paso inicial cuando crea cualquier complemento, incluido un sistema CRUD en un complemento de WordPress, es estructurar los archivos correctamente.
El enfoque habitual es colocar el archivo de punto CRUD de entrada principal en el directorio raíz del complemento y preparar varias subcarpetas:

Activos: todos los javascript, hojas de estilo, fuentes, imágenes y otros activos estáticos que serán necesarios para su sistema CRUD;
Fuente: carpeta para las clases PHP "básicas" que realizarán toda la funcionalidad CRUD en el back-end;
Lib: carpeta para cualquier componente de terceros que desee utilizar en su sistema CRUD;
Plantillas: carpeta para plantillas HTML que serán la interfaz de usuario para su sistema CRUD.

Puede haber más (controladores, manejadores de código abreviado y otros), pero eso es lo mínimo para empezar.

Crear back-end del editor (clases PHP)

En primer lugar, necesitaría la parte de back-end: un script PHP que realmente haría los trabajos CRUD. Para esto, necesitaría conectarlo con WordPress DB (objeto global $wpdb). Puede leer un buen tutorial aquí sobre el uso de la base de datos de WordPress y el objeto $wpdb en sus complementos.

Si usa una base de datos externa, necesitará, por ejemplo, usar una conexión PDO separada, o simplemente funciones incorporadas de PHP MySQLi (si su motor de base de datos es MySQL).

Su tarea en este paso es preparar un conjunto de clases y métodos que aceptarán datos del front-end en alguna forma esperada, validarlos y desinfectarlos (desinfectar todas las entradas es una medida de seguridad muy importante para todos los sistemas CRUD) y realizar las acciones INSERTAR, ACTUALIZAR y ELIMINAR en su base de datos.

Como se describió en el paso anterior, estos archivos "básicos" pertenecerían a la carpeta "fuente" de su nuevo complemento CRUD de WordPress.

Crear una interfaz de usuario (HTML, JS, PHP)

Cuando las clases y los métodos de administración de la base de datos estén preparados, su complemento necesitará una interfaz frontal para que el usuario use su nuevo sistema CRUD en WordPress. La mejor solución sería preparar un conjunto de plantillas en sus nuevos archivos de complemento y enviarlo donde lo necesite con un código abreviado.

Tiene sentido mantener siempre las plantillas HTML separadas del código (enfoque MVC) y preparar archivos de plantilla lógicamente separados, por ejemplo: "edit.tpl.php", "delete.tpl.php", "list.tpl.php". ", etc. – una plantilla para cada página o acción CRUD.

Aquí puede leer un excelente artículo del códice sobre la API de código abreviado de WordPress.

Conecte el front-end con el back-end con llamadas AJAX (JS)

Por supuesto, puede hacerlo al "estilo de la vieja escuela", con envíos de formularios simples y recarga de página. Sin embargo, hoy en día ya no es un enfoque común. En cambio, usar AJAX es un enfoque estándar, ya sea a través de jQuery u otras bibliotecas como Angular. Por lo tanto, nuestra recomendación es tomarse un tiempo y considerar el uso de AJAX en sus complementos de WordPress. Aquí hay un excelente artículo de Codex sobre cómo usar AJAX en sus complementos, tanto en el lado administrativo como en el front-end.

Puede colocar el código JS en la carpeta de "activos" que preparó en el primer paso.

Probar, refinar y depurar

Cuando termine la parte de implementación, tómese un tiempo y pruebe su nuevo sistema CRUD en WordPress. No puede detectar todos los errores desde el principio, pero repetir las acciones de rutina CRUD varias veces con diferentes ejemplos (casos "extremos" preferibles, por ejemplo, cantidades muy grandes de datos, hacer clic varias veces en el mismo botón, etc.) siempre lo ayudará. para detectar la mayoría de los errores, y estos siempre ocurren cuando implementa algo nuevo.

CRUD vs REST: ¿Cuál es la diferencia?

REST es un estilo arquitectónico de creación de aplicaciones en red basado en un protocolo de comunicación cliente-servidor, sin estado y almacenable en caché, es decir, el protocolo HTTP. CRUD es un acrónimo de CREAR, LEER, ACTUALIZAR y ELIMINAR, las funciones básicas de almacenamiento persistente en programación.

Las operaciones CRUD, es decir, CREAR, LEER, ACTUALIZAR, ELIMINAR, son similares a los comandos básicos REST, es decir, GET, PUT, POST, DELETE, lo que genera confusión entre los dos. ¿Qué es CRUD? ¿Qué es REST? En CRUD vs REST, ¿cuál es la definición de CRUD? ¿Es REST una mera copia al carbón de CRUD?

¡Todas estas son preguntas muy pertinentes que este artículo pretende responder en detalle!

¿Cómo funciona REST?

No puede comprender términos como API REST, servicios REST, matriz CRUD o base de datos CRUD o programación REST si no comprende la diferencia entre los dos procesos en cuanto a la forma en que funcionan. La confusión desaparecerá una vez que sepas esta diferencia.

Puede trabajar con REST en cualquier recurso, ya sea un archivo multimedia, un documento, un sitio web, etc. No hay restricciones en cuanto a lo que puede trabajar con REST; puede usar HTML solo como protocolo de comunicación para señalar los recursos. REST significa Transferencia de Estado Representacional.

REST indica que allí cada URL distintiva representa algún objeto, al que puede acceder a través de HTTP GET, así como modificarlo y eliminarlo a través de HTTP POST, PUT o DELETE.

¿Cómo funciona CRUD?

Solo puede aplicar CRUD en los registros de la base de datos y no puede crear API CRUD como crea API REST. La aplicación CRUD está restringida a bases de datos, por lo que CRUD, a diferencia de REST, no es un estilo de arquitectura, sino un ciclo. Las aplicaciones y los sitios web contienen diferentes ciclos CRUD.

Por ejemplo, un visitante en un sitio web de comercio electrónico puede CREAR una cuenta, ACTUALIZAR la cuenta, LEER la información y ELIMINAR la cuenta. Ese es un ciclo CRUD completo que incluye cada operación CRUD.

Por ejemplo, en el mismo sitio web de comercio electrónico, un visitante puede CREAR un artículo en el carrito electrónico y luego completar el ciclo CRUD completo al LEER, ACTUALIZAR e incluso ELIMINAR el artículo.

La Fundación y los Principios de REST

Los comandos básicos de la transferencia de estado representacional, el acrónimo REST, giran en torno a un objeto o recurso, que puede describirse como cualquier cosa que pueda revelar mediante el protocolo HTTP. Ejemplos de recursos REST: imagen, sitio web, documento, servicio. El cielo es el limite.

REST es una interfaz de programación de aplicaciones, o API, o una arquitectura destinada a multimedia distribuida. Una API es un servicio web que sigue los principios de la arquitectura REST. Por lo tanto, REST llama a cada API a través de uno de los métodos de solicitud HTTP, GET, PUT, POST y DELETE.

Los seis principios rectores de la arquitectura RESTful

Mandato Cliente-Servidor

El mandato cliente-servidor enfatiza el hecho de que REST representa un método distribuido que se basa en la naturaleza de la separación cliente-servidor. Un servicio REST implica varias capacidades y atiende solicitudes. El cliente realiza las solicitudes y el servidor las acepta o deniega.

apatridia

La apatridia restringe el tipo de solicitudes que se pueden enviar entre el consumidor y el servidor. En efecto, es la solicitud la que inicia la comunicación entre el cliente y el servicio, donde la solicitud contiene toda la información necesaria para que el servidor responda.

almacenamiento en caché

El propósito de almacenar en caché una solicitud nunca es tener que enviar la misma solicitud dos veces porque el almacenamiento en caché le indica al servidor que etiquete las respuestas como almacenables en caché o no. Como resultado, el almacenamiento en caché reduce las limitaciones o restricciones generadas por la apatridia.

Contrato Uniforme

El Contrato Uniforme excluye el uso de varias interfaces independientes dentro de una Interfaz de Programación de Aplicaciones o API. REST se adhiere a los principios de un Contrato Uniforme. Por lo tanto, una interfaz REST se comparte a través de conexiones hipermedia.

Sistema en capas

Un sistema en capas emplea varias capas independientes para desarrollar y ampliar la interfaz. Como las capas no pueden verse entre sí, se pueden insertar nuevas solicitudes y middleware que no tendrán un impacto en los comandos iniciales y el funcionamiento del cliente-servidor.

Opcional: código bajo demanda

Si bien Cliente-Servidor, Almacenamiento en caché, Apatridia, Contrato uniforme y Sistema en capas son imprescindibles para las aplicaciones RESTful, Code-On-Demand no es obligatorio. Sin embargo, Code-on-Demand permite que la lógica dentro de los clientes permanezca independiente y, por lo tanto, se actualice por separado de la lógica del servidor.

Pensamientos finales sobre CRUD vs REST

CRUD implica las operaciones esenciales realizadas en el almacenamiento de datos estáticos o bases de datos, como el manejo de registros u objetos pasivos. CRUD esencialmente manipula datos básicos.

REST se basa en la representación de recursos a través de URL únicas, donde los recursos son abstracciones de objetos, donde el comentario de un usuario puede ser un recurso, por ejemplo.

Como tal, REST implica más que un registro en una tabla de comentarios. REST se trata de la relación del registro con el recurso del usuario y la publicación/comentario al que está adjunto. REST es un estilo de API de muy alto nivel que interactúa con un sistema complejo.

Por supuesto, este artículo no era un tutorial completo, ya que se necesitarían veinte páginas para escribir uno. Pero háganos saber si tiene alguna pregunta o le gustaría ver un ejemplo específico paso a paso, y crearemos uno para usted.

Esperamos que haya sido útil de alguna manera.

¡Gracias por leer!

Fuente de la imagen: http://www.tyseo.net

Fuente de grabación: wpdatatables.com