El CMS más usado en la mayor parte de las webs disponibles en Internet es WordPress. Se trata de un sistema gestor de contenidos construído sobre PHP, muy orientado a la creación de blog, también llamados cuadernos de bitácora. No obstante, es un CMS para el que hay una gran cantidad de plugins y temas.
Con WordPress se pueden construir desde sencillos blogs,páginas corporativas, a tiendas online medianamente complejas o comunidades de usuarios orientadas a compartir contenidos redactados.
Es de muy fácil uso, y su adaptación para la mayoría de los casos se puede hacer mediante la instalación y configuración de plugins.
¡Hola de nuevo! En la programación hay que mantenerse al día, no nos podemos quedar estancados. Así que ya estoy por aquí de nuevo jugueteando con WordPress, poniéndome al día, para traer este howto. Hoy traigo este codekata para montar un sistema de administración para la información que quieras para WordPress.
Hoy traigo un pequeño howto o codekata, un resumen, sobre el sistema de plantillas para WordPress. En la documentación oficial está muy extendido. No he encontrado un resumen de todo esto, así que aquí estoy entonces compartiendo sobre este tema.
Este post es en parte continuación de un post anterior sobre cómo crear temas propios para WordPress. Más en concreto es el cómo trabajar los temas para estructurarlos. No hay que hacer grandes ficheros, si no ir dividiendo en pequeños problemas fáciles de resolver.
Este post resumen el cómo usar la función get_template_part() para seguir esas buenas prácticas recomendas por WordPress, dividir todo, para poder hacer después plantillas hijas del theme en curso. Al grano..
Dándole una vuelta de tuerca más a las optimizaciones para WordPress, podemos querer instalar también al gran Varnish para el cacheado de front, y así seguir rascando esos milisegundos en la velocidad de la web.
Este post es una continuación del post anterior sobre el cacheado de back, en este caso con un sistema de cacheado de front. Esto es un howto o tutorial para instalar Varnish, y una review de un plugin para WordPress que funciona muy bien, el Purge Varnish Cache.
WordPress trae una forma de almacenar la información peculiar, a base de metadatos. Traigo en este post el cómo empezar a usar estos Campos Personalizados, y una breve review de otra joya del software para WP, el Advanced Custom Fields, que amplía esta funcionalidad.
La mayoría de los items de información dentro de la base de datos de WordPress, se almacenan en unas pocas tablas.. la de los posts, comentarios, términos y usuarios. Cada una de estas tablas, tiene unas tablas anexas para los metadatos relacionados con cada elemento. Los posts tienen por ejemplo la tabla _posts y _postmeta.
Este es un pequeño howto para instalar Redis con WordPress, y así ponerle un turbo a la página web. Unos sencillos pasos y explicaciones de lo que es, como instalarlo en el servidor. Además, unas pocas instrucciones para enlazar todo con el plugin Redis Object Cache, una joya del software para WordPress ?
Siguiendo en la línea de las optimizaciones para WordPress, para mejorar el SEO, para disminuir el TTFB, que la web funcione ágil.. podemos llegar a esta optimización. Ésta se trata de una optimización de back, ya que se hace en la parte de la base de datos, aumentando la velocidad de las consultas.
En la incansable búsqueda por conseguir hacer que las cosas funcionen lo mejor posible, me he encontrado con un plugin que vengo a compartir en este post. Se trata un plugin que todo desarrollador de WordPress debería de conocer, el Query Monitor.
Es un plugin que una vez instalado te muestra detalladamente qué es lo que está pasando dentro de WordPress para poder depurar, mejorar todo y aumentar el rendimiento de la web. Es una manera de tener una visión global del funcionamiento, número de consultas a la base de datos, plantillas cargadas, tiempos, errores/notificaciones/advertencias en la programación, y un largo etcétera..
Automatizar la publicación de nuevas versiones es una técnica de desarrollo de aplicaciones que se denomina Despliegue Continuo o Continuous Deployment en inglés (CD). Se suele usar junto con el Continuous Integration (CI), en el que se elabora una serie de pruebas automáticas sobre el software.
Tener esto automatizado nos ahorra mucho tiempo, nos dará velocidad en todos estos pasos intermedios ya que no tendremos que repetirlos continuamente, y podremos centrarnos en desarrollar para cada iteración.
Durante las pruebas puede notificarnos en caso de errores, realizar todo tipo de chequeos, o elaborar documentación sobre el proyecto para el resto del equipo. Pero una vez que tenemos el primer paso montado del CI, es interesante seguir con el segundo paso del CD. A continuación comparto unos scripts e instrucciones para una web en WordPress, Symfony o Magento 2, con GitHub o BitBucket. Así es como funciona también aquí en JnjSite.com..
Dejo aquí otro pequeño codekata o howto sobre Gulp, en JavaScript, para preparar los directorios de publicación de un plugin para WordPress. La semana pasada publiqué lo mismo en Shell Script, pero como en JavaScript se puede hacer de todo, lo he transcrito para usar con Gulp. Así podemos automatizar el flujo de trabajo dentro de los otros flujos de trabajo Gulp. Así nos independizamos del sistema operativo y nos beneficiamos de los extras que nos trae Gulp con sus plugins, para hojas de estilo CSS, JavaScripts, tratamiento de imágenes, etcétera.
Simplemente genera una estructura de directorios bajo el directorio extra/ dentro del proyecto siguiendo el patrón de estructura propuesto para WordPress, a partir de un plugin en desarrollo bajo el directorio /wp-content/plugins/your-plugin-slug/. Es necesario tener instalado Nodejs, Gulp 4 por lo menos, y las dependencias necesarias. Al lanzarlo, si falta algo en tu sistema te lo dirá. En teoría es multiplataforma.
Ya estoy por aquí de nuevo compartiendo en este blog. Esta vez tienes un pequeño howto o codekata para crear un theme from scratch, desde 0 y sin ningún punto de partida, para WordPress. Vengo de nuevo escribiendo sobre WordPress, ya que últimamente estoy poniéndome al día con este CMS.
He estado construyendo un par de plugins, practicando mientras leía la documentación oficial. También me propuse crear un theme propio para jnjsite.com para conseguir aumentar la puntuación SEO, aunque lo estaba abandonando un poco. He estado trabajando en un Service Worker para que puedas visitar offline jnjsite.com, aumentar con este la puntuación SEO, y también para que puedas instalarte la web como si fuera una app de móvil. Si has estado viendo las últimas entradas en jnjsite.com habrás notado, que por esto, estoy escribiendo más alrededor de WordPress, frontend, JavaScript, SASS, etc..
Hoy vuelvo con otro howto o codekata para WordPress. Esta vez es para hacer una descarga de un fichero que no existe, a partir de una URL. Es decir, es una forma de generar contenido de un fichero al vuelo, en forma de fichero y darlo en descarga al navegador que visita WP. En vez de devolver contenido HTML, CSS y JavaScript desde el servidor al navegador que nos visita, devolvemos el contenido de un fichero y le decimos al navegador que nos visita que hay que descargar.
Para hacer esto es simple la idea. Sólo hay que engancharse a un hook de WordPress antes de que se devuelva ninguna respuesta web normal al navegador. Entonces, si la URL de la petición es la que queremos, entonces devolvemos el contenido del fichero, y ponemos los HEADERS en la respuesta para que el navegador se descargue el contenido en forma de fichero.
Hoy traigo un codekata o howto para el desarrollo de plugins para WordPress, con una funcionalidad que me ha entretenido bastante el conseguir que funcione. Se trata de una forma de actualizar las tablas de la base de datos, a medida que vamos actualizando un plugin, y vamos modificando también la estructura o contenidos de la base de datos. Es decir, es un pequeño howto o tutorial para mantener versiones de la estructura y contenido de la base de datos, para un plugin de WordPress.
Una persona me ha hecho una pregunta sobre WordPress. Curioseando para responder al comentario, inspeccionando las llamadas con el Monitor de Red, me he dado cuenta de una funcionalidad muy interesante que nos brinda WordPress. Resulta que tenemos disponible otra forma de desacoplar el frontend de una instalación WordPress, pero seguir disfrutando del backend de WordPress. Podemos programar con esto en mente, para trabajar la información usando llamadas AJAX que ataquen al CMS.
Rizando el rizo un poco, estas llamadas AJAX, incluso se podrían hacer desde otro tipo de programas que no fueran webs..
Es decir, tenemos un ‘endpoint’ con la ruta wp-admin/admin-ajax.php al que podemos atacar. Y a partir de este punto de entrada podemos crear plugins o themes, con lo que podemos programarle lo que queramos en la parte de backend. Por otro lado, en la parte de frontend, al atacar este endpoint podríamos así desacoplar más todo el frontend, y usar cualquier tecnología de frontend como podría ser Angular, React, Vue, etc.. o incluso otro tipo de programas de escritorio o aplicaciones nativas de móviles.