Con todos las extensiones ya instaladas y configuradas es un buen momento para revisar que nuestro sitio cumple los estándares W3C. Esto es una garantía de calidad en nuestro código, nos ayuda a mejorar nuestro posicionamiento en google y evita gran parte de los errores por incompatibilidad de navegadores, entre otras ventajas.
Joomla cumple con estos estandares por lo que los problemas pueden venir por las extensiones que hayamos instalado o por las modificaciones que hayamos realizado nosotros mismos sobre éstas.
1.-Validación XHTML
Para validar que nuestro código cumple el estándar XHTML 1.0 podemos utilizar el validador oficial en:
Donde indicamos la url que queremos validar y corregimos los errores que nos hayan podido aparecer. El problema es que esto sólo nos valida la url indicada, de manera que si le pasamos la raíz d nuestra web no navega por todo el entramado de enlaces que cuelga de ésta. Una herramienta que mejora esto es:
La cual rastrea y evalúa toda nuestra web mostrándonos, para cada página, los errores que haya podido encontrar. Para algunas de las urls dentro de mi sitio me he encontrado que indicaba error pero al acceder al resultado de la validación W3C me salía como correcta. No sé si es un bug o es que algo se me escapa, en cualquier caso nos facilita bastante la vida.
En el conjunto de las extensiones instaladas, la que más problemas me ha dado con diferencia es ccboard (para el foro) aunque también es la más compleja. A la hora de elegir extensiones Joomla no suelo ver comentarios referente al resultado de las validaciones W3C, pero sería recomendable informarse sobre este punto dado que, si queremos que nuestro sitio valide, puede suponernos una cantidad de horas importante corrigiendo errores de código ajeno (sobretodo por que a veces encontrar la raíz del problema puede ser un verdadero quebradero de cabeza).
A continuación hago referencia a un par de errores de validación que creo que merece la pena mencionar.
1.1.-Uso del ‘&’ en links y action’s de formularios
El uso del carácter ‘&’ (tal cual) en links y actions genera un error XHTML ya que el estándar pide que se utilice el código html (‘&’). Dado que algunos links venían parametrizados como variables PHP la manera que he encontrado de resolverlo ha sido utilizando el método str_replace(…) de php. Así si el link viene como:
….href=”<?php echo $url ?>”
lo cambio por
….href=”<?php echo str_replace(‘&’, ‘&’, $url) ?>”
lo que sustituirá cada aparición de un ampersand por su codificación HTML.
Esto vale para otros caracteres que generen error por no estar codificados.
Nota: Estuve investigando sobre si esto supondría un problema en el caso de que le queramos pasar un ‘&’ como parte de un parámetro (p.ej. si queremos pasar ‘smith&wesson’ como valor de un parametro ‘gun’). Por lo que he visto no habría conflicto ya que la manera de pasar este tipo de caracteres por url es mediante la codificación de éstos (con el método PHP urlencode(“”) p.ej.) y la codificación del ampersand queda como “%26″. Supongo que debe haber algún caso patológico en el que el uso de esta solución genere algún problema, pero en este caso me ha solucionado el problema.
1.2.-Código generado automáticamente en editores WYSIWYG
Al guardar textos en editores WYSIWYG es frecuente que este le añada código y que éste no sea XTHML válido. Por más que queramos eliminar este código, al guardar, el editor los vuelve a generar. La manera como he resuelto este problema ha sido modificando el contenido directamente en la BD. Como me ha pasado con artículos he modificado la columna ‘introtext’ de la tabla ‘jos_content’, eliminando de ahí los errores. Evidentemente si el error se encuentra en el texto de categorías, secciones u otro ítem del sistema habría que buscar la tabla donde se guarda en bd y modificarla.
2.-Validación CSS
Para la validación CSS también existe el validador oficial:
http://jigsaw.w3.org/css-validator/
Pero en este caso no he encontrado una herramienta que rastree el sitio completo y nos libere de hacer esta tarea manualmente. Lo que he hecho ha sido pasarle manualmente todas las URLs generadas por la herramienta anteriormente comentada (http://www.validator.ca/) para evitar así dejarme alguna. Una tarea de chinos sin duda.
No he encontrado ningún error especialmente difícil, pero si muchos warnings que a simple vista eran tan complejos de resolver que he preferido dejarlos (con los warnings valida igualmente).
3.-Validación RSS
La validación de nuestro RSS la podemos hacer en la página:
pasándole la URL del feed que queremos validar. Para el rss-feed que tengo instalado (bca-rss-syndicator) no me ha dado ningún error pero si una recomendación. Se quejaba de que el tag title estaba vacío y que esto podía provocar algún problema. Para resolverlo me he ido al fichero ‘feedcreator.class.php’ del componente y donde genera el título he cambiado:
$feed.= ” <title>”.FeedCreator::iTrunc(htmlspecialchars($this->title),100).”</title>\n”;
por
if(str_replace(” “, “”, $this->title)==”"){
$feed.= ” <title>”.FeedCreator::iTrunc(htmlspecialchars(“No Feed Title”),100).”</title>\n”;
}
else{
$feed.= ” <title>”.FeedCreator::iTrunc(htmlspecialchars(” “.$this->title),100).”</title>\n”;
}
Lo que he hecho ha sido validar si el feed tiene o no título (ya que desde el back del componente no se nos obliga a darle un título). Si lo tiene lo informo tal y como ya lo hacía previamente y si no lo tiene se lo pongo como “No Feed Title”. Así el warning queda resuelte y en el caso de que el feed no tenga título, aparece algo coherente.
Conclusiones
Con estos puntos resueltos ya podemos poner los links que permiten a los usuarios comprobar que nuestro sitio cumple los estándares W3C.
[...] Este punto ya lo hemos resuelto (ver el artículo 1.-Cumplir los estándares). [...]
Pingback por 3.- Tareas SEO « Proyecto portal AECSA — septiembre 14, 2009 @ 7:09 pm |