Construir una tienda online sin tener que lidiar con la falta de fiabilidad de WordPress

La pareja WordPress y WooCommerce han sido durante demasiado tiempo la solución favorita para desplegar rápidamente una tienda online y empezar a obtener ingresos. Ahora bien, todos los desarrolladores que se encontraron con WordPress conocen sus muchos inconvenientes. En este artículo, explicaremos cómo superamos la falta de fiabilidad de WordPress convirtiéndolo básicamente en un servicio de backend.



¿Primero de todo por qué WordPress es tan popular?

    • WordPress es fácil de implementar, hay un montón de soluciones de alojamiento que ofrecen WordPress directamente, pero también los alojamientos PHP siguen siendo muy comunes, es decir, wordpress.com, DreamHost, BlueHost, etc.

.

    • Hay muchos plugins disponibles, y también puedes desarrollar tu plugin.

.

    • Hay muchos temas de muy buen aspecto.

.

    • Es fácil de usar, sobre todo para personas no técnicas.
    • Se trata de un futuro de usar.
    • Tiene una gran comunidad y numerosos recursos de aprendizaje en línea.

.



Entonces, ¿cuál es el problema de WordPress?

.Su popularidad también trajo consigo debilidades:

  • Su enorme comunidad, compuesta en su mayoría por usuarios no técnicos, generó una enorme cantidad de recursos de aprendizaje no oficiales que están desactualizados o son de mala calidad.
  • Por ejemplo, el conocido como conocimiento de la cultura.
  • También atrajo a un montón de desarrolladores maliciosos y estafadores para hacer sus propios plugins contaminando el mercado de plugins.
  • Un montón de agujeros de seguridad también porque los usuarios de WordPress no suelen ser no técnicos y es probable que no apliquen parches de seguridad a su configuración.

En el aspecto técnico:

  • WordPress es demasiado flexible en el sentido de que para implementar algo se puede hacer en diferentes capas: en el código fuente PHP, en el editor de páginas/post de WordPress o en la configuración del tema. Esto lleva a los usuarios no técnicos a no adoptar convenciones claras y les permite probar diferentes trucos aquí y allá dando lugar a un uso muy hacky del CMS. <p< li=””> </p<>
  • Se trata de un problema de seguridad en el uso de la web.
  • WordPress también es poco fiable debido a la forma en que se realizan las actualizaciones, los plugins y los temas simplemente se sobrescriben perdiendo así cualquier cambio local (generalmente cambios a medida realizados para personalizar los plugins y los temas).
    Para ser precisos, WordPress tiene un sistema de temas hijo que permite definir los cambios que se aplicarán sobre un padre que ayuda a evitar que algunos de los cambios locales se sobrescriban. Pero no está bien integrado ni es fácil de usar.
    Para los webmasters, especialmente los amateurs, es demasiado arriesgado actualizar plugins, temas y el propio WordPress porque temen perder sus cambios y/o incluso romper todo su sitio web. De ahí que los sitios web de WordPress no se actualicen de facto nunca.



¿Cómo superar la falta de fiabilidad de WordPress?

Imaginemos que podemos usar WordPress y WooCommerce para lo que valen solamente que son un sistema de blog y un sistema de tienda online.
Lo primero que probablemente queramos hacer es eliminar los riesgos que suponen los plugins, y sólo instalar lo mínimo, WooCommerce.
Lo segundo que queremos hacer es deshacernos también de los temas. Para ello empezamos a mirar en Headless WordPress y descubrimos la API de WordPress y la API de WooCommerce.



API de WordPress

WordPress, desde su versión 4.7.0 (lanzada en diciembre de 2016), ofrece una API RESTful que viene a decir 13 años después de su primer lanzamiento en 2003 y hace tan solo 3 años del momento de la redacción de este artículo.

La API permite interactuar con WordPress utilizando únicamente el formato JSON (JavaScript Object Notation). Mientras que para solicitar datos de la misma, no requiere autenticación si se desea editar, crear o eliminar información será necesario autenticarse. Cabe destacar que WordPress sólo admite la autenticación de cookies de forma nativa, pero algunos plugins permiten más tipos.

El consumo de la API es bastante sencillo y permite recuperar cualquier dato con bastante facilidad. El endpoint raíz se monta en /wp-json/. Desde ahí podrás ver todos los sub-endpoints disponibles.
Pero vamos a profundizar en algunos ejemplos:



API de WooCommerce

WooCoomerce lleva más tiempo que WordPress ofreciendo una API RESTful a sus usuarios. La primera API de WooCommerce se lanzó con WooCommerce 2.1.0 en febrero de 2014, lo que supone casi tres años antes que la API REST de WordPress.

Su uso es más habitual. Por ejemplo, cuando configures tu logística con ShipBob ellos utilizarán la API para recuperar los pedidos de tu tienda automáticamente.

Es importante tener en cuenta que la API original de WooCommerce después de varias actualizaciones ha sido obsoleta y reetiquetada como Legacy API. WooCommerce decidió rehacer por completo su API para extender la de WordPress directamente después del lanzamiento de esta última.

Recomendamos utilizar la última versión que en el momento de escribir este artículo es la WooCommerce API v3 (no la Legacy sino la actual).

Cuando se utiliza la API ya sea la Legacy o la actual, es necesario crear primero un token de API en los ajustes de WooCommerce los pasos a seguir se describen aquí: https://docs.woocommerce.com/document/woocommerce-rest-api/

Después, para saber cómo utilizar los tokens para autenticarse, por favor, ve aquí: https://woocommerce.github.io/woocommerce-rest-api-docs/#authentication

Finalmente aquí hay algunos ejemplos:



El siguiente paso

Ahora que sabemos cómo utilizar la API de WordPress y la API de WooCommerce, hay dos cosas que debemos tener en cuenta:

    • La API de WooCommerce necesita autenticación, así que ¿cómo vamos a mantener nuestros tokens de la API en secreto?

.

  • Y al utilizar sólo la API, nos estamos desvinculando del proceso de pago de WooCommerce. Significa que tendremos que procesar los pagos nosotros mismos fuera de WordPress/WooCommerce.

Esto es por lo que nos decantamos por la arquitectura siguiente:

    • El front-end está ejecutando una app Angular escrita en Typescript.

.

    • El middleware es una app Node.js escrita en Typescript, guarda los tokens de la API e implementa lo necesario para procesar los pagos también, por ejemplo, solemos implementar Stripe y GloBee.

.

    • El back-end y el back-office es nuestro WordPress.

.

  • El CDN y el almacenamiento se ejecutan respectivamente en AWS CloudFront y AWS S3.

Significa que con esa arquitectura cuando queramos:

    • Para alojar una imagen, simplemente la subimos a WordPress media, y la recuperamos con el enlace CDN,

.

    • Para hacer algunos cambios en algunas partes de nuestro sitio web, editamos una página de WordPress y recuperamos el contenido de la página dinámicamente a través de la API de WordPress a través de nuestro middleware,

.

    • Para añadir un producto, simplemente lo añadimos en WooCommerce,

.

.

Nótese que para automatizar la subida de los medios a S3 en WordPress instalamos el plugin WP Offload Media Lite. Haciendo el recuento total de nuestros plugins instalados en WordPress a sólo dos: WooCommerce y WP Offload Media Lite.



Dificultades encontradas

  • La API de WordPress es lenta:
    https://stackoverflow.com/questions/45421976/wordpress-rest-api-slow-response-time/45425091#45425091
    Aunque un plugin parece ayudar a ello, al almacenar en caché las respuestas de la API:
    https://wordpress.org/plugins/wp-rest-cache/ (Todavía no lo hemos probado).
  • Para mantener WordPress totalmente oculto detrás de nuestro middleware (y evitar ojos curiosos), hemos tenido que filtrar todos los enlaces devueltos por WordPress para asegurarnos de que o bien utilizan el CDN, o bien utilizan un dominio vetado, o simplemente no aparecen en las respuestas de las llamadas a la API. Para ello, el plugin WP Offload Media Lite ayuda mucho porque actualiza cada enlace multimedia para que utilice el CDN.
  • Por favor, no te preocupes, no te preocupes, no te preocupes, no te preocupes.



Pensamientos finales

Para la empresa en la que trabajo, poder personalizar completamente el front-end como queramos, a la vez que mantenemos nuestra web más segura es una gran victoria para nosotros. Es cierto que las necesidades de infraestructura son mayores, pero la mantenibilidad y estabilidad a largo plazo son mayores.

Categorías : # wordpress

Deja una respuesta

Tu dirección de correo electrónico no será publicada.