wordpress

WordPress: No uses camelCase para tus shortcodes

Deja un comentario

En breve: no utilices camelCase para nombres de parámetros en los shortcodes de WordPress

He estado un rato dado vueltas a un código de shortcode que estaba haciendo. Quería inyectarle un contenido para que lo usara como una propo de schema para mejorar la semántica del código. Esa prop usaba camelCase y decidí que el parámetro llevase el mismo nombre para no liarme… pero cuando capturaba el recogía el parámetro me aparacía con el valor por defecto.

function shortcode_process($atts) {
	$atts = shortcode_atts( array(
		0 => null,
		'name' => null,
		'price' => null,
		'priceCurrency' => null,
	), $atts );
}

Y es que no sabía que los atributos del shortcode de WordPress se pasan a través de la función strtolower() de PHP.

Es raro que use camelCase en PHP, suelo usar snake_case (aunque últiamente en javascript uso camelCase), pero aquí quería usar el mismo nombre que la prop, y Schema.org marca las props en camelCase. Ha sido un rato rascándome las neuronas intentando averiguar si porqué un parámetro estaba pasando correctamente y el otro se quedaba con el valor por defecto, hasta que finalmente he pensado ¿y si es por el casing?

function shortcode_process($atts) {
	$atts = shortcode_atts( array(
		0 => null,
		'name' => null,
		'price' => null,
		'pricecurrency' => null,
	), $atts );
}

Y así era, resulta que los parámetros estaban siendo ignorados porque ya no coincidían con los nombres esperados después de ser convertidos a minúsculas por la función strtolower() antes mencionada.

Así que aquí te dejo la pista para que no pierdas el tiempo que he perdido. Utiliza nombres de propiedads en minúsculas/snake_case en el array shortcode_atts().

js, tips

Chrome dev tools: Como explorar un JSON

Deja un comentario

Si te dedicas al mundo del frontend, seguramente tienes que estar consultando un API REST que te devuelve documentos en formato JSON y en ocasiones querrás comprobar que lo que recibes es lo que esperar y poder explorarlo. Vamos a a ver un par de trucos para atacar rápidamente un JSON gigante usando las Developer Tools del navegador Google Chrome (o Chromium) y facilitarte la vida.

Truco 1: Cargar en el terminal

La consola de las Developer Tools no es solo l lugar donde probar el código, también podemos hacernos.

Con las DevTools abiertas, en la pestaña Network, realizamos la petición al API REST. Entonces abriremos el documento que hemos recibido y nos iremos a la pestaña preview y veremos el JSON en todo su esplendor. Entonces, seleccionando el elemento raíz, abrimos el menú contextual (botón derecho) y elegimos «Store to global variable».

Desde ese momento tendremos una variable (en mi caso fue temp1) con la que podremos trabajar en el terminal. Podremos hacer operaciones de array o de objeto sobre sus elementos y usar el autocompletado para hacer todo el path. Si escribimos el path y damos intro recibiremos el valor de ese elemento en el árbol JSON.

Truco 2: Extraer el path a un elemento

Un caso bastante habitual es tener un elemento bastante profundo en el árbol JSON y no querer tener problemas de erratas al transcribirlo. Puedes sacar el menú contextual del elemento y

Y puedes comprobar que está correctamente escibiendo en la consola:

temp1.PATH_COPIADO

Bola Extra: Una extensión para ver JSON.

Si no quieres tener que hacer el recorrido hasta las dev tools, y quieres ver directamente el JSON al llamar a su url en el navegador de una manera manejable, te recomiendo instalar JSON Formatter.

Truco: puedes expandir y contraer ramas pulsando ctrl para que lo haga con todas las del mismo nivel.

linux

Variables de entorno por carpeta de proyecto

Deja un comentario

Tenemos un proyecto que necesitamos que tenga una serie de variables de entorno. En producción no hay problema, porque cada máquina es específica para cda proyecto y tiene sus varaibles de entorno. Pero en el entorno de desarrollo podemos tener más de un proyecto en marcha y puede que ciertas variables se repitan o pisen entre proyectos. Entonces lo que necesitamos son variables de entorno por proyecto.

Una solución maravillosamente sencilla es tener un fichero de variables de entorno que se cargue al entrar en esa carpeta. Tendrá el mismo formato que nuestro clásico .bashrc. Para ello habrá que instalar el programa direnv (y que se cargue en nuestro .bashrc).

sudo apt-get install direnv && echo "eval "$(direnv hook bash)"" >> ~/.bashrc

Y en la carpeta raíz de cada proyecto tener un fichero .envrc con las variables de entorno que necesitamos.

.gitignore global

Por limpieza, lo ideal es que este (y otros ficheros propios de nuestra máquina de desarrollo) no estén ensuciando el .gitignore particular de cada proyecto. Así que para ignorar este fichero particular del control de versiones para cada proyecto (pero solo de nuestra máquina), en lugar de ignorarlo a nivel de proyecto podemos ignorarlos a nivel global. Para ello usaremos el comando:

git config --global core.excludesfile ~/.gitignore

Al añadir un fichero .gitignore a nuestra carpeta de usuario y añadir los ficheros «.envrc».

Bola Extra: dotenv

Idealmente, en muchos proyectos javascript utilizo dotenv. Una librería que añade variables de entorno en tiempo de ejecución. Si tu proyecto no es javascript o no usa dotenv, aquí tienes otra solución.

git

Poner bonito tu perfil en Github con el README.md

Deja un comentario

Si estás metido en el mundo de la programación seguro que usas GIT como sistema de control de versiones, y la manera más cómoda de poner tener un repositorio online es usar sitios como Github (puedes tener ilimitados repositorios gratuitos si son públicos, pero tendrás que pagar si quieres tener repositorios privados), Gitlab o BitBucket. Recordemos que Github es propiead de Microsoft, aún así el código será de tu autoría y se respetará la licencia que desees compartirlo.

GitHub se ha convertido en una plataforma esencial para desarrolladores y profesionales de la programación, y tu perfil en esta plataforma es tu carta de presentación ante la comunidad. Una forma de destacar y presentarte de manera atractiva es a través de la creación de un archivo README en tu perfil de GitHub. Vamos a ver lo fácil que resulta poner bonito tu perfil de GitHub utilizando el archivo readme.md.

¿Qué es un archivo README?

Un archivo README es un archivo de texto en formato Markdown (extensión .md) que se utiliza comúnmente en proyectos de software para proporcionar información sobre el proyecto, instrucciones de instalación, documentación y otros detalles relevantes. Sin embargo, en el contexto de tu perfil de GitHub, el archivo README te permitirá compartir información sobre ti mismo con la comunidad.

Paso 1: Crear un repositorio para tu perfil

Para empezar, debes crear un repositorio con el mismo nombre que tu usuario en github. En mi caso queda algo como github.com/yondemon/yondemon. Si aún no tienes un repositorio, puedes crear uno en la web haciendo clic en el botón «+» y seleccionando «New Repository». Al usar la interfaz web ya te avisará que este es un repositorio especial que usarán para tu perfil.

Paso 2: Crear el archivo README

Ahora, debes crear un archivo con el nombre «README.md» en tu repositorio de GitHub. Atención: En el propio proceso de creación del repositorio puedes decirle que cree ya este archivo, en otros repositorios te lo rellenará con la estructura habitual de un fichero README de un proyecto, pero en este repositorio te pondrá un mensaje breve y oculto recomendaciones de texto.

Paso 3: Estructurar tu perfil README

El archivo README.md utiliza el formato Markdown para dar estilo al texto y agregar elementos como títulos, listas, enlaces e imágenes. Todo ello solamente con texto y un marcado especial a base de símbolos especiales como parénteis, corchetes y almohadillas, entre otros. Puedes utilizar una combinación de texto, imágenes y enlaces para crear una presentación visualmente atractiva de tu perfil.

Puede ser interesante incluir algunas de estas secciones en tu perfil README:

  1. «Acerca de mí»: En esta sección, puedes describir tu trabajo, intereses y experiencia en el campo de la programación. Puedes hablar sobre los lenguajes de programación que dominas, tus proyectos anteriores o cualquier otro detalle relevante que desees compartir. También puedes poner enlaces a redes sociales o foros donde pueden encontrarte.
  2. «Contribuciones destacadas»: Aquí puedes resaltar algunos de tus proyectos o contribuciones en los que te sientas orgulloso. Proporciona un breve contexto sobre cada contribución, explicando para que sirven, y por qué son significativas.
  3. «Guía para obtener ayuda»: Si estás involucrado en comunidades de programación o tienes experiencia en algún tema en particular, puedes incluir enlaces y recursos para que otros desarrolladores puedan obtener ayuda en esas comunidades.

Paso 5: Utilizar elementos de estilo y formato

Como comentaba antes, además de la estructura básica del archivo README, puedes utilizar elementos de estilo y formato para hacer que tu perfil sea más atractivo visualmente. Algunas opciones que puedes considerar incluyen:

  • Utilizar encabezados de diferentes niveles (usando #) para organizar el contenido y resaltar las secciones principales.
  • Utilizar listas con viñetas o numeradas para resumir tus habilidades o logros destacados.
  • Agregar enlaces a tu perfil de redes sociales o a otros proyectos relevantes.
  • Incorporar imágenes y capturas de pantalla relevantes para ilustrar tus proyectos o logros. (Puedes subir las imágenes al mismo repositorio).

La presentación de tu perfil de GitHub es una oportunidad para mostrar tu personalidad y habilidades a la comunidad. Experimenta con diferentes estilos y formatos para encontrar el que mejor se adapte a ti. Poner bonito tu perfil de GitHub utilizando el archivo readme.md es una excelente manera de presentarte de manera atractiva ante la comunidad de desarrolladores y el mundo en general. Aprovecha esta oportunidad para compartir información relevante sobre ti, destacar tus contribuciones y proporcionar recursos útiles. ¡Haz que tu perfil sea único y representativo de tu trabajo y pasión por la programación!

Mas información en «Github: Managing your profile README»

css

HTML: ¿Conoces el tag «METER» ?

Deja un comentario

Atentos a esta maravilla. La etiqueta <meter> (soportada por todos los navegadores) podemos describir de manera semántica cualquier cosa que se está midiendo: el estado de algo, un resultado; y el navegador lo mostrará de manera gráfica.

Con este código de Sven Wolfermann, podemos darle el estilo que queramos gracias al poder de manejar elementos gráficos en SVG y adaptarlo al típico caso de mostrar una reseña con estrellas.

Código: https://codepen.io/maddesigns/details/oQoMre/

css, tips

[WebDevTip] Forzar el refresco de CSS (y javascripts) cacheados

Deja un comentario

[Vía: Force CSS changes to “go live” immediately | Mark on WordPress]

TL;DR Un sencillo truco, cada vez que se actualiza el fichero, se le añade su fecha detrás de la interrogación. Este parametro GET no se utiliza para nada, pero al cambiar la URL el navegador no la tiene cacheada y deber refrescar ese contenido. Mientras no se cambie el fichero la URL no cambiará.

Cuando actualizas el archivo style.css de tu tema de WordPress, es posible que hayas notado que tienes que «forzar la recarga» de tu sitio en el navegador para ver los cambios. Esto se debe a que el navegador guarda una copia del CSS en caché en tu disco duro. Dependiendo de cómo esté configurado tu servidor, es posible que no verifique una nueva versión de la hoja de estilos durante un par de horas o incluso más tiempo. Incluso si fuerzas la recarga para ver los cambios, los visitantes que hayan accedido previamente a tu sitio aún podrían obtener la versión anterior del CSS. Una forma de solucionar esto es «versionar» tu archivo CSS, agregando ?v=123 al URL en el elemento de tu hoja de estilos. Sin embargo, hacer esto manualmente cada vez puede resultar tedioso, por lo que aquí te presento una manera mucho mejor de hacerlo:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); echo '?' . filemtime( get_stylesheet_directory() . '/style.css'); ?>" type="text/css" media="screen, projection" />

Con este código, se actualizará automáticamente la parte final ?12345678 cada vez que modifiques el archivo. ¡Boom! Ahora todos verán instantáneamente tus cambios.

Explicación del código

El código utiliza la función filemtime() para obtener la fecha de modificación del archivo style.css. Luego, se agrega esta información al URL del enlace a la hoja de estilos mediante echo '?' . filemtime( get_stylesheet_directory() . '/style.css'). Al hacerlo, se crea un nuevo valor después del signo de interrogación que cambia cada vez que se realiza una modificación en el archivo CSS.

De esta manera, cuando actualices el archivo style.css, el URL de la hoja de estilos cambiará automáticamente y el navegador del usuario solicitará la nueva versión en lugar de usar la versión en caché.

Beneficios de forzar el refresco del CSS

Al versionar el archivo CSS de esta manera, garantizas que los cambios realizados se muestren instantáneamente a los visitantes de tu sitio web. Ya no tendrás que preocuparte por los usuarios que siguen viendo la versión anterior del CSS debido a la caché del navegador. Además, si trabajas en colaboración con otros desarrolladores o si tienes un equipo de mantenimiento de tu sitio web, todos podrán ver rápidamente las actualizaciones realizadas sin tener que realizar acciones adicionales.

Forzar el refresco del CSS es una técnica muy útil para asegurarte de que los cambios que realizas en tu hoja de estilos se reflejen inmediatamente en tu sitio web. Mediante el versionado automático del archivo CSS, te aseguras de que los visitantes vean siempre la última versión y evitas problemas causados por la caché del navegador. ¡Utiliza este método y olvídate de las dificultades para ver tus cambios en tiempo real!

Sin categoría

HTML: ¿Como tacho? «Strike» vs «Del» vs «S»

Deja un comentario

A estas alturas, tenemos claro que presentación y contenido debería estar separados cuando realizamos una web. Que el HTML es el contenido y que el CSS es la manera de presentar, y que podríamos entender el contenido sin el CSS.

Quizá alguna parte de nuestro texto tenga un texto que se eliminó en el pasado pero que queremos que se mantenga para que una persona que venga después pueda leerlo, o algo que no es válido y, aunque se muestra, se muestra como erróneo. En la especificaciones de HTML 3.2 se planteó el uso de strike, pero pensando en que se eliminaría en favor de s, con al representación visual de una línea que tacha el texto. Finalmente este elemento se retiró en HTML 4 y XML 1.0 y se declaró obsoleto en HTML5.

Entonces ¿como tacho? Pues si estamos indicando que es un elemento que fue escrito en el pasado pero borrado, deberemos usar del, que además permite añadir un atributo datetime con la marca temporal del momento en que fue eliminado. Con esto decimos que el elemento ya no es importante para el contenido actual, pero que lo mantenemos por razones de consulta (para poder ver los cambios).

Sin embargo para mostrar un texto que sería incorrecto antes de algo correcto es recomendable usar s. Un ejemplo de caso de uso donde utilizo s es para indicar dos precios, el normal y el oferta, el primero no se ha retirado, pero tiene prevalencia la oferta.

Otra opción es usar la propiedad CSS text-decoration: line-through; que marcará con un tachado el texto, pero entonces no estaremos indicado semánticamente nada. Y en tal caso tendremos que apoyarnos en otra etiqueta, pero en ningún caso usaría un em para tachar algo, ya que para mi s, es un anti-em: lo que viene a continuación es importante, pero esto es a lo que no tienes que mirar. Por cierto, el opuesto a del, es ins, que marca un texto que se ha introducido posteriormente.

Sin categoría

Gamevelopers y otras hierbas…

Deja un comentario

Soy feliz organizando Betabeers, los encuentros de desarrolladores que trabajan programando en startups y que quieren compartir sus tribulaciones. Y en la historia de Betabeers lo que mas me sorprendió es que en otras ciudades también han ido surgiendo nuevos Betabeers, pero de manera espontánea. Me refiero a que allí podían haber montado otros encuentros informales de desarrolladores, pero sin embargo cuando alguien ha querido montar uno nuevo, nos ha llamado, le ha puesto la misma marca y el mismo formato. Nosotros hemos pedido muy poco a cambio, seguir las (flexibles) directrices del formato, usar Betabeers.com para anunciarlo y tener algo de constancia.

Mientras, en el cercano terreno de los desarrolladores de videojuegos, noto que hay movimiento, pero el movimiento es desestructurado. Surgen distintas propuestas, pero cada una tiene unas cabezas diferentes al frente y me hace dudar de si se conocen o no quieren conocerse…
Seguir leyendo Gamevelopers y otras hierbas… →