Los lectores de Feeds son programas independientes que no necesitan acceder a la página web ni tampoco usar un navegador web para obtener la información.

Los RSS lo generan los sitios web que desean distribuir sus contenidos en el formato utilizado para ello, el XML.

Por lo tanto el usuario que abre su programa lector de Feed desearía leer el contenido completo de los nuevos artículos publicados de sus fuentes preferidas y no un resumen como se hace actualmente.

El problema surgió porque muchos webmasters prefieren que los visitantes accedan a su sitio web con un navegador en vez de con lectores Feed. Les interesa por diferentes motivos, la publicidad, el pagerank y estar mejor posicionados en los motores de búsqueda.

¿Qué es y para qué se utiliza el Feed o RSS?

Lo que no saben es que el Feed es un mundo aparte que también puede ser usado para campañas publicitarias al margen del sitio web y para promociones propias de los suscriptores al Feed. Aquí hay un terreno sin explorar teniendo en cuenta que se pueden recibir más visitas por Feed que por Web. Todo es cuestión de dirigir al público a uno u otro lado según nos interese.

Para que se hagan una idea se podrían enviar contenidos diferentes según se tratase del Blog o del RSS. Esto es algo que echo de menos en WordPress, la posibilidad de manipular esta información desde el DashBoard. Hay algunos plugin que realizan esta función pero los resultados no me han convencido o no he encontrado el adecuado.

¿Por qué usar FeedBurner?

La llegada de FeedBurner cambió un poco las cosas porque permitía ver el Feed como una página web desde el propio navegador sin necesidad de programas lectores de Feeds, una forma de rizar el rizo como decimos por aquí. De ahí que muchos decidieran no mostrar todo el contenido de sus últimos artículos olvidando que esta no es la única manera de leer Feeds.

FeedBurner utiliza el archivo XML que genera WordPress y le da su propio formato. También es convertido a HTML para poder ser visualizado por los navegadores web. Lo que aparece en los Feeds puede no depender de las configuraciones que hagamos en WordPress sino de la configuración en FeedBurner.

Pero más importante quizás es la posibilidad que ofrece a los visitantes de suscribirse mediante email para recibir las últimas novedades publicadas en sus propios correos electrónicos. A pesar de los numerosos complementos que tiene FeedBurner por ahora no permite configuraciones más personalizadas sobre la información que se envía en los correos de los suscriptores. Tampoco es posible enviar contenidos diferentes para las suscripciones por correo y para los lectores de Feed.

A muchos les gusta FeedBurner pero la mayoría lo usan para evitarse complicaciones con las suscripciones por email. FeedBurner lo gestiona por nosotros de forma cómoda y sencilla, y no tenemos que preocuparnos de guardar y proteger los datos de los usuarios. Pues que siga así, ahora debemos buscar la forma de crear otro Feed para usarlo separadamente.

¿Por qué hay que crear dos Feeds?

Podríamos tener dos Feeds uno para cada cosa. Esto no parece complicado, en el enlace a las suscripciones o las actualizaciones al Blog por Feed pondríamos uno que también creara WordPress que puede ser ligeramente diferente al anterior, con esa idea lo hemos pensado.

Para las suscripciones por correo ponemos el código que nos da FeedBurner. Es más a FeedBurner podemos enviarle el extracto o resumen del artículo, no lo necesita completo. De esta manera sería posible enviar por correo sólo el título del artículo con un extracto del contenido y un enlace de manera que se tenga que entrar en el Blog para leer el artículo completo. El verdadero Feed quedaría para su propósito original. Ofrecemos las dos posibilidades reales, suscripción por correo a través de FeedBurner y suscripción al Feed con dos formatos diferenciados según las preferencias del visitante.

FeedBurner redirige la url del antiguo Feed generado por WordPress a la suya propia, más bien es el plugin FeedBurner Smith quién realiza esta función. Si desinstalas el plugin desactivas la redirección. Esta es la razón por la que es complicado hacer cambios en el Feed sin que afecten a FeedBurner.

No puedes desactivar o desintalar el plugin porque FeedBurner dejaría de recibir los cambios que se hagan en el Blog y quedaría inoperativa la suscripción por email.

En otra ocasión veremos como crear nuestro propio Feed.

WordPress permitía mostrar solamente las páginas o solamente las categorías del blog pero no era posible mezclar ambas en el mismo menú. Con la nueva función wp_nav_menu() podemos escoger las páginas, las categorías y los enlaces (externos o internos) que deseemos mostrar en el mismo menú.

Está selección la podemos hacer desde el propio DashBoard o Backend, en Appearance – Menus, y podemos crear tantos menús como queramos. Desde la pestaña derecha le asignamos un nombre al menú y seleccionamos las categorías y páginas que deseemos mostrar en el menú marcándolas y pulsando el botón Add to Menu. Así como los enlaces que teclearemos en la ventana Custom links y después añadiremos al menú pulsando el botón Add to Menu.

Inicialmente si el theme no viene preparado, WordPress 3.0 nos permite ubicar el menú con un widget en el sidebar verticalmente. Aunque lo suyo es situarlo horizontalmente en la parte superior a continuación de la cabecera del theme. Para que una plantilla pueda hacer uso de esta posibilidad debe contener la función wp_nav_menu() en el archivo header.php.

WordPress indica que el theme no está preparado para el uso de menús con este mensaje.

Normalmente las plantillas hacen uso de las funciones wp_page_menu() o wp_lists_page() para crear un menú con las páginas del blog. Si sustituímos ese código por;

<?php wp_nav_menu( array( 'container_class' => 'menu-header',
'theme_location' => 'primary' ) );
?>

estaremos en disposición de usar el menú que configuremos en el DashBoard.

Los parámetros que se pasan a la función son; ‘container_class’ => ‘menu-header’, para decirle que aplique los estilos de la clase “menu-header” contenidos en el archivo style.css y ‘theme_location’ => ‘primary’ que le indica que es el primero de nuestros menús. Por supuesto, puedes usar otro nombre para container_class siempre que definas sus propiedades en la hoja de estilos style.css o incluso no usar ninguno.

Si el menú falla o no se encuentra, se usará la función wp_page_menu() que mostrará un menú sólo con las páginas.

Para mostrar un segundo menú se procede de la misma manera pero indicándo la palabra secondary:

<?php wp_nav_menu( array( 'container_class' => 'menu-header',
'theme_location' => 'secondary' ) );
?>

Lo visto anteriormente se refiere a la ubicación y la elección de los menús en las distintas zonas de nuestro theme. Es decir, no siempre podemos necesitar un sólo menú superior o que éste aparezca en la página principal, podríamos hacer uso del menú que nos interese.

Pero para poder hacer uso de los menús tenemos que decirle a WordPress cuál es cada uno y así nos permita seleccionarlos y configurarlos desde el DashBoard. Eso lo hacemos en el archivo functions.php. Para el caso de dos menús:

register_nav_menus( array (
'primary' => __( 'Navegacion Principal', 'tu_theme' ),
'secondary'=>__( 'Navegacion Secundaria', 'tu_theme' )));

Este será el resultado en la ventana de configuración de menús.

Normalmente eso se consigue en WordPress mediante plugins como “Similar posts” pero si no queremos sobrecargar el blog con tanto plugin o no nos gusta que los plugins guarden información en la base de datos puesto que con el paso del tiempo sufre un aumento considerable, se podría emplear la solución que comento a continuación.

WordPress posee potentes funciones para realizar todo tipo de consultas a la base de datos. Es el caso de query_posts(). A esta función se le pueden pasar diferentes parámetros dependiendo de la clase de consulta que se desea hacer.

Por ejemplo, query_posts(array(‘orderby’ => ‘rand’, ’showposts’ => 3)); le dice a WordPress que busque en la base de datos 3 posts de forma aleatoria. Cambiando el 3 por otro valor encontrará tantos posts como se le indique.

Si además le indicamos la categoría donde buscar los artículos ya habremos conseguido lo que queríamos, crear nuestra lista de artículos relacionados o similares. Este sería el código a utilizar con categoría y para 5 artículos: query_posts(array(‘cat’ => ‘mi_categoria’, ‘orderby’ => ‘rand’, ’showposts’ => 5));

Recordar que vamos a trabajar con el archivo single.php que es el encargado de mostrar un sólo post. La lista de artículos similares debe aparecer debajo del contenido.

Ahora bien, primero necesitamos saber a qué categoría pertenece el artículo que se está leyendo para poder ejecutar la consulta de forma automática. Para ello existe la función get_the_category() cuyo resultado lo guardamos en una variable y utilizamos el identificador de la categoría para realizar la consulta.

$category = get_the_category();
query_posts(array('cat' => $category[0]->cat_ID, 'orderby' => 'rand',
 'showposts' => 5));

Una vez hemos hecho la consulta ya podremos mostrar la información en pantalla. El código completo sería el siguiente:

$category = get_the_category();
query_posts(array('cat' => $category[0]->cat_ID, 'orderby' => 'rand',
 'showposts' => 5));
while (have_posts()) : the_post();
$similares = $similares .'<a href="'. get_permalink() .'" rel="bookmark"
title="'. get_the_title().'">'.get_the_title().'</a><br />';
endwhile;

Pero la cosa se complica. El archivo single.php ya tiene un blucle while que es el encargado de mostrar la información original de la consulta, o sea, el post. Tenemos dos problemas:
1 – No podemos perder la consulta previa. Es decir, cuando el visitante selecciona un enlace hacia un post ya le estamos pasando la consulta para que el bucle la muestre. Si ejecutamos otra consulta perdemos la anterior.
2 – No podemos usar un bucle dentro de otro de esta manera. WordPress, sin embargo, permite hacer consultas anidadas. Es lo que haremos en este ejemplo.

Una vez aclarado lo anterior lo primero que debemos hacer es guardar la consulta previa. Realizamos la nueva consulta y el segundo bucle while, y el resultado lo guardamos en la variable $similares. Restauramos la consulta previa y dejamos que el archivo single.php trabaje como lo haría normalmente con su propio bucle while.

Este sería el código completo al que hemos añadido una condición para que nunca salga en la lista de similares el artículo que se está leyendo. Este código debe añadirse al principio del archivo single.php después de <?php get_header(); ?>.

<?php
/* Guardamos la categoria actual */
$category = get_the_category();
/* Guardamos el ID del post actual para no repetirlo en la consulta */
$do_not_duplicate = $post->ID;
/* Guardamos el query anterior para realizar nueva consulta */
$temp_query = clone $wp_query;
/* Consultamos por categoria aleatoriamente un numero de posts
y guardamos en similares */
query_posts(array('cat' => $category[0]->cat_ID, 'orderby' => 'rand',
 'showposts' => 5));
if (have_posts()) :
while (have_posts()) : the_post();
if( $post->ID == $do_not_duplicate ) continue;
update_post_caches($posts);
$similares = $similares .'<a href="'. get_permalink() .'" rel="bookmark"
title="'. get_the_title().'">'.get_the_title().'</a><br />';
endwhile;
endif;
/* Restauramos el query anterior */
$wp_query = clone $temp_query;
?>

Dependiendo de la plantilla o theme $similares se puede situar en cualquier lugar dentro de la columna de contenido del artículo aunque queda mejor al final justo antes de los comentarios. Para mostrar la información debes escribir el siguiente código:

<h3>Articulos similares</h3>
<?php echo $similares; ?>

Si colocas $similares antes de los comentarios (antes de <?php comments_template(); ?>) estará dentro del bucle while principal. Se podría ubicar fuera pero quedaría muy abajo después de los comentarios.

Puesto que el bucle principal sólo muestra un artículo cada vez no hay mayor problema con meter $similares dentro, es decir, sólo se ejecutará una vez. Esta es la razón de que sólo se pueda usar este código en el archivo single.php. Si lo intentas poner en el index.php no funcionará porque se crearán varios bucles encadenados obteniendo un resultado no deseado.

Puedes consultar sobre los bucles anidados en el codex de WordPress.

Si los archivos dañados son pocos y conocemos cuales son, podemos emplear las copias de seguridad que debemos tener para restaurarlos a su estado original. En este caso subimos los archivos mediante FTP al servidor.

El problema mayor surge cuando no tenemos copias de seguridad o cuando la modificación se ha producido por un ataque de malware desconociendo el número de archivos afectados.

Si tu sitio web está alojado en GoDaddy, o alguno de sus Resellers, debes saber que en el servidor se guarda una copia de todos los archivos en los últimos 30 dias. Gracias a esto podemos restaurar los archivos a una fecha anterior al ataque. Además de poder comparar por fechas nos facilita la labor indicando los archivos que han sido modificados mediante la palabra “different”.

Para restaurar archivos o directorios completos debemos hacer lo siguiente:

1 – Crea una página index.html que advierta a tus visitantes que el sitio está en mantenimiento. Subela a tu hosting por FTP. No hay necesidad de dar información sobre las causas, un simple mensaje de Sitio en mantenimiento, Estamos en obras, Volveremos pronto o algo similar puede servir. Elimina el archivo index.php. Comprueba que al acceder a tu sitio sale la página de mantenimiento. Esta situación es temporal, estará así el tiempo que estes trabajando en tu hosting.

2 – Accede a tu cuenta Go Daddy. En Hosting Account selecciona el botón Your Files – Manage site content. Esto abrirá una ventana con el administrador de archivos que te permitirá ver y cambiar tus permisos de archivos y directorios, modificar fechas, así como ver y editar tus archivos.

3 – A la izquierda, en la pestaña Current localiza la fecha y hora de los archivos. Fijate en la fecha de los archivos PHP, debe ser la de la última actualización de tu aplicación, ya sea WordPress o cualquier otro CMS. Si la fecha de los archivos es de hace unos dias y no has modificado ninguno recientemente, está claro que han sido alterados después.

4 – Selecciona la pestaña History para poder escoger una vista de los archivos con fecha anterior a la modificación. Puedes ir atrás seleccionando en el icono del calendario un dia concreto antes del ataque de tu sitio. Podrás ver un indicador color naranja que pone “different”, esto indica los archivos que han cambiado. Anota esa fecha y hora.

5 – Amplia la vista de 25 a 50 para poder ver más archivos. Comprueba todas las páginas que aparezcan y todos los archivos.

6 – Selecciona la pestaña Current y borra todos los archivos y directorios excepto _db_backups, php_uploads, stats, en caso de que los tuvieras. Borralos de uno en uno para evitar bloqueos del servidor. Tampoco puedes eliminar el archivo index.html anteriormente creado.

Eliminando todos los archivos y directorios te aseguras de no dejar restos de malware. Además si no eliminas los directorios cuando restaures te va a estar preguntando en cada archivo si quieres sobreescribirlo, cambiarle el nombre, etc. Si hay muchos archivos en un directorio puedes tardar mucho tiempo.

7 – Selecciona la pestaña History y vuelve a la fecha que pusiste en el punto 4.

8 – Marca la casilla a la izquierda del archivo o directorio para seleccionarlo y pulsa el icono Restore. Realiza esta operación para cada directorio hasta que todos indiquen Current en color verde.

9 – Repite el mismo proceso para los archivos del directorio raiz.

10 – Comprueba que todos los archivos y directorios están marcados en verde como “Current”. Revisa dentro de los directorios y si la vista tiene más páginas con archivos.

11 – Selecciona la pestaña Current y borra el archivo index.html, aunque también podrías renombrarlo por indexhtml.old por si en un futuro lo pudieras necesitar. En la mayoría de servidores pueden existir los dos archivos, es decir, se da preferencia al archivo index.php en caso de no encontrarse se buscará index.html. Por tanto este último puede quedarse tal cual está, no afecta al funcionamiento del sitio.

12 – Visita tu sitio y comprueba que todo va bien.

A las ya sabidas medidas de seguridad ya comentadas aquí para todo el que tenga un Blog, hay otras tan básicas que no por ello debemos desechar y pensar que no van con nosotros. A parte de bloguers no debemos olvidar que también navegamos por internet como cualquier otro usuario. Es posible que estos descuidos tengan mucho que ver con las recientes oleadas de malware que se están produciendo y que tienen mayor incidencia en algunos blogs de WordPress principalmente.

No digo que los servidores no tengan su parte de culpa en ello por descuidar actualizar y reforzar sus normas de seguridad pero como usuarios y webmaster deberíamos esmerar un poco más las precauciones. No conocer la ley no exime del delito.

Por tanto, partiendo como usuario hay algunos detalles a tener en cuenta:
1 – Eliminar las cookies, archivos temporales de internet, historial de navegación, formularios, etc, de nuestros navegadores constantemente.

Cada vez que visites una página vacia el historial de navegación antes de visitar otra. Las cookies están jugando un importante papel en la transmisión de estos malware.

2 – Cuidado con los sitios que visitas. Sospecha de todo, a veces sólo por el aspecto de un Blog se puede saber mucho de la persona que hay detrás de ellos. Sitios web descuidados, con elementos fuera de sitio, mal ubicación de códigos, publicidad, etc. Seguro que los hackers se fijan en estos detalles para atacar estos sitios puesto que queda claro el desconocimiento del webmaster en el manejo de códigos.

3 – Cambia tu rutina de navegación diaria. Es decir, deja de visitar los blogs que frecuentas durante algún tiempo, algunos meses si es posible hasta que pase todo este caos. Da igual si son de amigos o conocidos, aunque la persona sea de confianza puede que sus blogs no lo sean tanto por tratarse de gente inexperta en la materia.

4 – No te dejes influir por los comentarios de todas esas páginas supuestamente de seguridad. En algunas se detecta el malware antes incluso de que se haya producido el ataque. Ya sabemos el negocio que hay detrás de los antivirus.

Si eres algo paranóico en estos temas te aconsejo que no entres en este tipo de sitios o creerás que tienes todo ese malware. Quién sabe si mucho del código malicioso existente se transmite por la abundancia de visitantes afectados a estos sitios. Si hay epidemia de gripe y acudes a un lugar sabiendo que hay personas infectadas existen más posibilidades de que caigas enfermo.

5 – Todavía existen muchos blogs infectados. Lo peor es que algunos de sus propietarios tienen conocimiento del problema. Es una imprudencia y una irresponsabilidad estar dias así y más cuando se tiene la seguridad de que puede haber malware en el blog. Sobre la marcha, ante cualquier mínima sospecha, poner el blog en modo mantenimiento. No es ningún modo especial de WordPress ni nada similar.

Se trata de tener preparado un archivo index.html que contenga un texto informando al visitante de que tu sitio está en mantenimiento y que es una situación temporal. Estamos en obras, Servidor en mantenimiento o cualquier otra frase que desees puede servir. Si no tienes un archivo index.html lo puedes subir al servidor por FTP. Cuando lo tengas renombra el archivo index.php por index-php.old por ejemplo. Si vas a restaurar o instalar de nuevo tu blog desde cero puedes eliminarlo, ya se encargará la instalación de crearlo de nuevo.

Una vez que hagas las comprobaciones oportunas y creas que todo está correcto puedes volver al modo normal renombrando index-php.old por index.php. La mayoría de los servidores para la carga de un sitio web lo primero que buscan es el archivo index.php, en caso de no encontrarse se carga el archivo index.html. Por tanto los dos archivos pueden estar en la carpeta raiz sin problema, no afecta al funcionamiento del sitio.

6 – En relación con lo anterior, existen plugins que te permiten poner WordPress en modo mantenimiento. Si la página se crea dentro de WordPress no vale, se trata de que salgas totalmente de WordPress para repararlo y puedas trabajar cómodamente sin interferencias externas. El plugin no deja de ser otro archivo PHP que también puede estar infectado por malware.

7 – Por supuesto, no ejecutes ningún código desconocido, da igual si te dicen que es un antivirus fantástico, da igual su procedencia o las buenas intenciones. A veces es peor el remedio que la enfermedad. No todos los servidores responden de la misma forma a la hora de ejecutar código. Algunos servidores por seguridad no permiten la ejecución de ciertos códigos para evitar comprometer el sitio. La consecuencia al ejecutar estos scripts es que puedas dañar alguno, o varios, de tus archivos puesto que el código no se ha ejecutado adecuadamente o completamente.

8 – Según lo anterior, ante la duda de lo que puedes o no ejecutar acude al servicio técnico de tu hosting. Pide asesoramiento y la manera de prevenir estos ataques y amenazas o limpiar tus archivos en caso de estar afectados. Para ello aporta la máxima información posible, versión de WordPress, efecto causado por el malware, sitios visitados, tareas que estabas haciendo, plugins instalados, código ejecutado, etc.

9 – Acostumbrate a anotar la fecha de los archivos de tu última actualización. Si entras por FTP puedes comprobar si ha habido modificación posterior de tus archivos. Lo que te indicará la posible presencia de malware en ellos. Por ejemplo, los archivos de la versión 2.9.2 de WordPress podrían tener fecha de enero o febrero de 2010, sólo los del sitemap y algún otro archivo que requiera actualización frecuente o que hayas modificado personalmente pueden tener una fecha más reciente. Todos los restantes deben tener la misma fecha, WordPress no necesita escribir ningún archivo para su funcionamiento normal.

En la mayoría de los servidores existen copias de los archivos antes de la fecha en la que se produjo el ataque de manera que tienes la posibilidad de restaurarlos a su estado original. Suele haber algún administrador de archivos que te permite editar, copiar, borrar o restaurar archivos escogiendo la fecha que desees.

10 – También es conveniente comprobar los permisos de acceso a los archivos y carpetas de tu sitio. WordPress necesita 755 para los directorios y 644 para los archivos. No necesitas dar más permisos, no pongas a ningún archivo acceso total 777, ninguna aplicación lo necesita.

Una manera un poco laboriosa de no permitir la escritura en los archivos sería reducir los permisos de todos los archivos que no requieran modificarse a 444, es decir sólo lectura. Esto impedirá que ningún código malicioso escriba en ellos. El inconveniente es que son muchos los archivos y que no podrás actualizar el blog o modificar algún archivo hasta que repongas los permisos por defecto.

Todo esto también es aplicable a cualquier CMS como puede ser Joomla, Drupal, phpBB, etc.

Seguro que se me olvida alguna medida de prevención más. Añade las que creas conveniente.

Un excerpt manual se añade rellenando el campo Excerpt en la ventana de edición del post. En el post se mostrará el texto introducido en el excerpt manual en vez del extracto auntomático o el contenido.

El excerpt tiene dos usos principales:
1 – Reemplaza el contenido completo del post en el Feed cuando la opción For each article in a feed, show – Summary (Para cada artículo en el Feed mostrar – Sumario) está seleccionada en el menú Settings – Reading (Ajustes – Lectura)

2 – Dependiendo del theme se puede mostrar en distintos lugares donde se prefiera un extracto en vez del contenido completo, resultados de búsqueda, categorías, Tags, artículos de autores, etc.

La mayoría de las veces echamos la culpa a la empresa que aloja nuestro Blog cuando averiguamos que nos han colado uno de estos códigos. Aunque en algunos casos podemos tener razón no siempre tomamos las medidas necesarias para proteger nuestros sitios web.

Si eres propietario de un dominio, si has creado un Blog, tú eres el máximo responsable. Si no te preocupas tú ¿Quién lo va a hacer?

Es sabido que los desarrolladores de WordPress se toman muy en serio la seguridad, están permanentemente revisando el código y corrigiendo errores cuando los detectan. Eso no quiere decir que sea una plataforma perfecta o inmune a los ataques. Tienes que ser consciente que hacer uso de WordPress no significa que te exima de responsabilidad o que puedas culpar a otros, incluído WordPress de la falta de seguridad de tu sitio web.

Es evidente que tu sitio web tiene un riesgo de seguridad alto si está alojado en un servidor compartido y más si no haces uso de los certificados SSL. Tampoco tiene culpa tu servidor de que utilices las típicas contraseñas facilmente detectables.

Algunas preguntas que deberías hacerte:
- ¿Sabes que tu sitio no es inmune o interesa a los hacker?
- ¿Has contratado con una compañía de Hosting fiable?
- ¿Usas contraseñas fuertes? ¿Son diferentes para tus distintas cuentas (FTP, hosting, base de datos, email, WordPress)?
- ¿Son los permisos de acceso a tus archivos los adecuados?
- ¿Tienes actualizados WordPress y los plugins?
- ¿Está en lugar seguro tu wp-config.php?
- ¿Haces copias de seguridad de tus archivos y base de datos con frecuencia?

La respuesta a todas estas preguntas debe ser la misma, “SI”.

En un artículo anterior ya comenté algunos de estos puntos y las medidas de seguridad básicas a seguir.

El mantenimiento del servidor no incluye el seguimiento del código o del contenido ni el mal uso que se haga de ellos. Podemos recibir recomendaciones y sugerencias del servicio técnico pero el mantenimiento y las medidas de seguridad a adoptar para nuestro blog nos corresponde a nosotros llevarlas a cabo.

Es imprescindible que adquieras buenos hábitos de seguridad y te acostumbres a realizar estas operaciones de forma periódica, nadie las va a realizar por ti.

Más información del malware en wpsecuritylock

Kunena permite integrar un Foro y crear comunidades en sitios webs basados en Joomla de forma rápida y sencilla.

Entre otras características también es posible insertar banners o anuncios publicitarios, como podrían ser los de Adsense. Su uso no está limitado sólo a publicidad, cualquier otro código que nos interese puede añadirse de igual manera.

Kunena ofrece diferentes posiciones para insertar estos códigos, en la parte superior del Foro, en el pie del Foro, en la ventana de identificación del usuario o entre los mensajes de cada tema o tópico.

Lo primero que debemos hacer es crear un nuevo módulo. Desde el menú Extensiones, Administrador o Gestor de módulos y seleccionamos Nuevo para añadir un nuevo módulo. De entre las distintas opciones que nos muestra Joomla elegimos Personalizar HTML. Esto nos permitirá crear nuestros propios módulos personalizados usando el editor de código.

En la siguiente ventana de detalles del módulo, ponle un título al módulo, será el nombre del módulo. Puedes ocultar el título en el Foro o mostrarlo marcando las casillas correspondientes. Lo más habitual es no mostrarlo.

Donde pone posición, NO selecciones ninguna de la lista. Escribe una de las siguientes:
kunena_profilebox, para que aparezca la publicidad dentro de la ventana de identificación de usuario
kunena_announcement, para que aparezca la publicidad en la ventana principal del Foro en la parte superior
kunena_bottom, para que aparezca la publicidad al final del Foro
kunena_msg_1, para que aparezca la publicidad después del primer mensaje en cada tema creado o tópico
kunena_msg_2, para que aparezca después del segundo mensaje, y así con todos los mensajes…

En el editor de texto le pones el código de Adsense y lo guardas.

Si quieres publicidad en todas las posiciones tendrás que crear un módulo para cada una de ellas. La única precaución a tener en cuenta es el espacio disponible para la publicidad.

Aquí puedes ver las distintas posiciones dónde se puede colocar la publicidad en Kunena. En esta otra vista puedes ver entre los mensajes 1 y 2.