WordPress 4.0.1 actualización de seguridad ¡ya estás tardando en actualizar!

Jueves, 20 de noviembre de 2014 |

Comentarios desactivados

wordpress 4.0.1

Acaba de salir a la luz la versión de WordPress 4.0.1 que soluciona graves posibles problemas de seguridad y, en consecuencia, es altamente recomendable.

En concreto incorpora los siguientes cambios:

  • Soluciona nada menos que tres vulnerabilidades XSS (Cross Site Scripting) por las que un autor o colaborador podría comprometer la seguridad de un sitio.
  • Arregla otra vulnerabilidad cruzada que podría usarse para engañar a un usuario para que cambie la contraseña.
  • También soluciona un problema que podría conllevar una denegación de servicio al comprobar contraseñas.
  • Incorpora protección adicional para peticiones de servidor ante ataques cuando WordPress hace peticiones HTTP.
  • Ahora WordPress inutiliza los enlaces de reinicio de contraseña si el usuario recuerda la clave, accede y cambia su dirección de correo.
  • Mejora la validación de datos EXIF al cargar fotos.
  • Y soluciona otros 23 pequeños fallos detectados desde el lanzamiento de WordPress 4.0.

Si no lo tienes desactivado, WordPress se actualizará solo a esta versión en las próximas horas, y sino ¡ya estás tardando!

Ver artículo completo...

WordPress 4.1 ya se puede probar … y funciona muuuy bien

Lunes, 17 de noviembre de 2014 |

Comentarios desactivados

wordpress 4.1Con el lanzamiento de la beta 1 de WordPress 4.1, ya disponible para descargar y probar, empieza el camino hacia la nueva versión de WordPress que verá la luz a finales de diciembre de este mismo año.

Las novedades de WordPress 4.1 son las que ya anunciamos hace días, lo bueno es que ya se pueden probar ¿las recordamos?:

  • Mejoras en el editor de entradas para que, por ejemplo, en el modo pantalla completa se pueda acceder a alguna caja meta, además de cambios de distribución de botones y estéticos.
  • Mejoras en los menús desplegables de usuario y entradas, posiblemente mediante el uso de Select2, un script jQuery totalmente compatible con todos los navegadores y muy solvente.
  • Permitir la desconexión en las sesiones existentes desde la pantalla de perfil de usuario, para lo que ya está en  marcha un plugin.
  • Nueva interfaz para la instalación de temas y plugins, aún muy verde pero del que también hay ya una versión inicial de plugin.
  • Mejoras en la gestión de archivos multimedia desde dispositivos móviles, sobre todo solucionar problemas actuales con el scroll en la pantalla de la Librería multimedia.
  • Mejoras en las queries WP_Meta_QueryWP_Tax_Query, and WP_Date_Query.
  • Por supuesto, el nuevo tema Twenty Fifteen.
  • Y, lo mejor de todo, y de lo que ya hemos hablado hace poco, poder instalar nuevos idiomas después de la instalación.

Con diferencia, lo mejor de todo lo nuevo es instalar idiomas adicionales desde los ajustes generales, con lo que se hace ya innecesario la descarga de versiones localizadas, así, sin anestesia.

Instalar idioma nuevo Nuevo idioma instalado Cambiar de idioma

El nuevo editor sin distracciones, va en gustos, pero no está mal, y de hecho es el editor por defecto, así que no te sorprendas si nada más entrar no ves las cajas meta de Publicar, Etiquetas, etc. No es que no existan, es que solo aparecen cuando mueves el cursor.

editor sin distracciiones wordpress 4.1

Y, por supuesto, ya tienes disponible el nuevo tema Twenty Fifteen para activar. Muy limpito, personalmente es el que más me gusta de los últimos 5 años, tal cual.

activar twenty fifteen wordpress 4.1

En fin, que lo disfrutes. Si tienes un sitio para pruebas ya tardas … y avisa si ves fallos, luego no te quejes. Si no tienes donde probarlo pásate por aquí.

Ver artículo completo...

¿Son democráticas las decisiones sobre WordPress?

Lunes, 27 de octubre de 2014 |

Comentarios desactivados

democracia participativa

WordPress, como todo desarrollo de código abierto tuvo su comienzo a partir de una idea brillante, y 11 años después, aquella gran idea se ha convertido en el sistema de gestión de contenidos más utilizado en el mundo, potenciando nada menos que el 25% de toda la Web.

Seguramente cuando Mike Little y Matt Mullenweg se lanzaron a hacer crear un sistema de gestión de contenidos amigable y potente no tenían ni idea de lo lejos que llegaría el proyecto, pero mira por donde la idea funcionó, y nosotros lo disfrutamos a diario.

Ahora bien, todo crecimiento tiene sus problemas, y uno de ellos es que actualmente la orientación del desarrollo de WordPress parece depender de una sola persona: Matt Mullenweg, para lo bueno y para lo malo.

De hecho hay mucha gente que WordPress es un producto de la empresa de Matt, Automattic, y no es así, su empresa tiene otros productos como WordPress.com o Akismet, pero WordPress en sí no es suyo, es de la comunidad. Automattic es una empresa genial, que apuesta por WordPress como no hay otra, pero WordPress no es un producto suyo sino en el que basan sus productos.

Ni siquiera la Fundación WordPress está pensada con este objetivo, sino que solo se limita a la protección de marcas y principios.

Así que ¿quién decide el futuro de WordPress?, de momento Matt.

matt mullenweg wordpress

 

Matt ha sido y es un gran líder de proyecto, tomando decisiones muy acertadas sobre hacia dónde debería ir WordPress pero ¿es bueno que esto sea así?

Hay grupos de desarrollo de la mayoría de los elementos y partes de WordPress, pero las decisiones, el liderazgo, lo detenta Mullenweg.

Uno de los handicaps de la dependencia en la genialidad de una sola persona es que si falta esa persona, y esperemos que no, o decide dedicarse a otra cosa, entonces el proyecto se resentirá, al menos hasta que se encuentren otros líderes que sustituyan su visión. Algo muy parecido está ocurriendo en Apple, pero es un caso distinto, Apple es una empresa.

Los proyectos de código abierto tienen larga experiencia en este sentido, y muchas veces se ha solventado este asunto mediante una especie de consejo asesor, un grupo de usuarios implicados en el futuro del proyecto que tomen las decisiones sobre el mismo. Estos consejos asesores, habitualmente, deben además consultar a toda la comunidad antes de tomar decisiones relevantes, para así obtener una mayor implicación de todos, además de para obtener el respaldo necesario.

Actualmente cualquier decisión sobre el futuro de WordPress la toma única y exclusivamente Matt Mullenweg, lo que no es nada democrático, ni siquiera recomendable. No se nos olvide que Matt es una persona, además de una personalidad, y aunque tenga una mente privilegiada no está exento de la posibilidad de cometer errores, incluso de tener sentimientos y gustos personales, que no siempre tienen porqué coincidir con el grueso de la comunidad de desarrolladores y usuarios de WordPress.

Si se planteara la posibilidad de organizar una especie de consejo asesor dejaría de recaer en las espaldas de Matt toda esa responsabilidad, y las decisiones serían mucho más consensuadas, mucho más democráticas y transparentes, acertadas o no. En cualquier caso nunca sería un problema pues la belleza de un proyecto de código abierto es la capacidad de respuesta antes los errores, precisamente debido a la implicación de la misma comunidad.

Actualmente, más allá de los debates en las reuniones de comunidad de usuarios de WordPress y alguna encuesta puntual, no existe algo parecido a “votar” sobre el futuro de WordPress, las decisiones son unipersonales, algo que socialmente hemos superado pero que, curiosamente, en un desarrollo tan abierto como WordPress seguimos dependiendo de una, permíteme llamarlo así, dictadura consentida, como la que tenían los antiguos romanos ocasionalmente.

Vale que todos estamos agradecidos a Matt por su decisión, encomio y buen hacer, pero ¿no habría que cuestionarse que 11 años después no deba avanzar el proyecto en este sentido?

Matt es un gran líder y visionario pero puede equivocarse, y podría incluso primar intereses de sus empresas a los de WordPress ¿no se te había ocurrido? En cualquier caso tiene una gran responsabilidad, y posiblemente vaya siendo el momento de liberarle de alguna, al menos en toda su extensión.

wordpress lupa

Tampoco es fácil elegir a los miembros de un posible consejo asesor, pues también ellos podrían equivocarse, pero se pueden aprovechar los avances en democracia directa y transparencia organizacional existentes para dotar a este ente de garantías suficientes para permitirles hacer su arduo trabajo al tiempo que liberarles de una excesiva presión externa e interna.

Actualmente nos encontramos con decisiones sobre el futuro de WordPress en entrevistas que le hacen a Matt o en intervenciones suyas en WordCamps pero ¿es esto transparente? ¿sabemos qué le ha llevado a tomar estas decisiones? ¿están sujetas a debate y/o aprobación? La respuesta a todas estas preguntas es NO.

Creo que son cuestiones que deberían irse dejando atrás y que el proceso de desarrollo de WordPress sea mucho más transparente y, sobre todo, participativo.

Un proceso de decisión regido por un consejo asesor, como plantea Vladimir Prevolac, conllevaría muchas ventajas:

  • Las normas de funcionamiento y procesos de decisión del consejo, incluso las reuniones, serían totalmente públicas, mejorando en mucho la transparencia del proyecto.
  • Sería mucho más efectivo que solo depender de la disponibilidad y buen criterio de una sola persona.
  • Se eliminaría la sensación de ser un proyecto personal, que en caso de que Matt abandonase el mismo perjudicaría enormemente su futuro y fiabilidad.
  • Toda la documentación generada por el funcionamiento habitual, reuniones y decisiones del consejo asesor servirían de información tremendamente valiosa para el futuro de WordPress.
  • Ahondaría en el empoderamiento de cada usuario de la comunidad, resultado ineludible de la política de gobierno abierto y transparente, reforzando la implicación y compromiso de toda la comunidad.

Por supuesto, un consejo de este tipo no estaría exento de cometer errores, de que sus miembros prioricen también sus gustos o intereses a la hora de la toma de decisiones, pero todo sería mucho más transparente y accesible, pudiendo valorar cada decisión y orientación.

Personalmente creo que tiene más ventajas que inconvenientes, y no estoy hablando de quitarnos de en medio a Matt Mullenweg, que por supuesto debería ser miembro nato del consejo, sino de dos cuestiones fundamentales:

  1. Liberar a Matt de responsabilidades
  2. Dotar de transparencia y democracia a las decisiones sobre el futuro de WordPress

No sé que pensarás de todo esto, estoy deseando leer tus impresiones al respecto.

Ver artículo completo...

Distinto fondo en cada entrada

Viernes, 24 de octubre de 2014 |

Comentarios desactivados

cambiar fondos wordpress

Ya hemos visto como cambiar la cabecera para cada plantilla de página o incluso como tener distintas cabeceras por categoría, pero ¿que te parecería poder elegir un fondo personalizado para cada entrada? ¿y sin tocar ni una sola línea de código?

Seguro que alguna vez lo usarás, y es sentillísimo gracias al plugin Custom background extended, una joya para los amantes de la personalización.

Una vez instalado y activo añade una nueva caja meta al editor de entradas de WordPress desde la que puedes elegir una cabecera personalizada para la entrada que vas a publicar, pudiendo elegir su ubicación y disposición.

caja cambiar fondo por entrada

El único requisito es que tu tema soporte fondos personalizados para lo que, te recuerdo, tienes que añadir esta línea al fichero functions.php del mismo:

add_theme_support( 'custom-background' );
Ver artículo completo...

¿Es realmente WordPress más seguro cambiando el prefijo de la base de datos?

Jueves, 23 de octubre de 2014 |

Comentarios desactivados

proteger wordpress

Uno de los consejos más habituales que se dan (yo también) sobre seguridad en WordPress es no usar el prefijo por defecto de WordPress para las tablas de la base de datos pero ¿de verdad este cambio mejora la seguridad de WordPress?

Ya sea desde la instalación o a posteriori (ver enlace del párrafo anterior), usar un prefijo distinto para las tablas de la base de datos es un consejo básico de seguridad en WordPress para evitar inyecciones SQL.

Como ya sabrás, WordPress por defecto usa el prefijo wp_nombretabla pero ¿realmente es una mejora de seguridad usar otro como mistablas_nombretabla? Vamos a ver los argumentos

¿Qué es una inyección SQL?

inyeccion sql

Para empezar es bueno saber qué es exactamente una inyección SQL. Por resumir, una inyección SQL ofrece al atacante la posibilidad de inyectar código SQL a través de alguna vía de entrada que esté disponible para los visitantes (visible o no) y que pueda ejecutarlo desde el servidor de la base de datos, que en el caso de WordPress sería el servidor MySQL donde esté alojado.

Por ejemplo, imagina que que en vez de introducir una dirección de email en un formulario de registro el atacante introduce código SQL que hace una lista de todos los registros de la tabla wp_users, que es donde se guardan todos los datos de los usuarios registrados de un WordPress. Da miedito ¿no?

Si así fuera, una vez enviado el formulario, en vez de rechazar el código SQL, la web lo ejecuta y el servidor de la base de datos le entregaría el contenido de la tabla wp_users al atacante.

Una inyección SQL, o sea, la ejecución de código a través de una vía de entrada a una web es el resultado típico de un problema con el código de un formulario, un plugin, el tema o cualquier otro componente de la instalación de WordPress. Y es posible casi siempre debido a que la vía de entrada para los visitantes no se ha saneado, por lo que permite la introducción de código SQL.

Es básicamente eso. En una instalación típica de WordPress el atacante también podrá escribir en la base de datos, lo que es incluso más peligroso como veremos más adelante.

Como en todo, hay muchas variantes de posibles inyecciones SQL, algunas realmente rebuscadas, pero es bueno que tengas una visión general de cómo funciona una inyección SQL, el impacto que puede tener si se lleva a cabo (leer o escribir en la base de datos) y, sobre todo, cómo se puede evitar.

Ahora vamos a ver cómo afecta esto a una instalación típica de WordPress y si un cambio en el prefijo de la base de datos influye a la hora de evitar inyecciones SQL ¿te parece?

Nombres y tablas de la base de datos de WordPress

Ya hemos visto en varias ocasiones cuales son las tablas de la base de datos de WordPress y para lo que sirve cada tabla, pero nunca sobra un nuevo repaso, y para lo que estamos hablando hoy nos viene de perla un recordatorio.

Básicamente, WordPress instala por defecto 11 tablas que, si no lo modificas, tendrán el prefijo wp_, así que si no has hecho modificaciones serán estas:

  • wp_commentmeta
  • wp_comments
  • wp_links
  • wp_options
  • wp_postmeta
  • wp_posts
  • wp_terms
  • wp_term_relationships
  • wp_term_taxonomy
  • wp_usermeta
  • wp_users

Si entiendes algo de inglés, solo viendo los nombres de las tablas puedes adivinar fácilmente qué se almacena en cada tabla. Por ejemplo, es fácil imaginar que en la tabla wp_comments se almacenan los comentarios o que en wp_options es donde están los ajustes ¿no?

Explotando una inyección SQL en WordPress

inseguridad wordpress

Vamos a adentrarnos en los reinos de Mordor así que elige tu mejor arma y confía en la comunidad del anillo (o en la de WordPress) jeje

Imagina que uno de los plugins que tienes instalado en tu WordPress es vulnerable a una inyección SQL, algo que no es raro, es la vía más frecuente de vulnerabilidades. Un atacante que te tenga ganas lo primero que haría sería escanear tu instalación de WordPress con herramientas como WPScan para tener la lista de los plugins que tienes instalados, incluso los desactivados. Si al ver la lista detecta que uno de ellos es vulnerable a inyecciones SQl ya tendrá la mitad del trabajo hecho, por no decir la mayor parte.

Lo siguiente que haría sería explotar la inyección SQL para lo que ejecutaría unos códigos como los siguientes, los habituales para crear manualmente un administrador en la base de datos de WordPress, ahí es nada:

INSERT INTO `wordpressdatabase`.`wp_users` (`ID`, `user_login`, `user_pass`, `user_nicename`, `user_email`, `user_status`, `display_name`) VALUES ('1000', 'tempuser', MD5('Str0ngPa55!'), 'tempuser', 'support@wpwhitesecurity.com', '0', 'Temp User');
INSERT INTO ` wordpressdatabase`.`wp_usermeta` (`umeta_id`, `user_id`, `meta_key`, `meta_value`) VALUES (NULL, '1000', 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}');
INSERT INTO ` wordpressdatabase`.`wp_usermeta` (`umeta_id`, `user_id`, `meta_key`, `meta_value`) VALUES (NULL, '1000', 'wp_user_level', '10');

¿Qué hacen esos códigos? Pues nada más y nada menos que el atacante puede crear un usuario WordPress con privilegios de administrador en tu web, con lo que obtendrá de inmediato acceso al escritorio de tu WordPress con acceso total.

En otras ocasiones el atacante no solo crea un nuevo usuario administrador sino que además cambia la contraseña del actual y, de paso, te deja a ti sin acceso, un síntoma que cuando lo veas ya tardas en reaccionar.

¿Por qué el atacante puede crear un administrador?

Sabiendo de antemano que tu web está hecha con WordPress y que es vulnerable a inyecciones SQL debido a algún plugin vulnerable o lo que sea que haya visto, el atacante solo necesita conocimientos básicos de configuración de la base de datos de WordPress, algo totalmente documentado en la misma web de WordPress.org.

Adivinando nombres de tablas de la base de datos

Si el prefijo de la base de datos de WordPress del sitio es el definido por defecto, o sea wp_, el atacante puede fácilmente ejecutar código y leer o escribir información en las tablas.

Si cambias el prefijo de la base de datos de WordPress, por ejemplo a MordorX25_, el atacante no podrá leer o escribir en la base de datos tan fácilmente ya que no conoce los nombres de las tablas. Esto es así incluso aunque haya realizado la inyección SQL y el código sea explotable, pues no tendrían efecto alguno al no encontrar un objetivo sobre el que actuar.

Sí, cambiar el prefijo de las tablas de la base de datos de WordPress mejora la seguridad en WordPress

La – buena – idea de cambiar el prefijo de las tablas de la base de datos de WordPress es antigua, de hecho desde las primeras versiones de WordPress, para evitar inyecciones SQL que pudiesen crear usuarios e inyectar spam o malware. El único modo de pararlos rápidamente era cambiar los nombres por defecto de las tablas.

¿Significa esto que estoy a salvo solo cambiando el prefijo de las tablas de la base de datos de WordPress?

Por supuesto que no. Cambiar el prefijo de las tablas de la base de datos de WordPress es una muy buena medida de seguridad, y frena infinidad de ataques a la base de datos, pero no es la única forma en que pueden entrar en tu sitio.

Aunque la mayoría de las veces los culpables de un ataque a WordPress son plugins mal programados o sin actualizar, la realidad es que se puede conseguir acceso a una instalación de WordPress de otros modos, por ejemplo mediante ingeniería social, robando contraseñas y cualquier otro método que imagines. Todo dependerá del interés que tu sitio provoque en los posibles atacantes, y con la plaga de spammers que nos invade nadie está seguro 100%.

Así que, además de cambiar el prefijo de las tablas de la base de datos, aplica estas 15 reglas para tener un WordPress a prueba de bombas, serás más feliz.

Ver artículo completo...

Cómo volver a una versión anterior de WordPress

Miércoles, 22 de octubre de 2014 |

Comentarios desactivados

regreso al futuro pasado

Actualizar WordPress no es solo la decisión adecuada para disfrutar de las novedades de cada versión sino que es lo más recomendable para tener una instalación segura. No obstante, hay ocasiones en que se hace necesario volver a una versión anterior de WordPress.

Hay ocasiones en que un plugin o tema no es compatible con una actualización de WordPress y te das cuenta de ello después de actualizar.

En este tipo de casos, mientras se actualiza el plugin o tema para poder convivir con la última versión de WordPress puede ser necesario volver a una versión anterior, en la que si funcionaba.

Otras veces es simplemente que no te gusta la nueva versión pero, en serio, que no sea este el motivo.

En ambos casos, el procedimiento sería el siguiente:

  1. Edita el fichero wp-config.php de la instalación actual añadiendo la siguiente línea:
    define( 'WP_AUTO_UPDATE_CORE', false );

    De este modo evitas que WordPress se actualice solo sin tu intervención y que no tengas que volver a empezar desde el principio de nuevo.

  2. Descarga la versión a la que quieres des-actualizar desde el almacén de versiones de WordPress España. Si por algún motivo necesitas volver a una versión anterior a la 2.5 entonces descárgala desde el repositorio oficial en inglés, donde tienes absolutamente todas las versiones.
  3. Descomprime el fichero zip que contiene la versión descargada y, mediante FTP, sube a la carpeta de tu instalación todos los archivos y carpetas descomprimidos excepto la carpeta wp-content porque sino sustituirías la tuya por la nueva y perderías todas las personalizaciones del tema y plugins, además de todos los archivos que hayas subido. Cuidado con esto, mi truco para evitar este error es borrar la carpeta wp-content recién descomprimida para así no dar lugar a la posibilidad de subirla al servidor.
  4. Accede a la siguiente dirección de tu sitio por si fuera necesario actualizar la base de datos: tusitio.com/wp-admin/upgrade.php

Ya está, si has seguido los pasos simplemente accede a tu escritorio de WordPress para comprobar que se ha des-actualizado. Pero no te duermas en los laureles o te arrepentirás más pronto que tarde, ponte las pilas y actualiza el tema o plugin incompatible, que no es buena idea nunca tener una versión de WordPress o un plugin sin actualizar, serían puerta de entrada fácil a hackers.

¿Otro consejo? Siempre que te sea posible es mejor usar otro tema o plugin que no te obligue a no estar actualizado que vivir con el riesgo y la inseguridad de tener una versión antigua de un plugin o WordPress.

Ver artículo completo...

Whatsapp en WordPress

Lunes, 20 de octubre de 2014 |

Comentarios desactivados

wordpress whataspp

Yo creo que no hay casi nadie en el mundo hispano que no use Whatsapp, la aplicación de mensajería instantánea que, poco a poco, ha ido retirando la conversación de las redes abiertas a este entorno más privado.

Es cada vez más habitual que en grupos de Whatsapp se compartan enlaces a páginas web sobre cualquier tema, pero es algo que actualmente es bastante coñazo hacerlo porque requiere un proceso muy manual de:

  1. Visitar la web que quieres compartir desde el móvil
  2. Copiar la URL
  3. Ir al grupo o chat donde quieres compartirlo
  4. Pegar la url

Es un proceso bastante tedioso, sobre todo la parte de copiar la URL, así que tiene mucho sentido facilitar la tarea de compartir URLs en Whatsapp, algo que desde WordPress podemos añadir ya mismo, y de varias maneras. Vamos a ver algunas …

  • >Mobile share bar: plugin especializado en botones para compartir para la versión móvil de tu sitio WordPress. Una vez instalado el plugin y configurados los ajustes para que se muestren los botones y textos a tu gusto, cuando alguien visite tu web desde un dispositivo con iOS (de momento no está disponible para Android o Windows Phone) verá unos hermosos botones desde los que compartir la página actual en tus redes favoritas, o Whatsapp.
    mobile share
  • Mashshare: plugin de iconos sociales para compartir en el que entre sus múltiples opciones dispones también la de compartir en Whatsapp que, por supuesto, solo funcionará correctamente desde móviles.
    mashshare
  • Add to any: el mítico y veterano plugin de iconos sociales dispone, entre sus múltiples opciones, la posibilidad de añadir un botón para compartir en Whatsapp. Una elección fantástica para los que ya usen este plugin.
    add to any whatsapp wordpress
  • Contact form 7 integration with Whatsapp: Una vuelta de tuerca de todo esto es la posibilidad de recibir en tu Whatsapp los avisos de formularios dejados en tu web a través del plugin Contact Form 7. El proceso de configuración es algo petardo porque primero tienes que crear una “aplicación” como harías para integrar WordPress y, por ejemplo, Facebook, para lo que tienes que pasarte por wassame.com, conseguir tu ID y crear la aplicación, pero es una opción muy interesante si eres de los que estás todo el día liado en el móvil.
    whatsapp contact form 7 wordpress

Como verás ya va habiendo bastantes opciones, que supongo que crecerán con la reciente compra de Whatsapp por parte de Facebook, con lo que la entrada en el mundo anglosajón estará garantizada.

Yo aún tengo que encontrar tiempo para añadirlo al blog, pero pienso hacerlo, ¿y tu? ¿ya has integrado Whatsapp y WordPress? ¿piensas hacerlo? ¿por qué?

Ver artículo completo...

Qué es y cómo se usa el fichero functions.php

Viernes, 17 de octubre de 2014 |

Comentarios desactivados

funciones functions.php

Es habitual encontrar en Ayuda WordPress multitud de trucos para añadir funciones al archivo functions.php, incluso hemos hablado de si es mejor usar este fichero o un plugin de utilidades, que también aprendimos a hacerlo, pero ¿qué es el archivo functions.php y cómo se usa?

Vamos a ver algunos conceptos básicos y consejos de uso ¿te parece?

¿Qué es el fichero functions.php?

Lo más básico es que es un archivo PHP, o sea, un archivo de texto repleto de caracteres y espacios que el motor PHP ejecutará para hacer cosas en tu web. Estos caracteres se denominan funciones y están encerradas entre las etiquetas <?php  y ?>. La cosa es sencilla: lo que está dentro de esas tags se ejecuta y lo que está fuera no.

Viene a ser el sustituto natural, y mejor estructurado del veterano archivo my-hacks.php, desaparecido en WordPress 2.8, que era donde antiguamente se incluían funcionalidades extra, pero con el agravante de que en cada actualización de WordPress se machacaba el archivo.

¿Donde está el fichero functions.php?

Prácticamente todos los temas WordPress actuales tienen un archivo functions.php en la carpeta principal, y si no lo tiene debería tenerlo. Unas veces contiene muchas funciones y en otras ocasiones solo unas pocas.

¿Qué hace el fichero functions.php?

El archivo functions.php contiene unos códigos PHP denominados funciones, una característica estándar de WordPress que permite que un tema “conecte” con funcionalidades internas de WordPress (registrar barras laterales, añadir soporte de miniaturas, etc) o propias del tema activo, como códigos cortos (shortcodes) especializados.

¿Cómo se comunica WordPress con el fichero functions.php?

WordPress, por defecto, espera encontrar un fichero functions.php en la carpeta del tema activo, no pasa nada si no lo encuentra, pero WordPress revisa a ver si existe e interactúa con él, ejecutando las funciones que encuentre.

De este modo, WordPress “sabe” que las funciones situadas en el fichero functions.php de tu tema deben ejecutarse y usará el motor PHP instalado en el servidor y las funciones estándar propias de WordPress para interpretarlas y ejecutarlas. Parece complicado pero es simple, se basa en las propias funciones y en otras piezas de código denominadas ganchos” (hooks).

¿Es necesario un fichero functions.php?

Imprescindible no es pero sí muy recomendable. Puedes incluir en él funciones necesarias para que el tema funcione correctamente, y como es lo primero que revisa WordPress se cargarán de inmediato, antes que códigos de los plugins, pues a fin de cuentas lo primero que se debe mostrar es el diseño, o sea, el tema.

Consejos de uso del fichero functions.php

A pesar de lo interesante que es disponer un fichero functions.php en el tema activo, hay algunos consejos a tener en cuenta:

  • No te vuelvas loco añadiendo funciones al fichero functions.php. Este fichero es genial para incluir en él funciones relacionadas con el diseño, con elementos visuales, para el resto de cosas es mejor un plugin de utilidades. Hay mucha gente que usa el fichero functions.php para meter en él todas las funciones chulas que encuentra en Ayuda WordPress o cualquier otra web, y no, no es un cajón de sastre, cada función que incluyas debe tener un sentido y objetivo, y si no la usas bórrala.
  • El fichero functions.php de un tema hijo no se superpone al del tema padre, al contrario que el resto de archivos que crees en el tema hijo. Si que se ejecutará antes que el del tema padre, lo que supondrá un problema si hay funciones iguales o incompatibles, con lo que lograrías unos feos errores PHP de funciones duplicadas o algo mucho peor, así que revisa qué pones en el fichero functions.php del tema hijo y del padre.
  • Procura que no crezca mucho, da igual que necesites muchas funciones. Si ves que tu fichero functions.php empieza a rozar las 200 líneas considera seriamente crear ficheros dependientes de los que tu archivo functions.php extraiga el resto de códigos que quieras ejecutar, lo podrás hacer fácilmente mediante comandos PHP como include() o require(), que incluirán o realizarán la conexión necesaria para ejecutar todo sin necesidad de sobrecargar tu archivo functions.php.

Como verás, el archivo functions.php es de una gran utilidad, y usado con mesura ampliará y mejorará la funcionalidad de tu web, así que aprende a usarlo, trátalo con cariño y añádele funciones útiles.

Ver artículo completo...
Artículos Anteriores