¿Por qué no puedo editar mis módulos de Joomla! 3.4 desde el front-end?

Problema

Como sabemos, a partir de la versión de Joomla! 3.2 tenemos la posibilidad de editar los módulos de nuestra web directamente desde la página principal, sin tener que recurrir a la administración de nuestro sitio.

Aunque esta opción tiene sus detractores, un compañero estaba especialmente interesado en utilizar esta opción trabajando con Joomla! 3.4 pero comprueba que en ningún momento desde el front se le ofrece esta oportunidad ¿Por qué?, ¿Qué está ocurriendo?

Solución

Lo primero que hacemos es comprobar que la configuración del panel de administración es la correcta para que aparezca esta opción. Lo hacemos desde "Sistema" --> "Configuración global" y concretamente buscando el ítem "Iconos de edición moviendo el ratón para".

 

Vemos que efectivamente esta bien configurado, por lo que nos aseguramos de estar identificados correctamente con un usuario con permisos para la edición en el back-end tanto en en el front como en la administración de la web, pero nada.

La web en cuestión utiliza una plantilla diseñada manualmente, por lo que probamos a cambiarla por la plantilla "Protostar" que se instala por defecto con el paquete de Joomla! y ahora sí, ahora al pasar el ratón por un módulo nos aparece un pequeño lápiz y si pinchamos en él entramos directamente en la edición del módulo directamente desde la página principal de nuestra web.

 

En otras palabras, el problema estaba en que no todas las plantillas soportan esta nueva opción de Joomla!, por lo tanto, esta posibilidad nos aparecerá únicamente con las plantillas optimizadas para Joomla! 3.2 en adelante y que tengan en consideración esta novedosa característica.

¿Se puede elegir el comportamiento de nuestra web con Joomla! cuando es visitada desde dispositivos móviles?

Existe cierta preocupación en los administradores de webs después del anuncio de Google que avisa sobre la necesidad de tener las páginas adaptadas a los dispositivos móviles para no perder presencia en este buscador cuando se realicen las búsquedas desde teléfonos o tabletas.

En principio, si utilizamos una plantilla en nuestro Joomla! basada en un diseño adaptable -o responsive- no deberíamos tener demasiados problemas en que Google considere nuestra web optimizada para móviles, de otra forma, a todos los que estéis dados de alta en la herramienta Google Webmasters os habrá llegado un mensaje para "corregir los problemas de usabilidad en móviles" de tu sitio web. Por cierto, se puede comprobar la optimización de tu web para móviles introduciendo su URL en el siguiente servicio de Google Developers.

Desafortunadamente, no existen opciones por defecto en la administracion de Joomla! que nos permita elegir cuál queremos que sea el comportamiento de nuestra web cuando es visitada desde dispositivos móviles. Si tiene plantilla responsive se adaptará y si no, pues se verá igual que en un ordenador. Para mejorar este aspecto, podemos encontrar algunas extensiones que nos darán variadas opciones de personalización.

En entre las distintas extensiones, podemos destacar un plugin, extremadamente simple, ligero y además gratuito que se denomina Simple Mobile Detection, disponible para Joomla! 2.5 y 3 que nos da bastantes opciones sobre qué queremos que ocurra cuando alguna persona acceda desde dispositivos móviles e incluso concretar qué queremos para móviles con Andoid, para Iphone, para Ipad o para Ipod.

Por ejemplo, con este plugin podemos elegir que cuando se entre con un Iphone se redirija a otra URL y cuando se accede con Android a otra distinta. También podemos seleccionar la plantilla que deseamos que se muestre en cada uno de los casos, pudiendo tener instalada una plantilla no adaptable en la web pero eligiendo que se muestra una responsive cuando se acceda desde móviles.

En definitiva, una interesante herramienta a tener en consideración ahora que, de forma urgente, si es que no se había hecho ya, nos debemos plantear el diseño para móviles de nuestra web realizada con Joomla! A continuación tenéis una de las capturas con las opciones básicas del plugin que se ofrece en el directorio Joomla! Extensions:

Problemas con la creación del ítem de SobiPro en el menú de componentes tras su instalación en Joomla! 3

Problema

Trabajando con Joomla! 3.3.1 nos disponemos a instalar el destacado componente gratuito SobiPro que sirve para crear directorios en el entorno de Joomla!

En un primer intento obtenemos un error al comprobar el sistema de instalación de la aplicación que el servidor tiene activado el "modo seguro" de php (safe mode), algo incompatible para que pueda funcionar SobiPro. Desde las opciones del panel de control de nuestro servidor tenemos la opción de desactivar el "modo seguro", lo hacemos y volvemos a intentar instalar el componente.

Esta vez sí que parece que todo ha ido bien, nos da algún aviso pero confirma que ahora ya se cumplen los requisitos mínimos exigidos y da la impresión de que SobiPro se instala correctamente. No obstante, nuestro gozo en un pozo cuando comprobamos que no existe ningún acceso a esta extensión desde el menú "Componentes" de nuestra administración de Joomla! ¿Entonces no se terminó de instalar? ¿Ha desparecido sin más? ¿Cómo puedo acceder a trabajar con él?... en definitiva ¿Dónde está SobiPro?

Solución

Comprobando vía FTP las carpetas existentes en el directorio "components" vemos que efectivamente existe una carpeta denominada SobiPro. Igualmente, en la gestión de extensiones podemos comprobar que aparece en el listado de componentes instalados...

Según parece este error viene provocado por una incompatibilidad con el editor "TinyMCE" instalado por defecto en todos los motores Joomla! El componente se instala, pero no se muestra en Componentes, funciona, pero es algo muy incómodo.

Para solucionarlo, y que nos aparezca normalmente nuestro ítem de SobiPro en "Componentes" para poder acceder con facilidad, solo hay que seguir tres sencillos pasos:

1. Desinstalar SobiPro (Componente y Plugin) desde el gestor de extensiones
2. Deshabilitar el plugin del editor "TinyMCE" en la gestión del plugins
3. Volver a instalar SobiPro

Y listo! Ya podemos volver a habilitar el plugin "TinyMCE" si nos es necesario y ya tenemos nuestro ítem de SobiPro funcionando en el menú de "Componentes".

Para más información, se puede consultar el detallado artículo del blog de Webempresa que trata sobre este mismo tema.

¿Puedo tener un único canal RSS en mi sitio con Joomla! 3 sin instalar ninguna extensión?

Como ya ocurría con las versiones anteriores 1.5 y 2.5, en Joomla! 3.x se mantiene el módulo por defecto denominado "Sindicación del sitio" que crea un canal de sindicación de noticias de las novedades de tu web.

No obstante, la principal dificultad de este módulo es que crea un canal RSS por categoría de tu web, es decir, si en mi página publico artículos en 5 categorías enlazadas desde mi menú principal obtendré un 5 canales de sindicación distintos, cada uno con du propia URL.

Esto es un gran problema porque por defecto no se puede obtener un único canal general con todas las novedades de todas mis categorías, siendo igualmente un inconveniente para los que utilizan FeedBurner, ya que solo se puede introducir un canal original en este herramienta de Google.

Con Joomla! 1.5 y 2.5 teníamos a nuestra disposición una extensión gratuita que permitía centralizar y configurar nuestro canal RSS con muchas opciones. Este complemento se denomina "Ninja RSS Syndicator" pero desafortunadamente todavía no está disponible para Joomla! 3.x. También existen otras alternativas de pago en Joomla! Extensions, pero aquí proponemos una solución en la que no es necesario instalar nada y totalmente gratuita.

La cuestión es que lo que pretendemos es unir todos los canales RSS de mi web en uno solo. Para ello, existe una fantástica herramienta de Yahoo! denominada Pipes que nos permite crear y configurar canales de sindicación a nuestro antojo. Lo positivo es que es muy potente y se puede hacer prácticamente todo lo imaginable, pero lo negativo es que es una herramienta con un interfaz poco intuitivo y totalmente en inglés.

Para obtener un único canal de nuestra web con esta herramienta online, creamos un nuevo "Pipe" -tubería en inglés- e introducimos en el panel el recurso "Fetch Feed" que permite unir hasta 10 canales RSS, por lo que copiamos ahí las direcciones originales de todos nuestros canales, una tras otra. Si tuviéramos más de 10 categorías, se pueden introducir varios "Fetch Feed" y posteriormente unirlos con el "Operator" "Union".

Una vez que hemos introducido todos nuestros canales originales, podemos ordenarlos por fechas para que aparezcan en orden cronológico mediante el "Operator" "Sort". También podemos limitar el número de ítems que aparecerán con el "Operator" "Truncate" o incluso prevenir los duplicados con "Unique".

Unimos nuestros recursos entre sí y con el módulo final "Pipe Output" y si todo va bien, ya disponemos de un único canal que muestra tal y como queremos todas las novedades de nuestra web. La dirección RSS de nuestro Pipe podemos usarla en FeedBurner y funcionará perfectamente.


Aquí queda esta posibilidad ya conocida por muchos, pero muy útil para los que se encuentran con este problema. Eso sí, un poco de paciencia con Pipes, ya que en un principio puede resultar un poco incomprensible la interfaz, pero los resultados son bastante buenos.

Solución al error "JFolder::create: Detectado bucle infinito" al intentar instalar extensiones en Joomla!

Existe un error bastante común en Joomla! cuando intentamos instalar alguna extensión que nos da, más o menos, el siguiente mensaje (extraído de la versión de Joomla! 3.2):

Advertencia
JFolder::create: Detectado bucle infinito
Advertencia: ¡Fallo al mover el archivo!
JFolder: :files: La ruta no es una carpeta. Ruta: /.../
JFolder: :folder: La ruta no es una carpeta. Ruta: /.../
JFolder: :files: La ruta no es una carpeta. Ruta: /.../
JInstaller: :Instalar: No se ha podido encontrar el archivo XML de configuración de Joomla!
Error
Archive does not exist

Al fin y al cabo lo que nos viene a indicar este mensaje es que no se encuentran algunas rutas, por lo que suele aparecer cuando cambiamos nuestro Joomla! de local a remoto, cambiamos de dominio o situaciones similares en las que tendremos que actualizar la configuración de nuestro motor.

Para solucionarlo, nos descargamos y abrimos nuestro archivo "configuration.php" de la raíz de la instalación de nuestro dominio. En este documento buscamos las líneas:

public $log_path = '/user/midominio.com/joomla3/logs';
public $tmp_path = '/user/midominio.com/joomla3/tmp'

Y modificamos y actualizamos las rutas en consonancia con nuestro nuevo dominio. Por ejemplo, si lo que he hecho es cambiar de midominio.com a miotrodominio.com, las nuevas líneas deberían ser:

public $log_path = '/user/miotrodominio.com/joomla3/logs';
public $tmp_path = '/user/miotrodominio.com/joomla3/tmp'

Guardamos y sobrescribimos el archivo. Al intentar de nuevo instalar una extensión, el sistema ya encuentra las carpetas "logs" y "tmp" y se puede completar con total normalidad.

En definitiva, un error que suele ser simplemente producto de un despiste, aunque habría que mencionar que en algunas ocasiones pueden darse errores similares en nuevas instalaciones donde no se tienen asignadas correctamente los permisos en las carpetas del servidor. En ese caso se deberían cambiar los permisos a 755 para carpetas y 644 para archivos.

Solucionando -definitivamente- los problemas con el código de los módulos de Jumi con Joomla! 3

Hace aproximadamente un año, publicábamos una entrada denominada "Solución al problema con el módulo de Jumi con Joomla! 2.5" donde exponíamos una posible solución a los últimos problemas que está presentando la extensión Jumi para guardar el código en sus módulos. En aquella ocasión planteábamos usar el componente para pegar el código y el módulo para hacer un llamamiento a ese código desde un lugar concreto de nuestra plantilla.

El problema de Jumi con Joomla! 3 vuelve a aparecer. Utilizando esta extensión que sirve para introducir códigos personalizados de javascript, php, html, css, dhtml scripts... ya sea directamente en el contenido de los artículos o mediante módulos, cuando queríamos insertar un determinado código mediante el módulo de Jumi, este desaparecía parcialmente al darle a "Guardar" el módulo, dejando inutilizado el código.

En el foro de esta extensión, podemos por fin encontrar una entrada donde un usuario propone una forma definitiva de solucionar este problema sin tener que recurrir a métodos indirectos como lo que proponíamos al principio de usar el componente como intermediario. La solución es muy simple y se basa en añadir un pequeño código en uno de los archivos del módulo:

1. Abrimos el archivo "mod_jumi.xml" que se encuentra en la carpeta modules >> mod_jumi

2. Buscamos la línea 35 (aproximadamente) donde aparece: 

    <field name="code_written" type="textarea" default="" label="Code written" description="PARAMCODEWRITTEN" cols="60" rows="17" />

3. Añadimos la expresión filter="raw" justo antes de type, debiendo quedar:

<field name="code_written" filter="raw" type="textarea" default="" label="Code written" description="PARAMCODEWRITTEN" cols="60" rows="17" />

4. Guardamos y listo!

Problema con los módulos tras realizar la actualización a Joomla! 3.3

Problema

Trabajando con Joomla! 3.2, realizamos la actualización del motor a la versión 3.3 mediante el componente "Actualizar Joomla!".

Una vez que se actualiza a la última versión, nos da el mensaje de confirmación y la web parece que sigue funcionando perfectamente. No obstante, al intentar modificar las características de un módulo, nos percatamos de que no podemos guardarlo ni copiarlo, de hecho, todas las opciones contextuales "Aplicar", "Guardar y cerrar", "Guardar y nuevo" y "Guardar como copia" no funcionaban, el único que parecía responder era "Cerrar" y esa opción de muy poco nos sirve.

Esto mismo nos ocurre con proyectos tanto en servidores locales como en la web... ¿Qué ocurre? ¿Un fallo en la actualización? ¿Ya no podremos modificar ni crear nuevos módulos?

Solución

De forma evidente, lo primero que hicimos fue relacionar este error con la actualización. En un primer momento activamos la "Depuración del sistema" en la pestalla "Sistema" que se encuentra en la "Configuración global" de nuestro motor para ver qué ocurre y comprobamos que de esta forma sí que podemos realizar cambios a los módulos donde su menú de opciones vuelve a funcionar normalmente, pero claro, no queremos estar mostrando permanentemente los errores de la web, por lo que no es la solución ideal, aunque ya por lo menos nos vamos acercando.

En una búsqueda por The Joomla! Forum, encontramos que el tema ya se ha tratado en varios hilos. En uno de ellos, se propone que se cambie la plantilla de la administración, de la "Isis" que es la que se muestra por defecto a la "Hathor", que también está instalada y que recuerda a la administración de las versiones anteriores de Joomla!. Así lo hacemos, nos dirigimos a "Extensiones" >> "Gestor de plantillas" y desde ahí realizamos el cambio y comprobamos que las opciones de los módulos vuelven a funcionar... pero claro, tendríamos que renunciar a usar la plantilla "Isis" y tampoco es lo que pretendemos.

De esta forma, ya hemos podido situar el problema en la plantilla. Finalmente, encontramos en otro tema del foro de Joomla! una solución permanente:

1. Sustituir la carpeta de la plantilla "Isis" de nuestra web por la que trae el paquete de instalación del nuevo Joomla! 3.3.
2. Limpiar la caché del navegador y de nuestro motor.

Y así lo hacemos. Copiamos la carpeta "isis" que está en el paquete de Joomla! 3.3 en la ruta "administrator" >> "templates", y la pegamos en la misma ruta de nuestra web mediante FTP. Posteriormente limpiamos la caché y problema resuelto de forma definitiva... Esperamos que sirva a quien esté en la misma situación.

Solución al bloqueo en la "Creación de tablas de la base de datos" durante la instalación de Joomla! 3 en XAMPP

Problema

Trabajando con el servidor local XAMPP en su versión 1.8.3, pretendíamos instalar el paquete de Joomla! 3.2.3, no obstante, después de completar los tres pasos para la configuración del motor, al pulsar "Instalar" en nuestro Joomla! 3, éste se quedaba una y otra vez bloqueado procesando la tarea "Creación de tablas de la base de datos".... el tiempo pasaba y el gestor nunca se terminaba de instalar.

Entrábamos una y otra vez en nuestro directorio de instalación para comprobar los datos y ver si alguna combinación mágica hacía que se pudiera completar el proceso de una vez. Pero parecía que nunca iba a suceder... ¿Qué estaba ocurriendo? ¿Cómo solucionarlo?

Solución

Buscando una posible alternativa sobre este tema en los foros de Joomla!, pronto nos situamos en la pista correcta. Encontramos primero una referencia a un problema similar pero con la versión de Joomla! 3.0.3. La solución propuesta es modificar el valor de "max_execution_time", una variable que se puede encontrar en el archivo "php.ini" de la carpeta "php" en nuestro directorio local de XAMPP.

De esta forma, modficamos el valor que aparece por defecto en la línea "max_execution_time" de 30 a 60, reiniciamos el servidor local... pero nada. Lo probamos con 100 y tampoco.

Continuamos la búsqueda y encontramos esta intervención respecto a un problema similar que propone subir el valor hasta 240. Así lo hacemos, colocamos "max_execution_time=240", reiniciamos el servidor otra vez (importante no olvidar este detalle)... y ahora sí, después de repetir nuevamente el proceso, por fin nos aparece la pantalla de confirmación de la instalación de nuestro Joomla! 3.2.

Solucionando problemas de saturación del servidor por Spam con Joomla!

Problema 

En un proyecto en el que se continuaba utilizando la versión 1.5.26 de Joomla! un día, sin motivo aparente, comienza a presentar errores en la navegación, en principio y atendiendo al mensaje de error, parecía que el problema se daba en la conexión con la base de datos.

Después de conversar con el servidor, nos cuentan que la base de datos que utilizamos está saturada y de ahí los problemas, que probablemente sea debido a alguna extensión instalada en la web u otro tipo de error en la programación del sitio. Realizando un exhaustivo examen de todas las extensiones de Joomla!, se desactivan las que parecen realizar mayor número de peticiones a la base datos.

Al poco tiempo, cuando parecía simplemente un repentino y extraño fallo, los problemas para acceder al sitio web se multiplican al poco, informando el servidor en esta ocasión de un exceso de consumo de recursos PHP y de peticiones al servidor... ¿Qué está ocurriendo? ¿Cómo puede ser que de la noche a la mañana y sin realizar ninguna acción relevante empiece a fallar todo?

Solución

Después de varios días, por fin parece que vamos situando el problema, y es que, consultando las estadísticas del servidor comprobamos unas series de IP de origen chino que están demandando muchísimos recursos, no aparecen en Google Analytics y evidentemente no se corresponden con el comportamiento normal de visitantes humanos.

Lo primero que hacemos es intentar que el servidor bloquee esas IP concretas que en los últimos días están entrando insistentemente. En principio parece de nuevo que se soluciona, pero al día siguiente, las IP cambian y la web vuelve a presentar problemas. Es algo extraño, ya que estas visitas de robots considerados Spam que estaban desestabilizando el funcionamiento de la web no dejaba comentarios ni ninguna otra huella aparente que la de intentar una y otra vez acceder al sitio.

Habiendo situado completamente el problema como Spam, con robots accediendo una y otra vez a nuestra web hasta saturarla, las medidas que tomamos son:

• Bloqueo de IPs  en el archivo .htaccess

Una de las funciones más utilizadas del archivo .htaccess (aparte del tema de las URL en Joomla!) es poder denegar manualmente el acceso al sitio de determinadas IPs o rangos de IP. Para lograrlo, tenemos que escribir al final del archivo:

## USER IP BANNING
<Limit GET POST>
order allow,deny
deny from 220.161.103.
deny from 121.205.
deny from 91.188.124.239
deny from 178.137.92.179
allow from all
</Limit>

Varias notas al respecto:

1. El ejemplo es un extracto del código real compuesto por muchas más IPs, siempre respetando el mismo formato por línea. Como se puede ver está compuesto por IP completas y rangos (los dos primeros que terminan en punto) que facilitan la labor de denegar IPs que comparten bloques de números idénticos.
2. Para saber que IP son las que accedían analizamos las estadísticas del servidor.
3. La primera línea <Limit GET POST> también se puede encontrar como <Limit GET HEAD POST>. Se puede utilizar una u otra siempre que no aparezca problema de incompatibilidad en el servidor.

Perfecto, con esta limitación manual nos aseguramos que esas IPs malignas concretas no vuelvan a acceder a nuestra web, pero ahora queda lo más difícil ¿cómo hacemos para que esto no nos vuelva a ocurrir?

• Instalación del plugin HTTP:BL

Para tener protegido nuestro sitio Joomla! de forma permanente contra nuevos ataques de Spam, instalamos el plugin gratuito denominado HTTP:BL - Project Honeypot Blocklists con el objetivo de tener un sistema que bloquee de forma automática las IPs consideradas malignas.

Una vez que instalamos el plugin -con versiones para Joomla! 1.5 y 2.5- tenemos que darnos de alta en el Project HoneyPot cuyo objetivo es precisamente fomentar una comunidad que pueda detectar y prevenir ataques de Spam a nivel global. Cuando nos registramos nos asignan nuestra "API Key" que tenemos que escribir en la configuración de nuestro plugin. Posteriormente lo activamos y algo importante, lo tenemos que colocar para que se cargue en primer lugar (posición 0).

Cuando comienza a funcionar el plugin, nos genera en el directorio principal de nuestro alojamiento un archivo denominado "httpbl.txt" en el que se recoge de forma constante la actividad de esta magnífica extensión, bloqueando todas aquellas IPs que están en la base de datos del proyecto clasificadas como malignas o como Spam. Los que no estén muy seguros de su utilidad, quedarán convencido viendo los resultados en este archivo que comentamos.

Complementariamente, se puede colaborar de diversas formas con Project HoneyPot para la detección y prevención del Spam, fundamentalmente colocando códigos "trampa" por tu web no visibles para los humanos pero que los robots de Spam consideran vulnerables, permitiendo así analizarlos para poder bloquearlos.

Pues de esta forma es como pudimos solventar este extraño error que nos costó detectar. Desde entonces vamos observando el archivo "httpbl.txt" y, aunque son bloqueadas, si vemos que una IP o rango concreto quiere entrar demasiadas veces seguidas en la web, procedemos a incluirla en nuestra lista negra en .htaccess añadiendo otra línea con "deny from" y la IP en cuestión.

Solución al problema con el módulo de Jumi con Joomla! 2.5

Por si hay alguien que todavía no la conozca, Jumi es una extensión muy conocida para Joomla! 3.x, 2.5 y 1.5 que permite insertar códigos personalizados de javascript, php, html, css, dhtml scripts... ya sea directamente en el contenido de los artículos o mediante módulos.

La extensión Jumi incluye el componente, el módulo y el plugin para introducir códigos en las publicaciones mediante la sintaxis: {jumi [código] [arg1] [arg2] ... [argN]}.

Problema

Trabajando con Joomla! 2.5.11 y con la versión de Jumi 3.0.4, nos percatamos que al intentar guardar el código que queríamos insertar en el módulo de Jumi, éste se borra casi por completo, quedando inutilizado y sin ningún efecto.

Según hemos podido constatar en el foro de esta extensión, es un problema que está siendo cada vez más habitual, y que no se corresponde a ningún fallo particular, como creíamos en un primer instante.

Solución

Siendo este problema conocido, confiamos en que en próximas versiones de Jumi se corrija el error. En la actualidad, para poder utilizar los módulos de Jumi, tenemos que utilizar también su componente de la siguiente forma:

1. Vamos a la gestión del componente. Allí, seleccionamos "Nuevo" y ponemos el código que queremos mostrar en nuestro módulo de Jumi en el apartado "Código base".

2. Damos a guardar y se nos quedará almacenado con el título que le hayamos puesto y un número de ID que le asigna el sistema. Copiamos ese número de ID.

3. En la gestión de módulos, creamos un nuvo módulo de Jumi, pero en vez de copiar el código ahí -pues no vale de nada hacerlo-, escribimos en el campo "Source of code" la expresión *XX, donde XX es el número de ID de nuestro código, por ejemplo, *3 (importante no olvidarse del asterisco)

Y de esta forma ya tenemos nuestro código personalizado en un módulo de Jumi, como vemos, de forma indirecta, pero es una buena solución para seguir utilizando esta magnífica y útil extensión.

Personalizando el formulario de registro de Joomla! con Community Builder

Problema

En un determinado momento, nos planteamos personalizar el formulario de registro de nuestro Joomla! 1.5.26 para poder introducir campos que nos interesaban conocer de los usuarios que se registraban en una Web y poder luego consultarlos en la administración de nuestro CMS.

La cuestión es que, como bien sabemos, el formulario de registro que viene por defecto en Joomla! 1.5 es bastante simple y ofrece los campos justos y necesarios, pero ¿cómo podíamos saber, por ejemplo, donde trabajaban o por qué se registraban?

El objetivo estaba claro: conseguir modificar a nuestro gusto el formulario de registro.

Solución

Básicamente pudimos encontrar dos formas de lograr nuestra finalidad:

1. Realizar manualmente los cambios en el código del formulario que viene por defecto añadiéndoles los campos que necesitáramos. Este proceso se explica en este tutoria: Parte 1 y Parte 2.

2. Con la ayuda de alguna extensión, por ejemplo, Community Builder, que se puede descargar previo registro en: http://www.joomlapolis.com/ y que actualmente es compatible con Joomla! 1.5, Joomla! 2.5 y Joomla! 3.0.

Cuando te descargas el paquete, tendrás que instalar el componente y los tres módulos de los que se componen. También está la opción de descargarse el paquete de idioma en español que deberá instalarse, mucho ojo con esto, al igual que otros posibles plugins mediante el gestor propio que el componente tiene, no con el gestor para instalar extensiones de Joomla!

Una vez instalado, se pueden modificar los campos del formulario que aparecerá a los usuarios que quieran registrarse mediante su propio módulo de registro. En definitiva, en esta ocasión lo que hacemos es crear otro tipo de formularios dejando de lado el que viene por defecto.

Trabajar con la extensión Community Builder ofrece bastantes más posibilidades que esta simple operación de modificación del formulario de registro, aunque hasta que no se utiliza un poco no deja de parecer un tanto compleja de abarcar esta herramienta.

Pues ahí queda esta solución que a nosotros -por ahora ya que con estas cosas nunca se sabe- nos ha venido de maravilla.

Error en la instalación de extensiones: "JFTP::store: Bad response"

Problema

Trabajando con Joomla! 1.5.25 en un servidor con PHP 5.3.4 intentamos instalar un componente en la web, sin embargo, nos aparecía una error que nunca antes habíamos observado al intentar realizar esta acción.

La verdad es que el servidor nos había dado diversos problemas para la instalación desde el Gestor de Extensiones de la Administración de Joomla!, ya que parece que no tenía una configuración demasiado optimizada para trabajar con este gestor.

La cuestión es que hacía tiempo que parecía que todo funcionaba con normalidad. Sin embargo, ese día nos encontramos con la imposibilidad de instalar extensiones por un error en el que se podía leer:

JFTP::store: Bad response
¡Advertencia! - Fallo al mover el archivo
JFolder::files: La ruta no apunta a un directorio válido o el directorio ha sido eliminado.
JFolder::folder: La ruta no apunta a un directorio válido o el directorio ha sido eliminado
JFolder::files: La ruta no apunta a un directorio válido o el directorio ha sido eliminado
¡Error! No puedo encontrar un archivo de configuración XML para Joomla! en el paquete

Solución

No sabíamos que estaba pasando. Las carpetas del servidor tenían los permisos adecuados, la capa FTP estaba activada con los datos correctos, las extensiones se podían instalar sin problemas en cualquier otra web...

Después de buscar un poco, encontramos que la solución era bien simple: Nos dirijimos a la Configuración Global, en la pestaña Servidor y allí pinchamos en "No" en la opción "Habilitar FTP", efectivamente, lo desactivamos, pero con los datos correctos grabados.

Una vez realizada esta sencilla operación, pudimos instalar las extensiones necesarias en nuestra web con total normalidad.

Cómo ver en los propios artículos las impresiones de cuántas veces han sido visitados en Joomla 1.5

Problema

Trabajando con Joomla! 1.5.26 nos planteamos que sería conveniente que al final de cada artículo apareciera de forma automáticas las veces que ha sido leído, es decir, las impresiones o hits. Con Joomla! 2.5 (o con K2) lo tenemos fácil, bastaría con seleccionar la opción en la configuración de presentación de los artículos, sin embargo con Joomla! 1.5 no es tan sencillo... ¿Cómo hacerlo?

Solución

Buscando la solución encontramos dos posibles opciones totalmente válidas en otros contextos, pero que no servían a nuestro propósito inicial:

*  Plugin Article Hits. En este caso se trata de un plugin que se instala y cuando se activa, en cualquier lugar de un artículo donde coloquemos la etiqueta {hits}ID{/hits} (donde ID es el número identificador del artículo) mostrará las impresiones.

La verdad es que está muy bien, pero nuestra intención es que lo hiciera de forma automática, no que tengamos que estar escribiendo en todos los artículos unas etiquetas.

* Módulo Hits AnyWhere: En esta ocasión si se muestra de forma automática las impresiones en cada artículo, pero se trata de un módulo, por lo que eso de que encaje al final del artículo sin que quede extraño, es muy complicado.

Al final la solución la encontramos aquí, basada en realizar un par de sencillos cambios a dos archivos de nuestro Joomla!:

1. Nos dirigimos hacia el archivo .../components/com_content/models/article.php

Bucamos el siguiente código:

else
      {
         $user =& JFactory::getUser();
         $article =& JTable::getInstance('content');
         $article->state         = 1;
         $article->cat_pub      = null;
         $article->sec_pub      = null;
         $article->cat_access   = null;
         $article->sec_access   = null;
         $article->author      = null;
         $article->created_by   = $user->get('id');
         $article->parameters   = new JParameter( '' );
         $article->text         = '';

Y se escribe justo debajo:

$article->hits         = null;

2. Nos dirigimos hacia nuestra la carpeta de nuestra plantilla en: .../templates/plantilla/html/com_content/article/default.php. Si no tenemos plantilla propia o no existe este archivo en: .../components/com_content/views/article/tmpl/default.php

Buscamos algo aproximado a esto:

<td valign="top">
<?php if (isset ($this->article->toc)) : ?>
   <?php echo $this->article->toc; ?>
<?php endif; ?>
<?php echo $this->article->text; ?>

Y le añadimos abajo:

<?php echo "<p>" . "Veces leido:: ". $this->article->hits . "</p>"; ?>

En esta misma etiqueta podemos utilizar las funciones de estilo en HTML para darle formato.

De esta forma, logramos tener en la parte inferior de todos los artículos, una expresión de "Veces leído:" y justo al lado, el número de impresiones del artículo.

Problema con las URLs amigables con Joomla! 2.5: "...Busqueda inteligente/Actualizar Joomla!..."

Problema

Trabajando con Joomla! 2.5.7 estábamos realizando un diseño de web sencillo, con un solo menú y un artículo simple conectado a cada ítem del menú.

Creamos nuestros artículos correspondientes y posteriormente, creamos el menú y conectamos cada artículo con su ítem. Hasta aquí todo normal, todo como debería ser. Sin embargo, al tratar de visitar los apartados creados en nuestra web, en cada página, nos daba un error "404 Categoría no encontrada" y la URLs generadas, en teoría amigables, eran de la forma:

http://www.misitio.com/index.php/Busqueda inteligente/Actualizar Joomla!/nombre.html.

¿Qué ocurre? ¿Por qué no podemos ver nuestras páginas si en principio el proceso seguido fue el correcto?

Solución

Al ver el error, lo primero que se nos ocurre es crear categorías, meter los artículos en dichas categorías y volverlos a enlazar hacía cada ítem del menú por si el fallo viene provocado por ahí. Pero nada.

Si vamos a Administración global de nuestro Panel de Administración y ponemos en "No" la opción "Motor de búsqueda para URLs amigables" el problema desaparece, pero las URLs amigables también con las repercusiones que eso puede tener para el SEO de la web. No es la solución que buscábamos, pero parece que nos vamos acercando.

Finalmente, encontramos que es un error que aparece habitualmente a los que trabajamos con Joomla! 2.5. y la solución perfecta, bastante sencilla:

Nos dirigimos hacia el aparado "Menús" y seleccionamos el menú en cuestión que nos está dando problemas. Marcamos todos los ítems y pinchamos en el botón "Reconstruir" que aparece en la parte superior derecha junto con las demás opciones de gestión del menú. De esta forma, el motor reconstruye las URL amigables y por fin se nos muestra nuestras páginas con una dirección adecuada.

Sin duda, un truco indispensable a tener en consideración para los nuevos usuarios de Joomla! 2.5 y para los que, como en mi caso, su experiencia con este CMS se ha centrado en el Joomla! 1.5.

Problemas con MySQL y PHP al instalar Joomla! en localhost con XAMPP

Problema

Como es bien sabido, es muy recomendable aprender y hacer pruebas con Joomla! en un servidor local por ser más rápido y poder tocar allá donde queremos sin temor. Hasta la fecha estábamos trabajando con una versión antigua del programa AppServ como localhost, sin embargo, en vez de actualizarlo, decidimos desinstalarlo y probar con el famoso XAMPP para Windows.

Después de informarnos en foros y demás, éramos conscientes de que para trabajar con Joomla! 1.5 no es muy recomendable utilizar la última versión de XAMPP (1.8) por que podrían aparecer diversas incompatibilidades graves con el PHP y MySQL, por ello, decidimos instalar la versión 1.7.4 de 2011.

A partir de aquí nos surgieron dos problemas gordos que no nos dejaban instalar y trabajar con Joomla! 1.5.26 con normalidad:

1. Cuando intentábamos enlazar la base de datos creada durante la instlación del motor Joomla!, aparecía el error:

You have an error in your SQL syntax; check the manual that corresponds  to your MySQL server version for the right syntax to use near  'TYPE=MyISAM CHARACTER SET `utf8`' at line 29 SQL=CREATE TABLE  `jos_banner` (   `bid` int(11) NOT NULL auto_increment,   `cid` int(11) NOT NULL default '0',   `type` varchar(30) .../...

2. Al completar la instalación, en vez de la portada de nuestro sitio en pruebas, nos aparecía un error larguísimo de la forma:

Strict Standards: Non-static method JLoader::import() should not be called statically in/home/user/www/joomla/libraries/joomla/import.php on line 29
Strict Standards: Non-static method JLoader::register() should not be called statically in/home/user/www/joomla/libraries/loader.php on line 71
Strict Standards: Non-static method JLoader::import() should not be called statically in/home/user/www/joomla/import.php on line 32 .../...

Solución  

1. El error con la base de datos es debido a un comando específico que utiliza esta versión de Joomla! y que no es compatible con la versión MySQL 5.5.x

Para solucionarlo, debemos editar el archivo joomla.sql (como siempre, preferiblemente con Notepad++) que se encuentra en la carpeta "installation" (esa misma que después de la instalación hay que borrar). Ahí debemos sustituir todas las expresiones:

"TYPE=MyISAM"

por

"ENGINE=MyISAM"

Con este simple cambio ya reconoce sin problemas la base de datos y podemos terminar la instalación con normalidad.

2. El problema en esta ocasión en de PHP. Resulta que por la configuración por defecto, por defecto nos aparecerá en pantalla el más mínimo error o warning, por lo que se nos llena la pantalla de pequeños fallos que habitualmente da Joomla! con PHP, de hecho, en la propia instalación recomiendan que no se active este informe de fallos.

Para solucionarlo nos vamos a la carpeta xampp >> php y editamos el archivo php.ini. Esta vez la modificación que hacemos es en la línea:

error_reporting = E_ALL | E_STRICT

y lo sustituímos por:

error_reporting = E_ALL

Precisamente al quitarle el "strict" le decimos a la configuración que no sea tan "tiquismiquis". De todas formas, si esto no funcionara, tenemos la opción de desactivar completamente los avisos de error en la línea:

display_errors = On

cambiándolo por:

display_errors = Off

¡Y a trabajar con Joomla! 1.5 en local con XAMPP 1.7.4¡

Las principales fuentes de donde sacamos la información son:

* The Joomla Forum
* OcioLaPalma
* The Joomla Forum (2)
* Jormc.es

¿Es posible instalar un sistema de preguntas y respuestas en Joomla!?

Problema

En un proyecto web sobre un determinado software, se pretendía poner un tipo de soporte basado en preguntas y respuestas, en vez del modelo Foro. La idea que se perseguía es conseguir algo parecido a las Preguntas y Respuestas de Yahoo, aunque lógicamente más humilde y sencillo.

Como no podía ser de otra forma, nos dirigimos a Joomla! Extensions, donde existe una sección específica denominada "Question and Answers", sin embargo, nos encontramos con una desagradable sorpresa y es que en esta ocasión casi todas las extensiones son de pago, y nuestra intención es instalar algo sin coste alguno.

Solución

Lo primero que hicimos fue fijarnos en una de las pocas opciones no comerciales: Answers para Joomla! 1.5 y nos lo descargamos. Al intentar instalar de forma automática desde Joomla! la última versión de Anwers (la 2.6) nos encontramos con diversos errores. Anteriormente había tenido ocasión de probar la 2.5 y estos errores no existían.

Después de investigar un poco, nos fijamos que los errores se subsanaban si descomprimíamos la extensión, copiábamos su contenido en una carpeta llamada "admin" y lo instalábamos desde la carpeta TMP de nuestro Joomla!. Esto viene porque según parece en esta versión no están bien configuradas las rutas de instalación y los propios diseñadores recomiendan en su web hacerlo desde TMP.

Una vez instalado, parece que lo más complicado está hecho. Ahora queda asignarle un ítem en un menú y configurarlo. Las opciones no son demasiado flexibles, viene por defecto un enlace al diseñador y tendremos que cambiar manualmente los mensajes que trae el sistema, todos en inglés. También hay que tener en cuenta que solo los usuarios registrados podrán utilizar esta herramienta. Pero con todo, el sistema de preguntas y respuestas funciona, con bastante trabajo (y suerte) ciertamente, pero funciona.

Buscando soluciones a un Sitemap demasiado grande con Xmap

Problema

En otra ocasión ya estuvimos hablando de Xmap, una extensión para la creación de Sitemaps de tu sitio Joomla! que puede facilitar la indexación en los buscadores.

Trabajando con Joomla! 1.5.25 en un servidor con PHP 5.3, un compañero me avisa de que en un proyecto con gran cantidad de artículos (sobre 6.000), Xmap está fallando, tanto en la creación del Sitemap en HTML como en XML.

En el sitemap en HTML el error que aparece al final de la página -que no logra cargarse- por completo es:

Fatal error: Maximum execution time of 10 seconds exceeded in /misitio.com/web/libraries/joomla/environment/uri.php on line 722

En el sitemap en XML aparecía:

Error de lectura XML: no se encuentra elemento
Ubicación: http://www.misitio.com/index.php?option=com_xmap&sitemap=x&view=xml
Número de línea 45454, columna 1

¿Qué hacer? Este proyecto se había quedado sin mapa del sitio y sin tener un XML válido para poder introducirse desde Google Webmaster.

Solución

* En primer lugar, el error en ambos casos, parece ser debido a una sobrecarga del sistema, que da la impresión de no poder crear Sitemaps tan grandes, ya que siempre el número de línea donde se daba el error, variaba, por lo que no se trataba de un problema puntual en un archivo.

Vemos en las opciones del actual Sitemap en la administración de Xmap que nos aparecía en la parte superior un error de PHP:

Deprecated: Function eregi() is deprecated in /misitio.com/web/administrator/components/com_xmap/admin.xmap.html.php on line 298

Como ya vimos en un artículo anterior, la función eregi en el nuevo entorno de PHP 5.3 está obsoleta. Para corregir este error, nos dirigimos hacia el archivo PHP que nos marca, y en la línea 298 sustituimos la función que aparece para controlar las imágenes por la expresión renovada:

if( preg_match('#^http:\/\/(.*)\.(gif|png|jpg)$#i'

 Una vez realizada esta acción, el error en PHP se había subsanado, pero los Sitemaps seguían sin funcionar.

* En segundo lugar, intentamos actualizar la extensión a su última versión. Desinstalamos la 1.2.9. e instalamos la 1.2.14, sin embargo, el error continuaba.

* Otra opción fue probar alguna extensión distinta, por si la dificultad estaba en la compatibilidad del sitio con el componente Xmap. Probamos el JCrowler, MySite y fwSitemap que aunque no dudamos de su valía en otros contextos, en nuestro caso, nada conseguimos.

* Finalmente dimos en la tecla con dos opciones válidas y que funcionaron utilizando el propio Xmap:

1. Opción de realizar varios Sitemaps, no solo uno. De esta forma se puede crear uno para cada sección o por cada menú y luego introducirlos todos en Google Webmaster.

2. Un solo Sitemap, configurado con las secciones del menú, pero no con las categorías. Es decir, en "Opciones" de nuestro Sitemap, en "Preferencias --> Excluir IDs del menú" excluímos del mismo todas las categorías que tengan las secciones del contenido que deseamos incluir, de esta forma conseguimos que se simplifique la función de Xmap y nuestro Sitemap con más de 6.000 ítems vuelva a funcionar, tanto en su versión HTML como XML. Lo único negativo es que mostrará el contenido por secciones, sin diferenciar las categorías, algo que sin duda es un mal menor.

Problema: Function eregi_replace() is deprecated con Ninja RSS Syndicator

Problema

Trabajando con Jommla! 1.5.24 en un servidor con PHP 5.3, nos percatamos de que nuestro feed en FeedBurner llevaba algunos días sin actualizarse. Al indagar un poco más, descubrimos que el origen del problema es que estaba fallando el RSS original del sitio, gestionado con la extensión Ninja RSS Syndicator. De esta manera, al intentar acceder a la dirección del feed original, de la forma: http://www.misitio.com/ index.php?option=com_ninjarsssyndicator&feed_id=1, obteníamos el siguiente error que había hecho que el RSS dejara de funcionar:

Function eregi_replace() is deprecated en tusitio.com/web/components/com_ninjarsssyndicator/views/ninjarsssyndicator/tmpl/default.php

Solución

Tal y como ya nos había pasado en otras ocasiones, ya que lo mismo ocurría con la función split y con la eregi, la función eregi_replace también ha quedado obsoleta en la nueva versión de PHP. Como en el resto de ocasiones, tendremos que sustituir la función antigua por otra expresión que pueda funcionar en la actual configuración de PHP.

En primer lugar, abrimos el archivo default.php siguiendo la ruta del error. Buscamos la expresión

eregi_replace

y la sustituímo por:

preg_replace

Sin embargo, si nos quedamos sólo con este cambio, el error original desaparecerá, pero nos dará otro:

Warning: preg_match() [function.preg-match]: No ending matching delimiter ']' found in tusitio.com/web/components/com_ninjarsssyndicator/views/ninjarsssyndicator/tmpl/default.php

Para que este fallo también desaparezca y por fin vuelva a funcionar nuestro RSS, el paréntesis que sigue a preg_replace también debe ser modificado para que quede de la siguiente forma:

preg_replace ("/xx/", "/xxx/", $string)

Así, por fin tenemos de nuevo funcionando nuestro feed con normalidad.

Problema: "Error SMTP: No es posible conectarse con el servidor SMTP"

Problema 

Trabajando con Joomla! 1.5.23 en un servidor de pago con PHP 5.3 comenzamos a tener un error cuando el sistema de envío de correos automático de Joomla!, configurado en "Servidor SMTP", comenzó a tener errores esporádicos, aunque continuos (aparentemente sólo 2 ó 3 veces al día), apareciendo el siguiente mensaje:

"Error SMTP: No es posible conectarse con el servidor SMTP"

La cuestión es que, por lo general, el envío de correos automáticos para el registro, para el administrador o los generados con otras extensiones, iba a la perfección, configurado todos los parámetros de forma correcta, el error aparecía de forma puntual y sin explicación aparente.

Aunque sólo parezca un error pasajero, el tiempo pasaba y persistía y eso significada que cada vez más correos de registro o avisos del sistema no llegaban a su destinatario. Por su parte, desde el servidor, informaban de que todo parecía funcionar correctamente, que el servicio SMTP corría a la perfección y que el error debía provenir de otra causa.

Solución

Después de investigar un poco, probar con todas las combinaciones imaginables y preguntar aquí y allí, el error acabó desapareciendo cambiando dos parámetros de la configuración de correo del Servidor SMTP (Panel de administración >> Configuración glogal >> Servidor).

1. SMTP Port: Modificamos el 25, que por defecto nos aparece, por el 578 que según parece es bloqueado por menos servidores.
2. Servidor SMTP: Aquí, cambiamos el típico "smtp.midominio.com" por la IP del correo saliente SMTP, un número facilitado en la información del servidor.

La cuestión es que, aunque sin saber exactamente el efecto de estas medidas, el error se fue como vino y los correos automáticos del sistema llegan a sus destinatarios (al menos por ahora).

¿Cómo colocar el módulo de acceso de Joomla! en horizontal?

Problema

Trabajando en un proyecto con Joomla! 1.5.25 y debido a las características de la plantilla del sitio, teníamos intención de colocar el módulo de acceso a usuarios registrados en el sitio en horizontal, justo abajo de la cabecera.

La cuestión es que con el módulo de acceso que por defecto trae Joomla! 1.5. (mod_login) es, como en otros tantos casos, un tanto inflexible, disponiendo de pocas opciones de configuración, entre ellas ninguna relacionada con la orientación del módulo, que en todos los casos tendrá una orientación vertical (a lo largo) pero nunca horizontal (a lo ancho).

Solución

Como ocurre muchas veces, la solución habrá que buscarla en alguna extensión que mejore y flexibilice las opciones para el módulo de acceso en nuestro sitio. En este sentido, encontramos en Joomla! Extensions el módulo SignalLogin que se puede descargar de forma totalmente libre, aunque sólo está disponible para la versión de Joomla! 1.5.

Gracias a esta sencilla extensión, de las numerosas que existen sobre autentificación, obtendremos la oportunidad de ampliar las opciones de configuración del módulo de acceso, entre ellas, dispondremos de la opción de colocar los cuadros de texto para introducir nombre de usuario y contraseña en horizontal, tal y como estábamos buscando.