Para los que manejáis WooCommerce es muy posible que no sólo utilicéis este metaplugin de WordPress para llevar a cabo ciertas tareas en vuestra tienda, sino que hagáis uso de otros plugins para añadir cierta funcionalidad. Por cierto, recordaros que WooCommerce es un plugin para montar tiendas sobre WordPress, y lo tenemos incluido en la lista de los mejores plugins para profesionales WordPress.
Pues bien, cuando hacemos uso de estas extensiones y son las propias de WooThemes (que el nombre no os confunda, esta empresa empezó haciendo temas y luego ya era tarde para cambiar el dominio raíz) nos aparece un mensaje bastante peleón que no podemos descartar (el clásico botón de “dismiss” para que no vuelva a aparecer no está) ¿Qué hacer? A mi personalmente no me gustan estos mensajes tan contaminantes, parece que nos estén obligando a realizar la acción, y ese tipo de checkers lo único que hacen es sobrecargar nuestra web de consultas a servidores externos nuestros.
Cuando desarrollo plugins y themes para WordPress en CODECTION siempre procuro mirar por la seguridad, “sanitizando” variables tanto para evitar ataques vía inyección SQL como para evitar ataques XSS. Es muy frecuente, que si recibes peticiones y luego las devuelves por pantalla, las variables que manejes, si las maneja el usuario de alguna manera, puedan terminar siendo el origen de una ataque XSS.
Algo tan sencillo como pasar una etiqueta script o iframe en un sitio conveniente y además de un ataque XSS, eres una fuente de phising para el resto de la red. Por fortuna, WordPress facilita mucho la vida al desarrollador al respecto y para evitar este tipo de ataques nos ofrece una función que además es extensible en su funcionamiento vía parámetros.
La función en cuestión es wp_kses() y aunque es similar a strip_tags(), una función nativa de PHP, suele recomendarse para cuestiones de seguridad.
¿Para qué usamos wp_kses?
Básicamente deciros que sirve para limpiar una cadena de elementos HTML indeseados (imaginad otros usos que no sea el de seguridad, se me viene a la cabeza un uso de “limpieza” de una cadena proveniente de Microsft Word o LibreOffice Write).
Tiene esta forma:
wp_kses($string, $allowed_html, $allowed_protocols);
Y los parámetros que recibe indican exactamente:
La función devolverá el código HTML totalmente limpiado.
El segundo parámetro es interesante, porque podemos definir también qué atributos pasarán de cada etiqueta, un ejemplo curioso:
array(
'a' => array(
'href' => array(),
'title' => array()
),
'br' => array(),
'em' => array(),
'strong' => array(),
);Ejemplo
El ejemplo es original de Simon Wheatly. Tenemos de entrada:
Wisi <a href=”#” style=”color: red;”>defui nunc</a> dignissim <strong class=”weird”>transverbero ideo vel</strong> utinam blandit, iaceo meus epulae enim amet nibh sed brevitas. Pala consequat <script type=”text/javascript” src=”http://example.com/certainly/do/not/want/this.js”></script> capio sino regula typicus <small>luptatum</small> olim ullamcorper uxor in verto.
Vamos a dejar sólo:
El código sería este:
$entrada = 'Wisi <a href="#" style="color: red;">defui nunc</a> dignissim <strong class="weird">transverbero ideo vel</strong> utinam blandit, iaceo meus epulae enim amet nibh sed brevitas. Pala consequat <script type="text/javascript" src="http://example.com/certainly/do/not/want/this.js"></script> capio sino regula typicus <small>luptatum</small> olim ullamcorper uxor in verto.'; $etiquetas_permitidas = array( 'a' => array( 'href' => array(), 'title' => array(), 'target' => array() ), 'em' => array(), 'strong' => array(), ); $salida= wp_kses( $entrada, $etiquetas_permitidas ); echo $salida;
Probablemente hayáis tenido problemas intentando desarrollar con Android cuando habéis intentado echar a andar el fichero adb para por ejemplo lanzar el emulador.
El problema es que al ejecutarlo dice algo así como: “./adb: No existe el archivo o el directorio” aunque estemos en el terminal y veamos con nuestros ojos que está el fichero, que tiene el bit de ejecución marcado y que todo es correcto.
Si te ocurre esto, lo más seguro es que estés usando una distribución de 64 bits y el IDE de Android necesita compatibilidad con 32 bits.
Cuando trabajas con AJAX en WordPress, si quieres hacerlo bien, debes hacer llamadas a admin-ajax.php y desde ahí gestionar las peticiones y sus salidas. Si conocéis esta técnica, conoceréis las funciones: wp_ajax_(acción) y wp_ajax_nopriv_(acción) (de la que no encuentro una referencia directa en el Codex, es raro).
Cuando hacemos desarrollos web para proyectos con algún apartado de gestión basado en formularios, lo más normal, es que terminemos teniendo que introducir fechas. Las fechas son un tanto problemáticas, tanto por su posterior manejo, como por su introducción por parte del usuario. ¿Por qué? Por dos razones:
Una buena solución suele ser manejar un calendario que salga directamente sobre el campo de texto como este que os muestro a continuación:
Cuando trabajamos con consultas en WordPress, es muy probable que necesitemos ordenar la salida de alguna forma diferente a la estándar que suele ser por fecha de forma que el más reciente aparezca primero y vayan apareciendo de forma sucesiva entradas más antiguas.
Si usamos WordPress como una API o como una plataforma de aplicaciones, más que como un CMS y más aún como un CMS orientado a blogs, este hecho es una auténtica necesidad.
En las instalaciones por defecto de MySQL, en muchas ocasiones, o aparece deshabilitada la caché de consultas o aparece, pero con muy poco espacio disponible.
Como podréis figuraros, la caché de consultas almacena en memoria física, la RAM, las últimas consultas realizadas y su resultado, de forma que si alguien repite dichas consultas, el acceso a su resultado sea casi inmediato comparado con recurrir a la base de datos en sí, a la que probablemente debamos acceder a disco y recorrer sus complejos árboles B y B+ internos.
El resultado de usar caché de MySQL es muy evidente en cuando a velocidad y en una entrada posterior os comentaré cómo sacar estadísticas para ver con más concreción cuál es la mejora.
¿Cómo activarla? ¿Cómo aumentar su tamaño?
Para ver si está activada nos dirigimos al fichero my.cnf (que probablemente esté en /etc o /etc/mysql) y buscamos dentro las siguientes cadenas:
En alguna ocasión, mostrando un extracto o por cualquier otra razón, a lo mejor necesitáis eliminar los enlaces de una cadena que manejáis en PHP. Para esta labor, podemos usar el siguiente código, que se basa en el uso de una expresión regular:
$cadena = preg_replace('/\b(https?|ftp|file):\/\/[-A-Z0-9+&@#\/%?=~_|$!:,.;]*[A-Z0-9+&@#\/%=~_|$]/i', '', $cadena);Con esto tendríamos la cadena sin enlaces: HTTP, HTTPS, FTP o FILE, si queréis podéis ampliar la primera parte de la expresión regular para incluir más posibilidades.
