El editor de WordPress ha ido adelgazando en las últimas versiones, mostrando cada vez menos botones de formato, a pesar de que en realidad si que podrías tenerlos a tu disposición.

El editor de WordPress, como ya sabrás, es una versión adaptada de TinyMCE, que ofrece una enorme cantidad de botones de formato, que el equipo de desarrollo de WordPress ha ido inhabilitando en base a los usos más comunes de los usuarios, los nuestros.

Ahora bien, cada usuario somos un mundo, y sin quererlo a veces recurrimos a plugins para ampliar el editor de WordPress sin saber que podemos tenerlo simplemente modificando su funcionamiento.

Un ejemplo de esto que te digo es que en realidad el editor completo TinyMCE está ahí, solo tienes que habilitarlo. Para conseguirlo tienes que crear una función en tu plugin de utilidades o archivo functions.php y añadir el siguiente código:

//Activar todos los botones del editor
function todos_los_botones($buttons) {

$buttons[] = 'fontselect'; //Selector de tipo de fuente
$buttons[] = 'fontsizeselect'; //Selector de tamaño de fuente
$buttons[] = 'styleselect'; //Selector de estilos de párrafo mucho más amplio
$buttons[] = 'backcolor'; //Color de fondo de párrafo
$buttons[] = 'newdocument'; //Nuevo documento inline
$buttons[] = 'cut'; //Cortar texto
$buttons[] = 'copy'; //Copiar texto
$buttons[] = 'charmap'; //Mapa de caracteres
$buttons[] = 'hr'; //Línea horizontal
$buttons[] = 'visualaid'; //Ayudas visuales del editor

return $buttons;
}
add_filter("mce_buttons_3", "todos_los_botones");

Por supuesto, no tienes que activarlos todos, sino solo los que necesites o uses más. La diferencia es pasar de esto …

a esto otro …

Tú eliges

A pesar de lo mucho que me meto con Automattic y JetPack, hay que reconocer que algunos de sus módulos, conexiones aparte, son estupendos. El caso de Difundir es uno de ellos, una pequeña maravilla que permite publicar automáticamente entradas en tus redes favoritas.

Pero también este módulo tiene sus limitaciones. La primera y obvia es que necesitas la conexión a WordPress.com para usarlo, pero una vez salvado este “peaje” que nos pide Automattic para acceder a sus virtudes, siempre he echado de menos poder añadir automáticamente hashtags, como si puedes hacer en la configuración de los plugins para compartir manualmente.

Me refiero a que, por ejemplo, si tu entrada habla sobre WordPress, puedas automatizar que siempre que se publiquen tus entradas se añadan hashtags relacionados de manera automática, para una mayor difusión de tus contenidos mediante una etiqueta que usan muchos otros usuarios de las redes sociales.

Y digo automatizar porque personalizarlo ya puedes. Antes de publicar una entrada hay una pequeña caja de texto en la caja meta de Publicar de WordPress donde puedes modificar el texto que se enviará y donde, por supuesto, puedes añadir hashtags manualmente, pero eso ya lo sabías ¿no?

Me refiero a automatizar totalmente, que no te tengas que acordar de personalizar los textos sino que se añada siempre algún hashtag – o varios – a tus publicaciones en redes sociales. Y para ello la mejor opción sería utilizar las etiquetas (tags) de la entrada como hashtag ¿a que sí?

Para ello recurriremos a nuestro plugin de utilidades, o al fichero functions.php de tu tema activo si lo prefieres, donde hay que añadir este código:

//Añadir hashtags automáticos a Divulgar de JetPack
//Si está activo empieza la magia
function ayudawp_publicize_hashtags() {
    $post = get_post();
    if ( ! empty( $post ) ) {
 
        // Cogemos las tags de la entrada
        $post_tags = get_the_tags( $post->ID );
 
        // Añadimos las tags al mensaje
        if ( ! empty( $post_tags ) ) {
 
            // Creamos una lista de hashtags con las tags 
            $hash_tags = '';
            foreach( $post_tags as $tag ) {
                $hash_tags .= ' #' . $tag->name;
            }
 
            // Creamos nuestro propio mensaje personalizado ya con las tags como hashtags
            $custom_message = get_the_title() . ' ' . $hash_tags;
            update_post_meta( $post->ID, '_wpas_mess', $custom_message );
        }
    }
}
} 
// Guardamos el mensaje
function ayudawp_cust_pub_message_save() {
    add_action( 'save_post', 'ayudawp_publicize_hashtags' );
}
add_action( 'publish_post', 'ayudawp_cust_pub_message_save' );

El código es autoexplicativo y funciona por sí solo. Revisa si la entrada tiene etiquetas (tags) y las convierte en hashtags que saldrán detrás del título. Simple y efectivo, como a tí te gusta.

Ya hemos visto en otras ocasiones como desactivar la comprobación de actualizaciones de todos los plugins, e incluso un plugin que bloquea actualizaciones de plugins específicos, pero hoy le damos otra vuelta de tuerca.

Porque, la verdad, la idea de no permitir la actualización de plugins en concreto me parece muy buena, incluso imprescindible para desarrolladores, pues así evitas que un cliente patoso se cargue tus personalizaciones, pero lo de usar un plugin para desactivar actualizaciones de plugins, o incluso desactivar la comprobación del todo, me parece un poco demasiado.

Es mucho más sencillo usar un pequeño código, que además puedes incluir en el fichero functions.php del tema – si lo has hecho tu – o en un plugin de utilidades específico para el sitio o tu cliente, casi la mejor opción.

El código sería así:

/* Quitar actualizaciones de los plugins de la lista "unset"*/
function disable_plugin_updates( $value ) {
   unset( $value->response['jetpack/jetpack.php'] );
   return $value;
}
add_filter( 'site_transient_update_plugins', 'disable_plugin_updates' );

Solo tienes que cambiar la ruta al fichero principal del plugin (en este caso /jetpack/jetpack.php) por el plugin que no quieres que se actualice y arreando. ¿Quieres desactivar más plugins? Solo tienes que añadir las pertinentes líneas el tipo unset( $value->response['carpeta_plugin/fichero_principal_plugin.php'] ); a continuación de la del ejemplo.

¡A desactivar!

Como ya sabrás, WordPress por defecto crea una serie de archivos de publicaciones, en concreto genera los archivos de autor, categoría, etiquetas, fecha, formatos de entrada y búsquedas, pero el hecho de que sea así por defecto no implica que tenga que ser obligatorio.

Pero, sobre todo, es posible que no sea necesaria la visutalización de estos archivos en tu WordPress.

Digamos, por ejemplo, que no usas categorías, o que solo usas una para todo, o que el único autor eres tú mismo, o que no usas etiquetas o incluso que no te aporta nada disponer de una serie de enlaces a archivos que ni tu ni tus visitantes utilizan.

Entonces ¿qué sentido tendría disponer de una serie de archivos que no aportan nada?

Hablando de SEO, como ya sabrás los archivos de categorías y etiquetas pueden llegar a tener su propio posicionamiento en buscadores, y puede ser que no quieras que estos archivos compitan en un futuro con cada publicación particular, pues en realidad la propia estructura de estos archivos no ofrecen el contenido completo.

Por supuesto, si este es tu caso no hace falta eliminar los archivos, solo con marcar los ajustes en tu plugin SEO para que no se indexen esos archivos sería suficiente.

Ahora bien, si lo que quieres es eliminarlos totalmente, si estás decidido, solo tienes que añadir el siguiente código al fichero functions.php del tema activo:

/* Eliminar archivos de WordPress */

add_action('template_redirect', 'aw_remove_wp_archives');
 
/* Borrado de archivos */
function aw_remove_wp_archives(){
  //Si estamos en el archivo de la categoría o etiqueta o fecha o autor
  if( is_category() || is_tag() || is_date() || is_author() ) {
    global $wp_query;
    $wp_query->set_404(); //definimos una página de 404 no encontrado
  }
}

En el código se eliminan los archivos de categorías, etiquetas, fechas y autor, pero lo puedes personalizar a tu gusto.

A la hora de instalar WordPress uno de los elementos básicos para poder conectarte a la base de datos, además del  usuario y clave MySQL es el nombre del servidor, el conocido como hostname, un dato que normalmente te facilita tu proveedor de alojamiento pero ¿y si no das con él?

Como la misma pantalla de inicio de la instalación de WordPress te indica, en el 99% de las ocasiones el nombre de servidor es localhost, pero ya sabrás que es precisamente es 1% el que suele dar guerra, especialmente cuando tu proveedor de hosting no te facilita las cosas.

Hay proveedores que no usan ese estándar, sino los siguientes:

• 1and1 Hosting — db12345678
• DreamHost — mysql.example.com
• GoDaddy — h41mysql52.secureserver.net
• ICDSoft — localhost:/tmp/mysql5.sock
• MediaTemple (GS) — internal-db.s44441.gridserver.com
• Pair Networks — dbnnnx.pair.com
• Yahoo — mysql

Pero si no te funciona ni localhost ni estás en el alguno de los anteriores proveedores siempre puedes usar un truco del archivo de configuración wp-config.php que te sacará del embrollo en más de una ocasión.

La idea es sustituir la línea siguiente:

/** Host de MySQL (es muy probable que no necesites cambiarlo) */
define('DB_HOST', 'localhost');

Por esta otra:

/** Host de MySQL (es muy probable que no necesites cambiarlo) */
define('DB_HOST', $_ENV{DATABASE_SERVER});

Lo que hace la nueva línea es intentar resolver el host de la base de datos sin necesidad de introducirlo manualmente. Guardas los cambios y en la mayoría de las ocasiones recuperará el nombre de tu servidor y todo funcionará correctamente.

Si utilizamos la herramienta PageSpeed Insights de Google para analizar nuestro WordPress es bastante probable que entre los elementos a corregir se encuentre el siguiente:

Eliminar el JavaScript que bloquea la visualización y el CSS del contenido de la mitad superior de la página

¿Qué significa esto? En nuestra web se cargan archivos CSS para dar estilo a las páginas y archivos Javascript para generar elementos dinámicos, entre otras cosas. Normalmente, este tipo de archivos se sitúan en la cabecera de la web, por lo que el navegador cargará estos contenidos antes que el código de la propia página, provocando una mayor espera hasta que se muestren contenidos en el navegador.

Para solucionar esto Google recomienda colocar solo en la cabecera el código Javascript y CSS que se vaya a utilizar en la página que se muestra o realizar una carga aplazada del código. La primera opción es poco viable en WordPress, ya que resultaría muy complicado averiguar el código concreto que se carga en cada página, pero sí que se puede hacer algo con la carga aplazada.

En primer lugar, la carga aplazada de las hojas de estilo CSS no es recomendable ya que, de hacerlo, la página se mostrará inicialmente sin diseño alguno, para pasar a maquetarse al finalizar la carga, lo que suele provocar un efecto extraño en la carga.

La carga aplazada de Javascript sí se puede probar, teniendo en cuenta que esta carga aplazada en ocasiones puede generar problemas en la web, en especial si estamos usando plugins con funcionamiento dinámico como galerías de imágenes, o el propio tema de WordPress cuenta con esos elementos. Por tanto, se puede probar la carga aplazada, y solo en caso de que veamos que todo sigue funcionando bien en la web deberemos dejarla activada.

La primera manera de lograr esa carga aplazada de Javascript consiste en agregar el siguiente código al archivo functions.php del tema que estemos utilizando:

function footer_enqueue_scripts() {
 remove_action('wp_head', 'wp_print_scripts');
 remove_action('wp_head', 'wp_print_head_scripts', 9);
 remove_action('wp_head', 'wp_enqueue_scripts', 1);
 add_action('wp_footer', 'wp_print_scripts', 5);
 add_action('wp_footer', 'wp_enqueue_scripts', 5);
 add_action('wp_footer', 'wp_print_head_scripts', 5);
}
add_action('after_setup_theme', 'footer_enqueue_scripts');

Para comprobar si el código aplicado ha funcionado podemos cargar nuestra web y ver el código fuente, para analizar si los archivos .js se cargan al final. Hay que tener en cuenta que no necesariamente todos los archivos .js se moverán al pie de la web.

Si no queremos modificar el código existen diversos plugins para WordPress que también sirven para aplazar la carga de Javascript al pie de la web. Una opción sería el plugin JS & CSS Script Optimizer. Una vez instalado veremos en el apartado Ajustes la opción Script Optimizer. Aquí podremos configurar algunos aspectos del funcionamiento del plugin: combinar archivos Javascript y CSS en un único archvio, agregar excepciones a la optimización, etc. De esa forma, en caso de que haya problemas tras la activación del plugin siempre podemos aplicar cambios en la configuración para ver si se soluciona el problema.

Existen otros plugins que sirven para hacer lo mismo, con más o menos opciones añadidas: Scripts to Footer, JavaScript to Footer, JCH Optimize, etc.

Otra forma de aplazar la carga del Javascript o CSS es hacer una carga asíncrona en paralelo al resto de contenidos de la web, en lugar de hacer una carga de forma secuencial (unos elementos detrás de otros). Para ello, podamos utilizar un plugin como el Async JS and CSS. Este plugin también añade dentro de Ajustes la opción Async Settings, donde podremos configurar el funcionamiento del plugin: elementos a cargar de forma asíncrona, método de carga de los CSS, etc.

Recordar de nuevo que en caso de probar cualquiera de estos plugins o modificaciones en el código tendremos que hacer pruebas en el frontal de la web para verificar que todo sigue funcionando como debiera. En caso de que surjan problema es preferible no aplazar la carga de Javascript y CSS.

También es importante reseñar que esta carga aplazada no siempre se tiene que traducir en una mejora en la puntuación que obtengamos en PageSpeed, pudiéndose dar el caso de que incluso la nota baje. Para tales casos también será conveniente desactivar estos plugins.

Lo sé, me ha dado por el Whatsapp, pero es que se usa mucho y no debemos perder ni una sola oportunidad de difundir nuestro contenido ¿no crees?

Así que si no te convenció ninguno de los plugins que ya vimos para añadir iconos con los que compartir en Whatsapp, o no usas JetPack, nada mejor que crear el tuyo propio ¿no?

Pues nada más sencillo. Solo tienes que ir a la web whatsapp-sharing.com y crear el tuyo en solo tres pasos:

1. Elegir el texto del botón
2. Elegir el texto que se muestra al colocar el cursor sobre el botón (el famoso tooltip)
3. Elegir la opción “Current page url” para que lleve a la página o entrada que se esté visitando.

Se genera un código de manera automática que puedes colocar a tu gusto en el archivo single.php del tema activo, normalmente a continuación del loop.

Por supuesto, no sirve solo para WordPress, también puedes usarlo en cualquier otra web, o en Blogspot, tu mismo.

¡Hala, a wuasapear!

Una la las novedades de WordPress 4.2 más polémicas, curiosamente, ha sido la incorporación de soporte para Emojis además de caracteres Unicode nativos en Chino, Japonés y Coreano, símbolos matemáticos y musicales, y símbolos jeroglíficos.

Vale que somos muchos los que no usamos el juego de caracteres Han para escribir en Chino, ni bloqueamos en Japonés o Coreano pero ¿quien no usa los Emojis a diario en su móvil?

Yo los uso, y mucho. Además, creo que todos estaremos de acuerdo en que hay que potenciar el uso móvil de WordPress, aunque si me parece que se podría haber incorporado este soporte de una manera más transparente, o al menos haber ofrecido alguna opción donde activarlo o no ¿por qué?

Básicamente porque desde WordPress 4.2 se añaden una serie de líneas en la cabecera de nuestro sitio que cargan con líneas extras de CSS y JavaScript que no todos querrán ¿no? Me refiero a todo esto:

<script type="text/javascript">
			window._wpemojiSettings = {"baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":".png","source":{"concatemoji":"http:\/\/www.website.com\/wp-includes\/js\/wp-emoji-release.min.js"}};
			!function(a,b,c){function d(a){var c=b.createElement("canvas"),d=c.getContext&&c.getContext("2d");return d&&d.fillText?(d.textBaseline="top",d.font="600 32px Arial","flag"===a?(d.fillText(String.fromCharCode(55356,56812,55356,56807),0,0),c.toDataURL().length>3e3):(d.fillText(String.fromCharCode(55357,56835),0,0),0!==d.getImageData(16,16,1,1).data[0])):!1}function e(a){var c=b.createElement("script");c.src=a,c.type="text/javascript",b.getElementsByTagName("head")[0].appendChild(c)}var f;c.supports={simple:d("simple"),flag:d("flag")},c.supports.simple&&c.supports.flag||(f=c.source||{},f.concatemoji?e(f.concatemoji):f.wpemoji&&f.twemoji&&(e(f.twemoji),e(f.wpemoji)))}(window,document,window._wpemojiSettings);
		</script>
		<style type="text/css">
img.wp-smiley,
img.emoji {
	display: inline !important;
	border: none !important;
	box-shadow: none !important;
	height: 1em !important;
	width: 1em !important;
	margin: 0 .07em !important;
	vertical-align: -0.1em !important;
	background: none !important;
	padding: 0 !important;
}
</style>

Total nada ¿eh?

Si eres de los que prefieren ahorrar unos segundos de carga de su Web, o simplemente si tienes claro que no quieres ofrecer los Emojis, puedes retirar esta novedad de un par de maneras.

Desactivar soporte de Emojis con código

Solo tienes que añadir el siguiente código al fichero functions.php de tu tema o a tu plugin de utilidades para desactivar el soporte de Emojis.

//Desactivar soporte de Emojis
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );

Y si además quieres quitar los estilos entonces las líneas a añadir sería estas:

//Desactivar soporte y estilos de Emojis
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );

Desactivar soporte de Emojis con plugin

Si prefieres tirar de plugins puedes instalar y activar el denominado Classic Smiles que desactiva el soporte de Emojis y, como extra, devuelve a tu sitio los emoticonos de siempre.

El archivo oculto de sistema .htaccess, aún no siendo parte de WordPress, tiene multitud de funcionalidades realmente útiles para cualquier web, así que más vale conocerlo y familiarizarnos con él. Así que vamos a ver qué es, cómo funciona, y aprender algunos trucos útiles, algunos poco conocidos, que podemos usar para nuestra instalación de WordPress.

1. ¿Qué es el archivo .htaccess?

El software de servidor Apache, sobre el que funciona la mayoría de la Web, ofrece configuración de directorios a través de los archivos de Acceso a Hipertexto, Hypertext Access en inglés, más conocidos como archivos .htaccess para que te hagas una idea de donde viene el nombrecito del archivo.

Estos archivos .htaccess permiten ajustes personalizados y específicos para cada sitio de directivas de configuración del sistema, definidas en el archivo de configuración principal de Apache (httpd.conf).

Estas directivas personalizadas pueden operar dentro de un archivo denominado .htaccess. Para ello el usuario debe conceder al fichero .htaccess los permisos de archivo adecuados de acceso y/o edición. Ya puestos, a este respecto toma nota que jamás debes dar permisos de escritura para todos al archivo .htaccess, lo más habitual y seguro es conceder permisos 644, que permite acceso universal de lectura y permiso de escritura solo al usuario del sistema.

También debes saber que las reglas – o directivas – de .htaccess afectan al directorio superior y todos los subdirectorios donde esté situado. Así que para que se apliquen sus configuraciones a toda una web debes colocar el archivo .htaccess en la carpeta raíz de sitio.

Además, también puedes crear archivos .htaccess en un directorio o subdirectorio concreto para que sus reglas se apliquen solo al mismo.

2. Notas importantes para novatos con .htaccess

Al ser un archivo de configuración, .htaccess es realmente potente, y en consecuencia peligroso si no se usa bien. Hasta el más ligero error de sintaxis, como un espacio de sobra, puede provocar un funcionamiento desastroso en el servidor. Así que es importante que hagas siempre copia de cualquier archivo y carpeta relevante de tu web, incluidos los ficheros .htaccess originales, antes de meterte a enredar con archivos de Acceso a Hipertexto.

También es importante comprobar que todo funciona bien en tu web después de hacer cualquier cambio en el fichero .htaccess, por pequeño o irrelevante que te parezca. Si encuentras algún error deshaz los cambios o recupera la copia guardada antes de hacerlos para así devolver tu web a su funcionamiento normal.

3. Ojo con el rendimiento

Las directivas de .htaccess ofrecen configuraciones de directorio sin necesidad de acceder al archivo principal de configuración de Apache (httpd.conf). Sin embargo, por cuestiones de rendimiento y seguridad, siempre que sea posible, se debe utilizar siempre el archivo principal de configuración para las directivas del servidor.

Por ejemplo, cuando un servidor está configurado para procesar directivas de .htaccess, Apache debe buscar en cada directorio del dominio y cargar todos y cada uno de los archivos .htaccess en cada petición de documentos. Esto provoca un incremento en el tiempo de procesamiento de la página y, en consecuencia, perjudica el rendimiento.

Para sitios con poco tráfico este tipo de fallos de rendimiento pueden ser inapreciables, pero se puede convertir en un serio problema en webs de alto tráfico.

Así que, como regla de oro, solo debes usar archivos .htaccess cuando no tengas acceso al archivo de configuración principal del servidor, o sea, al archivo httpd.conf.

4. Expresiones regulares (regex) disponibles en .htaccess

#

Una #  le dice al servidor que ignore la línea, que no la ejecute. Se usa para incluir comentarios. Debes tener claro que cada línea de comentarios requiere su propio carácter # así que si quieres añadir mucho texto recuerda poner una # al principio de cada línea. Suele ser recomendable usar solo letras, números, guiones y guiones bajos, para evitar posibles errores de llamadas no deseadas al servidor.

Ejemplo:

# esto es un comentario
# cada línea debe tener su propia almohadilla
# utiliza solo caracteres alfanuméricos, guiones (-) o guiones bajos (_)

[F]

Forbidden (prohibido): le dice al servidor que devuelva al cliente un 403 Forbidden.

[L]

Last rule (última regla): le dice al servidor que deje de hacer rewrite una vez se procese la directiva anterior.

[N]

Next (siguiente): le dice a Apache que vuelva a ejecutar el rewrite hasta que todas las directivas de rewrite se hayan ejecutado.

[G]

Gone (ido): le dice al servidor que entregue el mensaje de estado Gone (no longer exists).

[P]

Proxy: le dice al servidor que gestione las peticiones mediante mod_proxy

[C]

Chain (cadena): le dice al servidor que encadene la regla actual con la anterior.

[R]

Redirect (redirigir): le dice a Apache que lance una redirección, haciendo que el navegador muestre la URL re-escrita/modificada.

[NC]

No Case: define cualquier argumento al que esté asociado como no afectado por mayúsculas-minúsculas, o sea, como case-insensitive, “NC” = “No Case”.

[PT]

Pass Through (pasar a través): le dice a mod_rewrite que pase la URL re-escrita de  nuevo a Apache para que la procese de nuevo.

[OR]

Or (o): especifica una lógica “o” que enlaza dos expresiones para que si una u otra se cumple se aplique la regla asociada a la misma.

[NE]

No Escape: le dice al servidor que redistribuya la salida sin escapar caracteres.

[NS]

No Subrequest (sin petición subyacente): le dice al servidor que se salte la directiva si hay peticiones internas subyacentes.

[QSA]

Append Query String: insta al servidor a que añada una cadena de petición al final de la expresión (URL).

Skip (saltar): le dice al servidor que se salte las siguientes “x” reglas si encuentra alguna coincidencia..

[E=variable:value]

Environmental Variable (variable del entorno): le dice al servidor que establezca la variable del entorno (“variable”) al valor definido (“value”).

[T=MIME-type]

Mime Type: declara el tipo mime del recurso al que está dirigido.

[]

especifica una clase de carácter, por el que cualquier carácter dentro de los corchetes se considerará una coincidencia, por ejemplo en [xyz], con x, y o z.

[]+

clase de carácter en el que cualquier combinación de elementos dentro de los corchetes se considera una coincidencia; por ejemplo [zyz]+ considerará una coincidencia cualquier número de equis, y griegas o zetas, o cualquier combinación de estos caracteres.

[^]

especifica que no está dentro de una clase de carácter; por ejemplo, [^xyz] considerará una coincidencia cualquier carácter que no sea ni x, ni y, ni z.

[a-z]

un guión (-)  entre dos caracteres dentro de corchetes ([]) define un rango de caracteres; por ejemplo [a-zA-Z] se refiere a todas las letras en mayúsculas y minúsculas de la a a la z.

a{n}

especifica un número exacto (n) del carácter precedente; por ejemplo x{3} se refiere exactamente a tres x.

a{n,}

especifica un número no o más del carácter precedente; por ejemplo x{3,} se refiere a tres x o más.

a{n,m}

especifica un rango de números, entre n y m, del carácter precedente; por ejemplo x{3,7} se refiere a tres, cuatro, cinco, seis o siete x.

()

se utiliza para agrupar juntos un grupo de caracteres, considerándolos como una sola unidad; por ejemplo (ayuda)?wordpress se referirá a wordpress, ya sea con o sin el prefijo ayuda.

^

indica el comienzo de una cadena de prueba de una expresión regular (regex); por ejemplo, empezar el argumento con el carácter anterior.

$

indica el fin de una cadena de prueba de una expresión regular; por ejemplo, terminar el argumento con el carácter anterior.

?

declara opcional el carácter precedente; por ejemplo cachopo? valdrá para cachopo y cachopos, mientras que cachopo(s)? se referirá tanto a cachopo como a cachopos; por ejemplo x? se refiere a ninguna o una x.

!

declara negación; ejemplo “!cadena” valdrá para todo menos para “cadena”.

.

un punto (o periodo) indica cualquier carácter arbitrario simple.

-

indica que “no se” haga rewrite de la URL, como en “...dominio.es.* - [F]”.

+

se refiere a uno o más caracteres del carácter precedente; por ejemplo, G+ se refiere a una o más Gs, mientras que simplemente “+” vale para uno o varios caracteres de cualquier tipo.

*

se refiere a cero o más de los caracteres precedentes; por ejemplo, puedes usar  “.*” como comodín.

|

declara un operador lógico “or”; por ejemplo, (x|y) vale para x o y.

\

escapa caracteres especiales ( ^ $ ! . * | ); por ejemplo, usa “\.” para indicar/escapar un punto literalmente.

\.

indica  un punto literal (escapado).

/*

cero o más barras.

.*

cero o más caracteres arbitrarios.

^$

define una cadena vacía.

^.*$

el patrón estándar para que valga cualquier cadena.

[^/.]

define un carácter que no es ni una barra ni un punto.

[^/.]+

define cualquiera números o caracteres que no contengan ni barra ni punto.

http://

esta es una declaración literal — en este caso la cadena de caracteres literal “http://”.

^domain.*

define una cadena que comienza con el término “domain”, probablemente precedido por cualquier número de caracteres.

^domain\.com$

define la cadena exacta “domain.com”.

-d

comprueba si la cadena es un directorio existente.

-f

comprueba si la cadena es un archivo existente.

-s

comprueba si el archivo de la cadena contiene un valor que no sea cero.

Códigos de redirección de cabecera

• 301 – movido permanentemente
• 302 – movido temporalmente
• 403 – prohibido
• 404 – no encontrado
• 410 – ido

5. Directivas básicas de .htaccess

Activar el rewrite básico

Hay servidores que no tiene el  “mod_rewrite” activo por defecto. Para que esté activo mod_rewrite (rewrite básico) en tu sitio añade la siguiente línea una vez en el archivo .htaccess de la carpeta raíz de tu web:

# activar rewrite básico
RewriteEngine on

Activar enlaces simbólicos

Activa los enlaces simbólicos (symlinks) añadiendo la siguiente directiva en el archivo .htaccess en el que los quieras tener disponibles. Ten en cuenta que para que funcione la directiva FollowSymLinks deben estar activados los privilegios AllowOverride Options en el archivo de configuración del servidor:

# activar enlaces simbólicos
Options +FollowSymLinks

Activar AllowOverride

Para que funcionen las directivas que requieren  AllowOverride, como FollowSymLinks, debe añadirse la siguiente directiva al archivo de configuración del servidor. Por cuestiones de rendimiento es importante activar AllowOverride solamente en el directorio o directorios concretos en los que sea necesaria. En el siguiente ejemplo de código se activan privilegios de  AllowOverride solo en un directorio concreto (/www/remplaza/esto/con/el/directorio/real). :

# activa privilegios de allowoverride
<Directory /www/remplaza/esto/con/el/directorio/real>
AllowOverride Options
</Directory>

Renombrar el archivo .htaccess

No todos los sistemas permiten el formato de solo extensión de los archivos .htaccess. Afortunadamente puedes renombrarlo a lo que quieras, mientras el nombre sea válido en tu sistema. Esta directiva debe colocarse en el archivo de configuración del servidor o no funcionará:

# renombrar los archivos
AccessFileName ht.access

Nota: Si renombras los archivos .htaccess recuerda que debes actualizar cualquier ajuste asociado a los nombres previos. Por ejemplo, si estás protegiendo tu archivo .htaccess con FilesMatch, recuerda informarle de los nuevos nombres:

# proteger archivos htaccess renombrados
<FilesMatch "^ht\.">
Order deny,allow
Deny from all
</FilesMatch>

Aprovecha las reglas definidas en httpd.conf

Puedes ahorrar tiempo, esfuerzo, y sobre todo recursos, definiendo reglas repetidas para varios alojamientos virtuales o solo para uno a través del archivo httpd.conf. Luego solo tienes que indicar a los archivos .htaccess afectados que hereden las reglas de httpd.conf incluyendo esta directiva:

RewriteOptions Inherit

6. Mejora el rendimiento de tu web con .htaccess

Uno de los usos más habituales, y agradecidos, de las directivas de .htaccess es el de mejorar el rendimiento de una web, así que vamos a empezar por ahí.

Mejora el rendimiento con AllowOverride

Recuerda antes de nada que puedes limitar bajadas de rendimiento activando  AllowOverride solo en los directorios en los que sea necesaria. Un ejemplo que verás muy claro es que si activas AllowOverride en todo tu sitio el servidor debe revisar cada directorio, buscando archivos .htaccess que puede que ni existan. Para evitarlo debemos desactivar AllowOverride en el fichero .htaccess de la carpeta raíz del sitio y luego activarlo solo en los directorios donde sea necesaria desde el archivo de configuración del servidor. Si no tuvieses acceso a este archivo de configuración del servidor y necesitas privilegios de AllowOverride no uses esta directiva:

# mejorar rendimiento desactivando allow override
AllowOverride None

Indicando el conjunto de caracteres

Podemos evitar errores 500 indicando el parámetro del conjunto de caracteres por defecto antes de cargarlos. Por supuesto, remplaza el “utf-8″ del ejemplo si usas otro conjunto de caracteres en tu web:

# indicamos el conjunto de caracteres por defecto
AddDefaultCharset utf-8

Ahorrando ancho de banda

Para aumentar el rendimiento en servidores con PHP activo (o sea, todos en los que tengas un WordPress) añade la siguiente directiva:

# ahorra ancho de banda en servidores con PHP activo
<ifmodule mod_php4.c>
php_value zlib.output_compression 16386
</ifmodule>

Desactivando la firma del servidor

En esta ocasión desactivamos la firma del servidor que podría identificarlo:

# desactiva la firma del servidor
ServerSignature Off

Estableciendo la zona horaria del servidor

Con esta directiva le indicamos al servidor que se sincronice cronológicamente de acuerdo a la zona horaria de la localización que le indicamos:

# establecemos la zona horaria del servidor
SetEnv TZ Spain/Madrid

Estableciendo la dirección de email del administrador del servidor

Aquí especificamos al dirección de correo por defecto del administrador del servidor:

# establecemos el email del administrador del servidor
SetEnv SERVER_ADMIN admin@dominio.es

Mejora la velocidad de transferencia activando la cache de archivos

Podemos mejorar enormemente la velocidad de transferencia de nuestro sitio activando la cache de archivos. Usaremos el tiempo en segundos para indicar la duración del contenido en cache:

# cache de imágenes y contenido flash un mes
<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

# cache de texto, css, y archivos javascript una semana
<FilesMatch ".(js|css|pdf|txt)$">
Header set Cache-Control "max-age=604800"
</FilesMatch>

# cache de archivos html htm un día
<FilesMatch ".(html|htm)$">
Header set Cache-Control "max-age=43200"
</FilesMatch>

# usamos esto para activar cache mínima durante tareas de desarrollo en el sitio
<FilesMatch "\.(flv|gif|jpg|jpeg|png|ico|js|css|pdf|swf|html|htm|txt)$">
Header set Cache-Control "max-age=5"
</FilesMatch>

# desactivamos la cache para scripts y archivos dinámicos concretos
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>

# método alternativo para cache de archivos
ExpiresActive On
ExpiresDefault A604800 # 1 week
ExpiresByType image/x-icon A2419200 # 1 month
ExpiresByType application/x-javascript A2419200 # 1 month
ExpiresByType text/css A2419200 # 1 month
ExpiresByType text/html A300 # 5 minutes
# disable caching for scripts and other dynamic files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
ExpiresActive Off
</FilesMatch>

Conversión de intervalos comunes de tiempo en segundos:

• 300 = 5 minutos
• 2700 = 45 minutos
• 3600 = 1 hora
• 54000 = 15 horas
• 86400 = 1 día
• 518400 = 6 días
• 604800 = 1 semana
• 1814400 = 3 semanas
• 2419200 = 1 mes
• 26611200 = 11 meses
• 29030400 = 1 año = no expira nunca

Estableciendo el idioma por defecto

Este es un modo sencillo de establecer el idioma por defecto para las páginas que sirvas en tu alojamiento:

# establece el idioma por defecto
DefaultLanguage es-ES

Declarando tipos MIME específicos/adicionales

# añade varios tipos mime
AddType application/x-shockwave-flash .swf
AddType video/x-flv .flv
AddType image/x-icon .ico

Enviando el conjunto de caracteres y otras cabeceras sin meta tags

# envía la tag de idioma y juego de caracteres por defecto
# AddType 'text/html; charset=UTF-8' html
AddDefaultCharset UTF-8
DefaultLanguage es-ES

Limitando métodos de petición GET y PUT al servidor

# limita métodos GET y PUT de peticiones al servidor
Options -ExecCGI -Indexes -All
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS|HEAD) RewriteRule .* - [F]

Procesando archivos selectivamente según el método de petición

# procesar archivos según el método de petición al servidor
Script PUT /cgi-bin/upload.cgi
Script GET /cgi-bin/download.cgi

Ejecutando varios tipos de archivo mediante un script cgi

En aquellas situaciones especiales en las que necesitemos procesar varios tipos de archivo con algún script cgi específico mejor definirlo:

# ejecutar todos los archivos png mediante png-script.cgi
Action image/png /cgi-bin/png-script.cgi

7. Mejora la seguridad de tu web con .htaccess

Otro de los usos más comunes de .htaccess es para aumentar la seguridad de una web, y disponemos de un buen montón de trucos para lograrlo.

Evita acceso a .htaccess

Añade el código siguiente a tu fichero .htaccess para añadir una capa extra de seguridad. Lo que consigue es que cualquier intento de acceso al fichero .htaccess resulte en un mensaje de error 403. No olvides, no obstante, que nuestra primera capa de defensa es proteger los archivos .htaccess cambiando los permisos a 644 con CHMOD, como hemos visto antes.:

# asegurando el archivo htaccess
<Files .htaccess>
order allow,deny
deny from all
</Files>

Evita el acceso a un archivo concreto

Podemos aplicar la misma directiva a cualquier otro archivo que queramos proteger, como el fichero “contabilidad.pdf” del ejemplo siguiente:

# evitar la visualizlación de un archivo concreto
<files contabilidad.pdf>
order allow,deny
deny from all
</files>

Evita el acceso a varios archivos

Para evitar el acceso a varios tipos de archivo añade el siguiente código y modifica la lista de tipos de archivo entre barras verticales para que se adapte a tus necesidades:

<FilesMatch "\.(htaccess|htpasswd|ini|phps|fla|psd|log|sh)$">
Order Allow,Deny
Deny from all
</FilesMatch>

Evita la navegación de directorios no autorizada

Podemos evitar la navegación por los directorios indicando al servidor que devuelva un mensaje de “Prohibido – Se requiere autorización” a cualquier intento de ver un directorio. Esto sucede cuando en algún directorio no hay una página de índice (index.html o index.php), y si no añades algún control de seguridad cualquier visitante podría ver el contenido de ese directorio desde  su navegador. Para evitarlo solo tienes que añadir la siguiente regla:

# desactivar la navegación de directorios
Options All -Indexes

Por el contrario, si quieres permitir este tipo de navegación, usa la siguiente directiva:

# activar la navegación de directorios
Options All +Indexes

Otro modo de evitar que el servidor muestre los directorios es con la siguiente directiva:

# evitar el listado de carpetas
IndexIgnore *

Y, para finalizar, puedes usar la directiva IndexIgnore para evitar que se muestren ciertos tipos de archivo:

# evitar que se muestren ciertos tipos de archivo
IndexIgnore *.wmv *.mp4 *.avi *.etc

Cambia la página índice por defecto

Esta regla le dice al servidor que busque y muestre “tienda.html” como el índice por defecto del directorio. Debe estar en el fichero .htaccess del directorio en el que quieras remplazar el fichero índice por defecto, por ejemplo “index.html”:

# sirve una página índice alternativa a la por defecto
DirectoryIndex tienda.html

Con la siguiente regla vamos un paso más allá y le decimos al servidor que revise los archivos del directorio raíz y muestre la primera que se encuentre en la lista (de izquierda a derecha), si no existe la siguiente y así sucesivamente:

# sirve el primer fichero disponible de la lista como índice por defecto
DirectoryIndex tienda.html index.php index.html default.htm

Oculta extensiones de script

Otra manera de mejorar la seguridad es ocultar los lenguajes script remplazando las extensiones reales de los scripts con extensiones de pega a tu elección. Por ejemplo, cambiando la extensión  “.foo” a “.php”:

# sirve archivos foo como archivos php
AddType application/x-httpd-php .foo

# sirve archivos foo como archivos cgi
AddType application/x-httpd-cgi .foo

Limita acceso a la Red de Área Local (LAN)

# limita el acceso a la red de área local
<Limit GET POST PUT>
order deny,allow
deny from all
allow from 192.168.0.0/33
</Limit>

Asegura directorios por dirección IP y/o dominio

En este ejemplo todas las direcciones IP tienen permitido el acceso excepto 16.654.98.123 y el dominio “dominio.es”:

# permitir a todas excepto a las indicadas
<Limit GET POST PUT>
order allow,deny
allow from all
deny from 16.654.98.123
deny from .*dominio\.es.*
</Limit>

En este otro ejemplo se deniega acceso a todas las direcciones IP excepto a la 16.654.98.123 y al dominio “dominio.es” :

# denegar acceso a todas excepto a las indicadas
<Limit GET POST PUT>
order deny,allow
deny from all
allow from 16.654.98.123
allow from .*dominio\.es.*
</Limit>

A continuación vamos un poco más allá y bloqueamos visitantes indeseables basándonos en el dominio de referencia. También puedes ahorrar ancho de banda bloqueando tipos de archivo específicos como vimos antes de los dominios de referencia. Simplemente cambia los nombres de dominio del ejemplo por tus odiados favoritos::

# bloquea visitantes desde los siguientes dominios
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} robaperas\.info [NC,OR]
RewriteCond %{HTTP_REFERER} pagafantas\.net [NC,OR]
RewriteRule .* - [F]
</ifModule>

Impide o permite acceso al dominio a un rango de direcciones IP

Hay varias maneras efectivas de bloquear un rango de direcciones IP mediante .htaccess y vamos a ver varias. El primero que tenemos bloquea un rango de IPs especificado por su número CIDR (Classless Inter-Domain Routing). Este método es muy útil para bloquear super spammers como RIPE, Optinet y similares. Si, por ejemplo, te das cuenta de que estás añadiendo un montón de líneas de directivas Apache deny para direcciones que empiezan con los mismos números, elige una de ellas y haz un whois. Bajo el listado de resultados del whois encontrarás el valor CIDR que representa a cada dirección IP asociada a esa red en particular. Así que bloquear mediante el CIDR es un modo muy efectivo de evitar que un montón de IPs del mismo atacante intenten acceder a tu web. Aquí tienes un ejemplo muy genérico de bloqueo por CIDR, cambia los números a los que quieras bloquear:

# bloquear rango de IPs por número CIDR
<Limit GET POST PUT>
order allow,deny
allow from all
deny from 10.1.0.0/16
deny from 80.0.0/8
</Limit>

La situación contraria sería permitir el acceso a una IP por número CIDR:

# permitir un rango IP por número CIDR
<Limit GET POST PUT>
order deny,allow
deny from all
allow from 10.1.0.0/16
allow from 80.0.0/8
</Limit>

Otra manera eficaz de bloquear un rango completo de direcciones IP requiere truncar dígitos hasta que aparezca el rango buscado. Como una dirección IP se lee de izquierda a derecha su valor representa una dirección específica. Por ejemplo, una dirección IP 99.88.77.66 se refiere a una dirección IP específica y única. Ahora bien, si quitamos los dos últimos dígitos (66) de la dirección se referirá a cualquier dirección IP que empiece con el resto de números, o sea, que 99.88.77 vale para 99.88.77.1, 99.88.77.2, … 99.88.77.99, …y así sucesivamente.

Y si seguimos con el mismo sistema, quitando otro par de dígitos de la dirección, su rango se amplía para referirse a cualquier dirección IP que empiece con 99.88.xx.xx, así que bloquearías 65.536 direcciones IP (256*256). Siguiendo esta lógica es posible bloquear todo un rango de direcciones IP a distintos grados de necesidad. El siguiente ejemplo es una muestra de lo que estamos hablando:

# bloquear un rango de IP por truncado de números
<Limit GET POST PUT>
order allow,deny
allow from all
deny from 99.88.77.66
deny from 99.88.77.*
deny from 99.88.*.*
deny from 99.*.*.*
</Limit>

Y para hacerlo al contrario, también podemos dar permisos a rangos de IPs usando el mismo sistema:

# permitir a un rango de IP por truncado de números
<Limit GET POST PUT>
order deny,allow
deny from all
allow from 99.88.77.66
allow from 99.88.77.*
allow from 99.88.*.*
allow from 99.*.*.*
</Limit>

Bloquea o permite acceso a múltiples direcciones IP en una sola línea

Podemos ahorrar algo de espacio bloqueando rangos de direcciones IP en una sola línea:

# bloqueo de dos direcciones IP concretas
deny from 99.88.77.66 11.22.33.44
# bloqueo de tres direcciones IP concretas
deny from 99.88 99.88.77 11.22.33

Y, de igual modo, podemos permitir acceso a varias IPs en una sola línea con el mismo truco:

# permiso de acceso a dos direcciones IP concretas
allow from 99.88.77.66 11.22.33.44
# permiso de acceso a tres direcciones IP concretas
allow from 99.88 99.88.77 11.22.33

Más reglas para bloquear y permitir acceso a direcciones IP

Otras posibles reglas para bloquear diversos tipos de direcciones IP serían las siguientes. Estas reglas se pueden adaptar igualmente para dar permiso a valores concretos de IPs simplemente cambiando la directiva  deny por allow:

# bloquear un dominio parcial a través de valores de red o máscara de red
deny from 99.1.0.0/255.255.0.0

# bloquear un solo dominio
deny from 99.88.77.66

# bloquear dominio.es pero permitir a sub.dominio.es
order deny,allow
deny from dominio.es
allow from sub.dominio.es

Para el “hotlinking” y servir contenido alternativo

Ya hemos hablado varias veces del hotlinking, esa  plaga de roba webs que rulan por Internet. Si quieres que se muestre un contenido distinto en aquellos sitios que te roban tus publicaciones copiando y pegando directamente o desde agregadores RSS puedes usar el siguiente código. Por supuesto cambia las rutas y nombres de archivo del ejemplo por los tuyos. Ten en cuenta también que este método bloquea todos los servicios RSS, como Feedburner o Feedly. Si quieres un método más refinado usa el de este enlace:

# parar el hotlinking y mostrar contenido alternativo
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?dominio\.es/.*$ [NC]
RewriteRule .*\.(gif|jpg)$ http://www.dominio.es/eresunrobaperas.jpg [R,NC,L]
</ifModule>

Si quieres mostrar una página de error en vez de una imagen desagradable, remplaza la línea que contiene la RewriteRule del código anterior por la siguiente línea:

# servir una página stander de 403 prohibido
RewriteRule .*\.(gif|jpg)$ - [F,L]

Si, por el contrario, quieres permitir que algún servicio o sitio concreto que no sea el tuyo pueda mostrar tus imágenes añade el siguiente código después de la línea que contiene la cadena “dominio.es” del ejemplo anterior:

# permitir hotlinking del siguiente sitio
RewriteCond %{HTTP_REFERER} !^http://(www\.)?webamiga\.es/.*$ [NC]

Bloquea robotos maliciosos, extractores de webs y navegadores offline

A continuación veremos unas reglas muy útiles para evitar que nos inyecten código. Todos los agentes que pongamos en la lista tendrán acceso denegado y recibirán un mensaje de error. Hay muy buenas listas por ahí, así que no te quedes en el ejemplo. Y, por favor, NO incluyas el “[OR]” en la última directiva RewriteCond o tu servidor se caerá mostrando múltiples errores 500 en todas las páginas:

# denegar acceso a robots maliciosos, extractores de webs y navegadores offline
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^Anarchie [OR]
RewriteCond %{HTTP_USER_AGENT} ^ASPSeek [OR]
RewriteCond %{HTTP_USER_AGENT} ^attach [OR]
RewriteCond %{HTTP_USER_AGENT} ^autoemailspider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xenu [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus.*Webster [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
RewriteRule ^.* - [F,L]

También puedes mostrar un mensaje de error más amistoso enviando a tus molestos amigos a un sitio a tu elección simplemente remplazando la directiva RewriteRule de la última línea del código anterior con alguno de los siguientes ejemplos:

# los mandamos a un sitio cachondo a nuestra elección
RewriteRule ^.*$ http://www.disney.com [R,L]

También, siendo algo más malo, puedes mandarles a un agujero negro virtual o a una dirección de email falsa:

# los mandamos a un agujero negro virtual o a una dirección de email falsa
RewriteRule ^.*$ http://english-61925045732.spampoison.com [R,L]

Puedes también incluir sitios de referencia específicos a tu lista negra usando HTTP_REFERER:

RewriteCond %{HTTP_REFERER} ^http://www.dominiomalo.org$
RewriteRule !^http://[^/.]\.tudominio\.es.* - [F,L]

Otros divertidos trucos de bloqueo

Aunque las siguientes técnicas de redirección están pensadas para bloquear y redirigir a sitios indeseables también puedes usarse para redirecciones más amables y útiles:

# redirigir cualquier petición de lo que sea de un sitio spam a otro
RewriteCond %{HTTP_REFERER} ^http://.*sitiospam.*$ [NC]
RewriteRule .* http://www.otrositiospam.com [R]

# redirigir todas las peticiones de un sitio a la imagen de otro sitio de spam
RewriteCond %{HTTP_REFERER} ^http://.*sitiospam.*$ [NC]
RewriteRule .* http://www.otrositiospam/algo.jpg [R]

# redirigir tráfico de una dirección o rango a otro sitio
RewriteCond %{REMOTE_ADDR} 192.168.10.*
RewriteRule .* http://www.otrositiospam.com/index.html [R]

Aún más trucos para bloquear escoria

Lo que sigue es una serie de códigos paso a paso que te ayudarán a bloquear todo tipo de entidades. No van por separado sino combinados entre ellos así que observa lo que hacen y adáptalos a tus necesidades::

# establecemos variables para agentes de usuario, referencias y direcciones IP
SetEnvIfNoCase User-Agent ".*(user-agent-you-want-to-block|php/perl).*" BlockedAgent
SetEnvIfNoCase Referer ".*(block-this-referrer|and-this-referrer|and-this-referrer).*" BlockedReferer
SetEnvIfNoCase REMOTE_ADDR ".*(666.666.66.0|22.22.22.222|999.999.99.999).*" BlockedAddress

# establecemos la variable para clacker red clase B que provenga de  una red a bloquear determinada
SetEnvIfNoCase REMOTE_ADDR "66.154.*" BlockedAddress

# establecemos la variable para dos redes clase B concretas de ejemplo 198.25.0.0 y 198.26.0.0
SetEnvIfNoCase REMOTE_ADDR "198.2(5|6)\..*" BlockedAddress

# denegamos acceso a cualquiera que se ajuste a los anteriores códigos y les enviamos un mensaje 403
<Limit GET POST PUT>
order deny,allow
deny from env=BlockedAgent
deny from env=BlockedReferer
deny from env=BlockedAddress
allow from all
</Limit>

Protege con contraseña archivos, directorios y más…

Un modo exhaustivo de asegurar un sitio es usar autenticación mediante usuario y contraseña, pudiendo proteger archivos concretos, varios archivos, directorios o incluso protegerse de cualquier IP excepto de la especificada. Hay un paso previo y es la creación del fichero .htpasswd, que  puedes generar aquí. Adapta los siguientes códigos a tus especificaciones:

# proteger con contraseña un archivo
<Files secure.php>
AuthType Basic
AuthName "Aviso"
AuthUserFile /home/ruta/.htpasswd
Require valid-user
</Files>

# proteger con contraseña varios archivos
<FilesMatch "^(execute|index|secure|insanity|biscuit)*$">
AuthType basic
AuthName "Desarrollador"
AuthUserFile /home/ruta/.htpasswd
Require valid-user
</FilesMatch>

# proteger con contraseña el directorio en el que está alojado el htaccess
AuthType basic
AuthName "Este directorio está protegido"
AuthUserFile /home/ruta/.htpasswd
AuthGroupFile /dev/null
Require valid-user

# proteger con contraseña el directorio para cada IP excepto la especificada
# crea un fichero htaccess en cada directorio para protegerlo
AuthType Basic
AuthName "Personal"
AuthUserFile /home/ruta/.htpasswd
Require valid-user
Allow from 99.88.77.66
Satisfy Any

Nota: la mayoría de proveedores de alojamiento actuales ofrecen la protección de carpetas y archivos mediante contraseña desde su panel de control, evitando la necesidad de crear y modificar ficheros manualmente.

Requerir SSL (Secure Sockets Layer)

Lo siguiente es un método excelente para requerir SSL:

# requerir SSL
SSLOptions +StrictRequire
SSLRequireSSL
SSLRequire %{HTTP_HOST} eq "dominio.es"
ErrorDocument 403 https://dominio.es

# requerir SSL sin mod_ssl
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

Automáticamente CHMOD varios tipos de archivo

Este otro método es genial para hacer cambios de permiso mediante CHMOD a varios tipos de archivo. Pon estas reglas en el .htaccess de la carpeta raíz para que afecte a todos los tipos de archivo, o sitúalo en una carpeta concreta para que afecte solo a los archivos de la misma. Por supuesto, modifica los archivos del código a lo que quieras modificar tu:

# cambiar ajustes CHMOD para archivos concretos
# recuerda nunca poner CHMOD 777 a menos que sepas lo que estás haciendo
# los archivos que requieran acceso global de escritura deben usar CHMOD 766 en vez de 777
# puedes hacer que ciertos tipos de archivo sean privados con CHMOD en 400
chmod .htpasswd files 640
chmod .htaccess files 644
chmod php files 600

Oculta todas las extensiones de archivo

Este método disfraza todos los tipos de archivo, sus extensiones de archivo, y los muestra como si fuesen archivos .php (o lo que tu quieras):

# disfraza todas las extensiones de archivo como si fuesen php
ForceType application/x-httpd-php

Protégete contra ataques de denegación de servicio (DOS) limitando el tamaño de carga de archivo

Una manera de proteger tu servidor de ataques DOS es limitar el tamaño máximo permitido para carga de archivos. En este ejemplo limitamos el tamaño de subida a 10240000 bytes, el equivalente a 10 megabytes. Lógicamente, este código solo es útil si permites subir archivos a tu sitio:

# protección contra ataques DOS limitando el tamaño de carga de archivos
LimitRequestBody 10240000

Asegura directorios desactivando la ejecución de scripts

Para evitar la ejecución de scripts maliciosos nada mejor que asegurar los directorios que puedan verse afectados. Cambia las extensiones de script a lo que necesites:

# asegurar directorio desactivando la ejecución de scripts
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI

8. Trucos de usabilidad

Miminiza el parpadeo de imagen por CSS en IE6

Con las siguientes reglas minimizamos o incluso eliminados el parpadeo de imagen de fondo por CSS en Internet Explorer 6:

# minimizar parpadeo de imagen en IE6
ExpiresActive On
ExpiresByType image/gif A2592000
ExpiresByType image/jpg A2592000
ExpiresByType image/png A2592000

Sirve páginas de error personalizadas

Usa las siguientes reglas para mostrar tus propias páginas de error personalizadas. Simplemente recuerda cambiar la ruta y archivos por los que hayas creado tu. Ten en cuenta que tus páginas de error deben pesar más de 512 bytes para que no las ignore Internet Explorer:

# servir paginas de error personalizadas
ErrorDocument 400 /errores/400.html
ErrorDocument 401 /errores/401.html
ErrorDocument 403 /errores/403.html
ErrorDocument 404 /errores/404.html
ErrorDocument 500 /errores/500.html

Ofrece un documento de error global

# ofrece un documento de error global
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*$ /carpeta/error.php [L]

Usa comprobación de errores de ortografía básicos en URLs

El siguiente truco es magia pura para corregir errores básicos de ortografía en URLs:

# corregir automaticamente errores de ortografia
<IfModule mod_speling.c>
CheckSpelling On
</IfModule>

Indica al navegador que descargue los archivos multimedia en vez de mostrarlos

Normalmente los navegadores tratan de reproducir los archivos multimedia cuando ofreces un enlace a los mismos. El siguiente método fuerza a que se muestre un mensaje en el que ofrece reproducirlos o descargarlos:

# indica al navegador que descargue los archivos multimedia
AddType application/octet-stream .avi
AddType application/octet-stream .mpg
AddType application/octet-stream .wmv
AddType application/octet-stream .mp3

Indica al servidor que muestre el código fuente de los tipos de archivo dinámicos

En ocasiones puede que quieras mostrar el contenido de archivos dinámicos en vez de ejecutarlos como scripts. Crea un directorio donde situar estos archivos que prefieres que se visualicen en vez de ejecutarlos y añade la siguiente línea de código al .htaccess de ese directorio:

RemoveHandler cgi-script .pl .py .cgi

Redirige a los visitantes a un sitio temporal durante tareas de desarrollo o mantenimiento

Cuando estás haciendo tareas de desarrollo, reparación o mantenimiento, es buena idea disponer de un sitio alternativo donde ofrecer contenido a tus visitantes, y sobre todo avisarles de que el sitio no está desaparecido sino simplemente mejorándose. Por supuesto, debes disponer del sitio temporal y adaptar el código a la ruta que elijas:

# redirigir a los visitantes a un sitio alternativo
ErrorDocument 403 http://www.sitio-alternativo.com
Order deny,allow
Deny from all
Allow from 99.88.77.66

Pide contraseña de acceso a los visitantes durante tareas de desarrollo o mantenimiento

Otra posible solución es esconder tu sitio durante las tareas de mantenimiento o mejora. Para ello bloquearemos los acceso normales pidiendo usuario y contraseña mediante el método anterior de .httppasswd y permitiremos acceso a IPs concretas:

# contraseña para los visitantes
AuthType basic
AuthName "Este sitio está actualmente en mantenimiento"
AuthUserFile /home/ruta/.htpasswd
AuthGroupFile /dev/null
Require valid-user
# permitimos al webmaster y otros acceder
Order Deny,Allow
Deny from all
Allow from 111.222.33.4
Allow from favorite.validation/services/
Allow from googlebot.com
Satisfy Any

Evita acceso a archivos o directorios durante periodos de tiempo concretos

Estupendo truco para evitar accesos por periodos horarios. Muy friki pero útil en ocasiones:

# evitar acceso a media noche
RewriteCond %{TIME_HOUR} ^12$
RewriteRule ^.*$ - [F,L]

# evitar accesos mientras comes
RewriteCond %{TIME_HOUR} ^(12|13|14|15)$
RewriteRule ^.*$ - [F,L]

9. Trucos de redirección

Nota importante relativa a las redirecciones a través de mod_rewrite

Para que funcionen las redirecciones que usen la directiva mod_rewrite es necesario que esté activo RewriteEngine. Es una práctica común activar la directiva  mod_rewrite, ya sea en el archivo de configuración del servidor o al principio del fichero .htaccess en la carpeta raíz del sitio. Si la directiva mod_rewrite no está incluida en alguno de estos dos lugares debería añadirse en la primera línea de cualquier bloque de código que use una función de rewrite (p.ej., mod_rewrite), pero solo debe incluirse una sola vez en cada archivo .htaccess:

# se inicia y activa el motor rewrite
RewriteEngine on

Redirección desde http://www.dominio.es a http://dominio.es

Se puede usar una redirección 301 para definir una redirección permanente desde la versión con www de un dominio a su respectiva versión sin www. Eso sí, comprueba que no hay errores siempre que hagas una redirección 301, hay incluso herramientas de comprobación de cabeceras del servidor para ello. También es importante incluir siempre una barra “/” el enlazar directorios, y – muy importante – no marees a los buscadores, sé consistente con la decisión de www o no www, o lo usas siempre o nunca pero no una mezcla:

# redirección permanente de dominio www a sin www
RewriteEngine on
Options +FollowSymLinks
RewriteCond %{HTTP_HOST} ^www\.dominio\.es$ [NC]
RewriteRule ^(.*)$ http://dominio.es/$1 [R=301,L]

Redirección desde http://viejo-dominio.es a http://nuevo-dominio.es

Un modo básico de cambiar de un dominio viejo a  uno nuevo (en el que no cambien los nombres de archivos y carpetas, importante) es crear una regla de Rewrite para redirigir del viejo dominio al nuevo. Nada más hacer la redirección puede que aún veas la URL del viejo dominio en la barra de direcciones del navegador, así que para comprobar que lo has hecho bien haz clic en cualquier enlace interno o imagen para comprobar que se ha hecho la redirección y todo está en el nuevo:

# redireccion de un dominio viejo al nuevo
RewriteEngine On
RewriteRule ^(.*)$ http://nuevo-dominio.es/$1 [R=301,L]

Redirección a una dirección concreta en base a caracteres concretos

No es tan raro. Imagina que quieres redirigir cualquier petición que contenga el carácter “seo” a una categoría concreta situada en http://ayudawp.com, pues entonces remplazaremos en el ejemplo la cadena “texto-buscado” por “seo” y, lógicamente, la URL de destino:

# redirigir cualquier variación de un carácter específico a una dirección concreta
RewriteRule ^texto-buscado http://ayuda.com/categoria/seo/ [R]

Y aquí otros dos métodos para hacer este tipo de tareas especiales:

# redirigir variaciones de URL al mismo directorio de del mismo servidor
AliasMatch ^/espec(ie|ies) /www/docs/destino

# redirigir variaciones de URL al mismo  directorio de otro servidor
RedirectMatch ^/[eE]spec(ie|ies) http://otrodominio.es

Otros curiosos pero estupendos trucos de redirección

# redirección de un sitio completo con 301
redirect 301 / http://www.dominio.es/

# redirigir un archivo concreto con 301
redirect 301 /current/currentfile.html http://www.newdomain.com/new/newfile.html

# redirigir un sitio completo con redirección permanente
Redirect permanent / http://www.dominio.es/

# redirigir una página o directorio con redirección permanente
Redirect permanent viejo_archivo.html http://www.nuevo-dominio.es/nuevo_archivo.html
Redirect permanent /viejo_directorio/ http://www.nuevo-dominio/nuevo_directoriio/

# redirigir un archivo usando RedirectMatch
RedirectMatch 301 ^.*$ http://www.dominio.es/index.html

Nota: Al redirigir archivos concretos utiliza la regla de Apache Redirect para los archivos dentro de un mismo dominio y la regla de Apache RewriteRule para cualquier otro dominio, especialmente si son distintos. La regla RewriteRule es más potente que la regla Redirect, y debería funcionar de manera más eficaz.

Por tanto, usaremos los siguientes códigos para conseguir una redirección más precisa y potente (la primera línea redirige un archivo, la segunda un directorio y la tercera un dominio):

# redirigir archivos directorios y dominios con RewriteRule
RewriteRule http://viejo-dominio.es/viejo-archivo.html http://nuevo-dominio.es/nuevo-archivo.html
RewriteRule http://viejo-dominio.es/viejo-directorio/ http://nuevo-dominio.es/nuevo-directorio/
RewriteRule http://viejo-dominio.es/ http://nuevo-dominio.es/

Envia a los visitantes a un subdominio

This rule will ensure that all visitors are viewing pages via the subdomain of your choice. Edit the “subdomain”, “domain”, and “tld” to match your subdomain, domain, and top-level domain respectively:

# send visitors to a subdomain
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{HTTP_HOST} !^subdomain\.domain\.com$ [NC]
RewriteRule ^/(.*)$ http://subdomain.domain.tld/$1 [L,R=301]

Más diversión con RewriteCond y RewriteRule

# rewrite solo si no se encuentra el archivo
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+)especial\.html?$ cgi-bin/especial/especial-html/$1

# rewrite solo si no se encuentra una imagen
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule imagenes/especial/(.*).gif cgi-bin/especial/mkgif?$1

# reglas seo de rewrite para varias carpetas
RewriteRule ^(.*)/aud/(.*)$ $1/archivos-audio/$2 [L,R=301]
RewriteRule ^(.*)/img/(.*)$ $1/archivos-imagen/$2 [L,R=301]
RewriteRule ^(.*)/fla/(.*)$ $1/archivos-flash/$2 [L,R=301]
RewriteRule ^(.*)/vid/(.*)$ $1/archivos-video/$2 [L,R=301]

# analisis de paquetes del navegador - sniffers - mediante entornos variables de htaccess
RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
RewriteRule ^/$ /index-for-mozilla.html [L]
RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
RewriteRule ^/$ /index-for-lynx.html [L]
RewriteRule ^/$ /index-for-all-others.html [L]

# redirigir una query a la búsqueda de Google
Options +FollowSymlinks
RewriteEngine On
RewriteCond %{REQUEST_URI} .google\.php*
RewriteRule ^(.*)$ ^http://www.google.com/search?q=$1 [R,NC,L]

# denegar una petición en base al metodo de la petición
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS|HEAD)$ [NC]
RewriteRule ^.*$ - [F]

# redirigir las cargas a un sitio mejor
RewriteCond %{REQUEST_METHOD} ^(PUT|POST)$ [NC]
RewriteRule ^(.*)$ /cgi-bin/procesador-cargas.cgi?p=$1 [L,QSA]

Más diversión con Redirect 301 y RedirectMatch 301

# redirección seo para un solo archivo
Redirect 301 /viejo-directorio/viejo-archivo.html http://dominio.es/nuevo-directorio/nuevo-archivo.html

# redireccion seo para varios archivos
# redirige todos los archivos de un directorio cuyas primeras letras sean xyz
RedirectMatch 301 /directorio/xyz(.*) http://dominio.es/$1

# redireccion seo para redigirir un sitio entero a otro dominio
Redirect 301 / http://otro-dominio.es

10. Trucos especiales para WordPress

Hemos visto muchos trucos de .htaccess para WordPress pero aquí tienes los conceptos básicos y también un truco útil que es posible que no conocieses.

Los “permalinks” de WordPress

Ya sabrás que WordPress crea el archivo .htaccess cuando cambias los enlaces permanentes (permalinks) a alguna otra cosa distinta de los que vienen por defecto, y además añade unas reglas básicas para que funcionen. Esta configuración básica sería la siguiente:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Ahora bien, si WordPress está instalado en  un subdirectorio (por ejemplo “blog”) entonces las directivas serían así

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>
# END WordPress

Asegura los formularios de contacto de WordPress

Un modo de asegurar los por defecto inseguros formularios de contacto de WordPress es verificar el dominio desde donde se invoca al formulario. Recuerda cambiar el dominio y página de contacto del ejemplo por los tuyos:

# asegurar formularios de contacto de wordpress depende de quien lo invoca
RewriteCond %{HTTP_REFERER} !^http://www.dominio.es/.*$ [NC]
RewriteCond %{REQUEST_POST} .*contacto.php$
RewriteRule .* - [F]

11. Trucos extra

Activa SSI para tipos de archivo HTML/SHTML

# activar SSI para tipos de archivo HTML y o SHTML
AddType text/html .html
AddType text/html .shtml
AddHandler server-parsed .html
AddHandler server-parsed .shtml
AddHandler server-parsed .htm

Da acceso CGI a un directorio concreto

# dar acceso CGI a un directorio concreto
Options +ExecCGI
AddHandler cgi-script cgi pl
# para activar todos los scripts de un directorio usa lo siguiente
SetHandler cgi-script

Desactiva magic_quotes_gpc en servidores con PHP activo

# desconectar magic_quotes_gpc en servidores con PHP activo
<ifmodule mod_php4.c>
php_flag magic_quotes_gpc off
</ifmodule>

Y hasta aquí. Espero que hayas aprendido mucho, y sino guarda este artículo en tus favoritos o donde acostumbres, para tenerlo de referencia futura.

Si se me ha pasado algo importante me lo comentas y lo incorporamos, así aprendemos todos.

Una de las medidas de seguridad básica en un servidor, y por supuesto en WordPress, es establecer adecuadamente los permisos de los archivos y carpetas. La instalación estándar de WordPress normalmente asigna los permisos adecuados a archivos y carpetas, pero a veces nos encontramos con sorpresas.

Ya sea por modificaciones manuales que no recordamos, o por accesos no controlados, o debido a modificaciones realizadas por plugins y scripts, a veces no todos los archivos y carpetas de WordPress tienen los permisos adecuados para garantizar al mismo tiempo usabilidad y seguridad.

Afortunadamente hay constantes de WordPress que podemos añadir a nuestro archivo de configuración (wp-config.php) para cambiar de golpe todos los permisos a los archivos y carpetas de la instalación.

Solo tienes que incluir el siguiente código a tu archivo de configuración de WordPress y guardar los cambios para hacer magia:

/** Cambiar permisos de archivos y carpetas automáticamente */
define('FS_CHMOD_FILE', 0644);
define('FS_CHMOD_DIR', 0755);

En el código anterior cambiamos los permisos a los que deben tener por defecto pero si eres especialito con temas de seguridad o lo que quieras simplemente pon a tu gusto los permisos que quieres aplicar.

Ahora bien, se precavido, porque esta es una modificación bastante radical, y puede que algunos plugins o incluso funcionalidades del tema activo no funcionen bien o dejen de funcionar del todo una vez hechos los cambios, pues a veces requieren que algunas carpetas o archivos tengan permisos especiales, así que sé cuidadoso antes de hacer cambios en masa como el que te permite este código.

Desde la versión WordPress 3.2 ya sabes que puedes actualizar WordPress automáticamente de manera rápida y sencilla pero ¡ah amigo! ¿qué pasa si has hecho modificaciones a algún tema por defecto o plugins? que también puede que se actualicen y perderías todos los cambios.

Peroooo …

Eso, pero puedes evitarte este efecto secundario indeseado, pues hay una constante que puedes añadir a tu fichero de configuración de WordPress, el famoso wp-config.php con la que evitar que las actualizaciones del núcleo de WordPress afecten (toquen) otras carpetas. Vamos, que solo se actualizará el núcleo de WordPress, nada más.

Solo tienes que añadir esta línea a tu archivo de configuración y guardar los cambios:

// Que las actualizaciones de WordPress afecten solo al nucleo, no a wp-content
define( 'CORE_UPGRADE_SKIP_NEW_BUNDLED', TRUE );

Así que ya tienes una excusa menos para no actualizar WordPress para que sea seguro.

¿Práctico y apañado verdad?

Los programadores que trabajan con WordPress deben estar informados de las actualizaciones de los plugins que utilizan. El problema es que aunque los plugins son de código abierto y Automattic proporciona una herramienta para examinar su código, no se proporciona ningún feed en el que se describa correctamente el histórico de cambios ni la importancia de estos.

Para cubrir ese hueco David Martínez ha creado una herramienta llamada WordPress Plugin Feed que se encarga de obtener toda la información disponible de cada release de un plugin para generar un feed que permite mantenerse actualizado sin tener que acudir al panel de control de WordPress o a la ficha de cada plugin en WordPress.org.

Cada elemento del feed consta de:

• Lista completa de cambios en formato legible
• Fecha precisa (basada en los commits de Subversion)
• Enlace a la lista de cambios entre versiones en Subversion
• Actualizaciones de seguridad destacadas
• Versionado semántico

También se soportan una serie de plugins de terceros cuyo código fuente no está disponible públicamente (como Gravity Forms, Slider Revolution o WPML) y otros cuyo registro de cambios no se encuentra disponible en el repositorio público (como All-In-One SEO Pack, BuddyPress).

El código fuente, que puedes descargar en formato ZIP, y las instrucciones de instalación los tienes en GitHub.

Por defecto, la mayoría de los temas WordPress muestran la fecha de publicación de una entrada, aunque se haya modificado posteriormente para actualizar información contenida en la misma, lo que hace que no se muestre adecuadamente la vigencia de su contenido.

Esto, además, supone una posible pérdida de tráfico y, en consecuencia, es una pérdida de posibilidad de mejora de posicionamiento natural, porque Google siempre ofrecerá contenidos lo más actuales posibles para cada tipo de resultado. También, el usuario siempre elegirá un resultado más reciente que otro más antiguo.

Así que ¿a que no es mala idea que en tu tema se muestre la fecha de actualización en vez de la de publicación? Sobre todo si con ello consigues más visitas, no solo de los visitantes directos sino también desde los buscadores. Pues vamos a ello.

Mostrar la fecha de actualización de las entradas con código

Si no le tienes miedo a modificar un poco de código es una sencilla modificación la que tienes que hacer en tu tema. Lo único es que no siempre encontrarás el susodicho código en el mismo lugar del tema.

La situación ideal es en la que la línea que muestra la fecha está incluida en el fichero functions.php, pero no siempre es así, por lo que igual tienes que buscarla en los archivos que muestren fechas, como index.php, single.php, o incluso archive.php y demás plantillas de archivo (categorías, tags,  autor, etc)

Da igual en qué archivo se encuentre, lo que tienes que buscar es la función de WordPress get_the_time. En el tema que uso actualmente estaría aquí:

Y sustituirla, partiendo del mismo ejemplo, por la función get_the_modified_date:

En definitiva, que cambias get_the_time por get_the_modified_date, simple y efectivo. Guardas los cambios y pasarás de esto:

A esto otro:

Además, no temas, que el cambio no afectará al orden de tus entradas en portada, pues se mostrarán por orden de publicación, no de actualización.

Mostrar la fecha de actualización de las entradas mediante un plugin

La otra posibilidad es que te olvides de códigos y uses un plugin, y hay uno perfecto: WP Last Modified.

La única pega es que no sustituye la fecha de publicación por la de actualización sino que la añade, lo que puede confundir a tus lectores, e incluso al buscador, pero por opciones que no quede.

No obstante ofrece unas interesantes funcionalidades:

• Permite mostrar la fecha de la última modificación en entradas y páginas.
• Puedes elegir que se muestre la fecha de actualización en la parte superior o inferior de entradas y páginas, además de distintos formatos de fecha y hora en los que mostrarla.
• Te permite personalizar el texto que se mostrará junto a la fecha. Por ejemplo “Modificada el:” o “Actualizado el:“

Lo que obtienes es esto:

Elijas la opción que prefieras, el hecho de mostrar la fecha de actualización reducirá el bounce rate de tus entradas, ya que tanto el visitante como el usuario del buscador siempre busca la información más reciente posible.

Aunque te parezca cosa de ciencia ficción en realidad es posible crear un tema WordPress en solo 60 segundos, partiendo de una plantilla base de CSS y HTML y unos pocos cambios en el código. ¿No te lo crees? Dentro vídeo …

Visto en TutPlus

Si eres desarrollador, cuando estás programando un tema o plugin seguro que tienes un entorno controlado pero ¿activas WP_DEBUG?. Pues deberías.

La activación de WP_DEBUG en entornos de desarrollo WordPress es enormemente recomendable. Ponerlo en marcha es una operación sencilla que te recompensará con grandes beneficios para tu trabajo.

Así que vamos a ver de qué va esto.

¿Qué es WP_DEBUG?

WP_DEBUG es una sencilla variable global permanente, también conocida como constante PHP, introducida en WordPress 2.3.1, que puedes usar para activar o desactivar el modo de depuración en WordPress.

Por defecto el modo de depuración está inactivo, pero es prácticamente imprescindible activarlo cuando comiences un trabajo de desarrollo de temas o plugins.

WP_DEBUG se lanza desde el archivo de configuración de WordPress, el famoso wp-config.php, normalmente situado en la carpeta de instalación de WordPress, aunque puedes encontrarlo en otro sitio.

En principio la activación de WP_DEBUG es sencilla, solo tienes que ponerlo en true o false, dependiendo de si lo quieres tener activo o inactivo respectivamente.

De este modo, para activar WP_DEBUG simplemente añade la siguiente línea al archivo wp-config.php:

define ( 'WP_DEBUG', true);

Y para desactivar el modo de depuración cámbialo a lo siguiente:

define ( 'WP_DEBUG', false);

Una vez esté activo WP_DEBUG aparecerán mensajes de depuración y avisos PHP en las páginas de tu web. Estos mensajes normalmente ayudan al desarrollador a detectar problemas con el código, que de otro modo podrían pasar desapercibidos.

Ahora bien, el mero hecho de activar WP_DEBUG no es suficiente. Es importante guardar un registro de los errores para revisarlos con posterioridad, algo que también podemos activar ¿mejor no?

WP_DEBUG_LOG

Si quieres guardar los errores y avisos en un archivo de registro donde revisarlos a posteriori solo tienes que activar la funcionalidad WP_DEBUG_LOG. Al ponerla en true se guardarán todos los errores y mensajes en un archivo denominado debug.log situado en la carpeta /wp-content/.

Activar WP_DEBUG_LOG  es tan sencillo, de nuevo, como añadir esto al archivo wp-config.php:

define ( 'WP_DEBUG_LOG', true);

Guarda los cambios realizados y a partir de este momento WordPress guardará un registro de todos los mensajes y errores en el archivo debug.log. Luego solo te queda repasar el código de tu trabajo para solucionarlo.

Ahora bien, se me ocurre que si ya estamos guardando los mensajes y errores en un archivo ¿qué necesidad hay de seguir viendo esos feos mensajes y errores en pantalla mientras programas?

Vamos a ver la solución a esta molestia.

WP_DEBUG_DISPLAY

Si ya tenemos un archivo de los errores y mensajes podemos evitar que se muestren en las páginas en las que se generan. para ello hay que activar la constante PHP llamada WP_DEBUG_DISPLAY. Una vez en marcha el modo de depuración sigue activo pero no se mostrarán mensajes o errores en tu sitio.

De nuevo, es muy sencillo activarlo, solo hay que añadir una línea más al archivo wp-config.php:

define ( 'WP_DEBUG_DISPLAY', false);

En resumen, que si quieres activar la depuración, que se guarden los mensajes pero no se muestren, las líneas a añadir a wp-config.php serían las siguientes:

// Activamos WP_DEBUG
define ( 'WP_DEBUG', true);
// Guardamos errores en /wp-content/debug.log
define ( 'WP_DEBUG_LOG', true);
// Ocultamos errores en pantalla
define ( 'WP_DEBUG_DISPLAY', false);

Eso es to… eso es to… eso es todo amigos

Y ya, no es complicado pero es una herramienta de gran ayuda para el desarrollador, imprescindible diría yo. Cuando creas o modificas código para WordPress es vital comprobar cualquier posible error en el mismo para poder ponerle solución, para depurarlo y ofrecer un código limpio y profesional a tus clientes.

Por supuesto, luego tienes que acordarte de desactivar el modo de depuración de WP_DEBUG cuando termines de programar, por razones obvias de seguridad.

¿Conocías el modo de depuración WP_DEBUG? Es más ¿lo usas?

Creo que casi todos estaremos de acuerdo en que las actualizaciones automáticas de las versiones de seguridad y mantenimiento de WordPress, introducidas en la versión 3.7, son una mejora de las que marcan diferencias, pero también tiene sus cosas, como los avisos de actualización.

Porque, vamos a ver, si no quieres que WordPress te moleste teniendo que actualizar las versiones de seguridad ¿a qué viene que te avise por email cuando lo ha hecho? ¿no habíamos quedado en que nos fiamos de WordPress?

Vale, que está bien eso de tenernos informados pero ¿qué aporta cuando ya se ha actualizado? Pues nada.

Así que dicho y hecho, vamos a ver cómo quitar esos molestos mensajes de WordPress de que se ha actualizado a tal o cual versión y que es muy molón y te protege de tal y de cual.

Desactivar los emails de actualizaciones de WordPress con plugin

La solución más inmediata, aunque me dirás que un poco bestia, es usar un plugin tan majete y tremendo como Easy updates manager. Que vale, que sirve para muchas otras cosas, todas relacionadas con las actualizaciones de WordPress, pero entre ellas está justo lo que buscamos: desactivar esa pesadilla de los emails de que se ha actualizado WordPress.

Lo instalas, lo activas y te pasas por la página de ajustes, situada en un lugar prominente como submenú del Inicio del Escritorio, y en la primera pestaña lo tienes, ahí un poco más abajo, donde pone Notifications. Simplemente cambias la casilla a Disabled, guardas los cambios y arreglado.

Dicho sea de paso, aunque ya lo he apuntado al principio, este plugin es la hostia en bote. Todo lo relacionado con las actualizaciones – o no – de WordPress lo puedes gestionar con el, así que échale un vistazo porque lo merece. A modo de resumen te permite todo esto:

• Por supuesto, desactivar los emails de aviso
• Activar/desactivar todas las actualizaciones
• Activar/desactivar las actualizaciones mayores
• Activar/desactivar las actualizaciones menores
• Activar/desactivar actualizaciones automáticas de plugins
• Activar/desactivar actualizaciones automáticas de temas
• Desactivar las actualizaciones automáticas de traducciones (que por si no lo sabías se actualizan solas aprovechando cualquier otra actualización)
• Decidir qué usuarios pueden ver y activar actualizaciones
• Activar/desactivar actualizaciones automáticas de plugins y temas uno por uno
• … algunas cosillas más

Lo dicho, una joya.

Desactivar los emails de actualizaciones de WordPress con código

Si prefieres no instalar un cojonoplugin como el anterior, sino hacerlo al estilo elegante y de super pro, entonces nada más simple que añadir a tu plugin de utilidades o al archivo functions.php esta línea que pongo a tu disposición con sumo placer:

//Desactivar los molestos emails de actualizaciones automáticas
add_filter( 'auto_core_update_send_email', '__return_false' );

Guardas los cambios y a vivir la vida, que son dos días.

Son millones los sitios que tienen instalado y funcionando el mega plugin JetPack, que ofrece en una sola instalación muchas de las funcionalidades que casi todo usuario desea en un WordPress. Pero tanta facilidad a veces genera problemas.

Y es que, como ya he comentado muchas veces, JetPack ofrece un poco de todo, pero no lo mejor de cada casa. Incluye muchas utilidades, pero en su mayoría mucho menos configurables que cualquier otro plugin especializado. Ahora bien, se pueden hacer algunos ajustes.

Uno de ellos está relacionado con la utilidad Compartir de JetPack, que nos ofrece los típicos botones para que los visitantes compartan tus publicaciones en sus redes sociales favoritas. En concreto me refiero al icono para compartir por correo electrónico.

Que si, que está muy bien, pero tan sencillo que algún desalmado puede utilizar un bot para mandar spam con enlaces a tu web, con lo que podría parecer que eres tu quien está generando basura, o al menos la imagen de tu web saldría mal parada.

Y como ya vimos que se pueden añadir servicios en los que compartir desde JetPack, añadir un icono para compartir en Whatsapp, o incluso como quitar el contador de veces que se ha compartido una publicación, igualmente podemos añadir un sistema de Captcha, en concreto reCaptcha de Google, al formulario que se muestra cuando alguien comparte tu publicación por email desde el botón correspondiente.

Además que es bastante fácil de hacer, los pasos son los siguientes:

1. Registra tu sitio en reCaptcha de Google y consigue la clave pública y secreta

Ve a esta página y pulsa en el botón Get reCaptcha.

En la siguiente pantalla te pide una serie de datos, de los que el verdaderamente importante y único es el del dominio – o dominios – al que quieres asociar el reCaptcha.

Decide a qué dominio asociar el Captcha y pon un email tuyo de verdad y pulsa en el botón de Registro.

En la siguiente y última pantalla ya te muestra, en primer lugar, un par de claves, la Clave del sitio y la Clave privada.

Apúntalas, las vas a necesitar ahora mismo.

2. Añade las claves de reCaptcha a wp-config.php

Abre para editar el archivo de configuración de WordPress wp-config.php y añade las siguientes dos líneas:

/** Añade captcha a compartir por email de jetpack**/
define( 'RECAPTCHA_PUBLIC_KEY', 'PON_AQUI_TU_CLAVE_DEL_SITIO_DE_RECAPTCHA' );
define( 'RECAPTCHA_PRIVATE_KEY', 'PON_AQUI_TU_CLAVE_SECRETA_DE_RECAPTCHA' );

Por supuesto, hay un par de cosas que debes sustituir por las claves que acabas de obtener en reCaptcha. Guardas los cambios y ya lo tienes.

La próxima vez que alguien comparta por correo electrónico desde tu sitio tendrá que demostrar que es humano y no una máquina maligna.

Si quieres, ya que tienes creado el reCaptcha, en la misma página donde obtuviste las claves tienes el procedimiento para añadir manualmente este sistema en cualquier otra parte de tu sitio si así lo deseas.

Lamentablemente, no puedes añadir esta funcionalidad en los sitios de WordPress.com, solo en tu WordPress alojado, libre y completo.

Como ya vimos hace tiempo hay un límite en la cantidad de elementos que puedes añadir a un menú personalizado de WordPress, algo que no viene determinado por el mismo WordPress sino por el servidor donde esté alojado.

Esta cantidad, en algunos casos puede rondar los 50 elementos y en otros los 100, pero es algo que puede variar dependiendo de la configuración de tu servidor, y en concreto de Suhosin, un sistema avanzado de protección de PHP que se usa en muchísimos servidores.

En concreto, hay una variable determinada por Suhosin que limita la cantidad máxima de elementos que pueden guardarse usando scripts PHP, causante de este límite en el número de elementos que puedes añadir a un menú en WordPress.

Vale que no hay que volverse loco con los menús ya añadir decenas de elementos pero en algunas webs es imprescindible para ofrecer a los visitantes acceso a múltiples secciones, como por ejemplo en las webs de noticias, con submenús por provincias, categorías y subcategorías, así que no es algo tan raro.

Como ya vimos hace tiempo, se puede modificar el parámetro que provoca esta limitación modificando el fichero PHP.INI, pero no siempre tendremos acceso a este parámetro así que vamos a ver alguna otra solución más accesible para el común de los mortales, especialmente si estamos alojados en servidores compartidos, donde normalmente no hay acceso a la configuración de PHP.

Evitar el límite de elementos de menú desde .htaccess

Como suele ser habitual, hay un código que podemos añadir al fichero .htaccess para saltarnos el límite de elementos de menú de WordPress que nos pone el servidor a través de Suhosin.

Simplemente añade esta línea a tu fichero .htaccess, situado en la carpeta raíz de tu instalación de WordPress:

php_value max_input_vars 10000

Si no fuera suficiente podrías subirlo (razonablemente) hasta 10.000 normalmente.

Ahora bien, no siempre esta modificación funcionará. En ese caso deberías remitirte a tratar de eliminar la limitación desde PHP.INI o pasar al siguiente método si lo tienes disponible.

Evitar el límite de elementos de menú desde el panel de tu alojamiento

En contadas ocasiones encuentras proveedores de alojamiento que ofrecen una utilidad para configurar los parámetros de PHP. Si este fuese tu caso simplemente accede a esta utilidad y modificar los valores del parámetro max_input_vars a un valor donde no tengas problemas en añadir tantos elementos de menú como “necesites”.

En el caso de CDmon puedes hacerlo desde la sección Configurar Servidor del panel de usuario, en concreto en el icono llamado Configurar PHP. Ahí encontrarás el sitio donde subir el parámetro max_input_vars desde los valores iniciales de 1.000 hasta el límite habitual para servidores compartidos de 10.000, normalmente más que suficiente.

Debes tener en cuenta que nunca es bueno llevar al límite las configuraciones del servidor, y que incrementar por un lado las prestaciones puede resultar en una merma de recursos inesperada en otro aspecto, así que usa este tipo de trucos solo si es absolutamente necesario, y siempre atento de los posibles efectos secundarios.

La jerarquía de plantillas de WordPress es la base para la creación de temas WordPress y en el Codex hay una buena cantidad de recursos disponibles para saber cómo crear temas y modificarlos, pero no siempre navegar entre las páginas de WordPress.org es la mejor opción ¿no?

Quizás por este motivo Rami Abraham se lió y creó un mapa de recursos visual en el que se pueden ver todas las plantillas y dependencias entre ellas, con el plus de que cada uno de los elementos enlaza a su página correspondiente en el Codex de WordPress, creando así un maravilloso recurso para desarrolladores y amantes de WordPress en general.

El mapa de la jerarquía de plantillas, alojado en GitHub, como es natural admite hacer bifurcaciones (o forks, como prefieras) así que me he animado y he creado la versión en español para general disfrute de todos.

Puedes visitar el mapa visual de recursos de la jerarquía de plantillas de WordPress, actualizada a WordPress 4.3+ al incluir ya la plantilla singular.php. Solo tienes que hacer clic en la siguiente imagen para acceder a la misma e interactuar con ella.

Clic para acceder

Si te animas, puedes colaborar en la página oficial de WPhierarchy o en la rama en español de JerarquíaWP.

En cualquier web, pero especialmente en un entorno editorial, donde hay varios autores que publican contenidos, hay que tener control de todo aquello relacionado con las publicaciones, y los archivos adjuntos son algo a controlar, para evita una sobrecarga excesiva de la web, o justo lo contrario, para asegurarse de que se adjuntan imágenes en las entradas.

Un modo estupendo sería poder ver en el navegador de entradas de la administración de WordPress una columna que nos mostrase cuántos adjuntos se han incluido en cada entrada para, en caso de exceso o ausencia, saber de un golpe de vista cuáles hay que editar y cuáles en principio no requieren ninguna acción adicional por parte del editor del sitio.

Si es lo que buscas, unas líneas de código en el archivo functions.php de tu tema activo o en tu plugin personalizado, te añade la deseada columna adicional, este:

//Añade columna de contador de adjuntos
add_filter('manage_posts_columns', 'posts_columns_attachment_count', 5);
add_action('manage_posts_custom_column', 'posts_custom_columns_attachment_count', 5, 2);

function posts_columns_attachment_count($defaults){
    $defaults['wps_post_attachments'] = __('Adjuntos');
    return $defaults;
}
function posts_custom_columns_attachment_count($column_name, $id){
        if($column_name === 'wps_post_attachments'){
        $attachments = get_children(array('post_parent'=>$id));
        $count = count($attachments);
        if($count !=0){echo $count;}
    }
}

Guardas los cambios y tendrás una columna extra, como la de esta captura: