Imaginemos que tenemos un div que contiene un par de divs con float:left. El problema que nos aparece es que el fondo gris no se estira para recoger los elementos que contiene, ya que los divs internos son flotantes.

Como corregimos ésto? Bién, he dado con la solución!
Editado: Gracias a los comentarios, ahora la solución es mejor!

La forma común

Hasta ahora lo que venía haciendo con Firefox era agregar un elemento HTML justo después del último elemento div interno, antes de cerrar el div contenedor, con un clear:both. La teoría es fácil y funciona: El clear:both se encarga de limpiar de elementos a derecha e izquierda para que el contenedor sepa hasta dónde llega él mismo.

Pero en Internet Explorer 6 y 7 ésto no funciona. El navegador lee el BR pero parece que el clear:both no se aplica. La única forma que encontré era poner dos veces el BR. Así parece que sí que funciona pero por contra nos hace dos saltos de línea, con lo que si teníamos la maquetación cuadrada con tamaños y posiciones, veremos como se descolocan con el nuevo espacio inferior.

La nueva solución

Rebuscando por internet he encontrado la solución que plantean en Quircksmode. Se trata de usar la instrucción overflow junto con un width. El primero soluciona el problema en Internet Explorer 7 y el segundo es para que internamente se llame al hasLayout de Internet Explorer 6:

El problema aquí es el width, porque el resto de navegadores también lo entienden y lo aplican, desmontando la maquetación que teníamos (por ejemplo, un padding).

Entonces, pensando un poco, necesitamos una instrucción que sólo funcione para Internet Explorer 6 y que active su hasLayout... y aquí entra otro truco que he visto en PositionisEverithing, que aunque su método no me gusta nada, usa la instrucción zoom para activar el hasLayout.

Así que la forma que he visto que funciona en los tres navegadores es una fusión de las 3 soluciones: Por un lado mantenemos el BR con el clear:both y además añadimos al DIV contenedor un par de instrucciones CSS para que en los otros navegadores funcione, dejándolo de la siguiente manera:

Editado: He probado la soluciónes de los comentarios y la fórmula que funciona en los tres casos es la siguiente: Añadir al contenedor el binomio overflow y zoom sin el salto de línea con clear:both.

Ala, problema resuelto. Y si estáis cuadrando maquetación entre navegadores... paciencia!

Salu10

¿Cómo? ¿Y porqué? Si justamente ahora empezaba a ser senior en PHP!
Habéis probado Ruby? Habéis jugado con lo que permite este lenguaje de objetos?

Ya desde que Bruno, un amigo motero y programador, me convenciese para que le echara un vistazo me gustó, pero claro, es "un lenguaje nuevo" y "aún le falta mucho" y "no tengo tiempo para jugar". Luego conocí a los creadores de moterus.es, red social al estilo facebook pero enfocada a moteros, escrita también en Ruby on Rails. Salimos varias veces en moto y en las paradas... bueno... somos unos frikis y nos gusta programar, hablamos y hablamos hasta que un día de principios de agosto me hicieron una propuesta formal: asumiendo que empezaba de cero con Rails, me querían en el equipo.

Yo estaba en plena fase de salida de producción del nuevo front y back de Privalia. Como buen profesional debía quedarme hasta el final así que la entrada la haría a principios de setiembre. Me tiré todo el agosto haciendo más horas que un reloj en Privalia y en los pocos ratos libres que me quedaron estuve estudiando Ruby on Rails. Con la coña casi no he tenido vacaciones pero ha valido la pena. Ya estoy metido de lleno.

Éste ha sido el motivo de mi larga ausencia. Con ello he caído de los rankings y Syntax Error a vuelto a ser un blog del montón (si es que nunca a pasado de aquí). Y para intentar remediarlo, aquí vengo con este post, en el que voy a intentar juntar la información y documentación que he usado para ponerme manos a la obra.

Qué es Ruby on Rails?

Ruby on Rails no es sólo un lenguaje, es un conjunto de un lenguaje (Ruby) sobre el que trabaja un framework (Rails). En comparación con PHP, Ruby sería el lenguaje como lo es PHP, y Rails sería la arquitectura que se levanta encima como lo podría ser el framework Zend.

En qué se diferencian Ruby y PHP?

La diferencia principal es la potencia. Si PHP es un lenguaje procedural (basado en funciones) al que paulatinamente le han dado soporte y potencia con la orientación a objetos, Ruby ya es de por si un lenguaje dónde absolutamente todo es un objeto, con lo que las posibilidades son casi infinitas. Gracias a éso, aparece una nueva diferencia a nivel de concepto: en PHP lo usual es tener algo (un string, un integer, un objeto) que pasas a una función o método para que haga el trabajo y te devuelve el resultado (otro integer, otro string, otro objeto). El Ruby lo usual es que el propio objeto (porque todo es un objeto) lleve los métodos con los que trabajar.

Pero PHP ya tiene soporte de objetos!

Si, y no va nada mal cuando te acostumbras a usarlo. En Atrapalo usábamos un framework propio que hacía un uso intensivo de los objetos. En Privalia el framework usado era Zend y en muchos aspechos se optimizaba el uso de los objetos. Pero hay conceptos que el PHP no tiene, como los code blocks de Ruby (snippets de código que puedes adjuntar a un método) o redeclarar una clase para agregarle funcionalidad (éso en PHP produce un Fatal Error), de forma que puedes hacer que una clase abra a otra y le agregue un par de métodos nuevos.

No me estás diciendo nada nuevo

Hay dos tipos de programadores: los reacios a los cambios y los que les gusta aprender. Si eres uno de los reacios tranquilo, PHP seguirá evolucionando y tendrás mayores opciones con las que jugar. Siempre lo ha hecho. Si eres uno de los segundos encontrarás una potencia de lenguaje sorprendente con la que el concepto de aplicación la enfocas desde otros puntos de vista, como plugins a un core principal, módulos atómicos que se interrelacionan entre ellos...

Vale, quiero empezar con algo

Primero de todo debo decir las versiones que actualmente se están moviendo en RoR.

Versión de Ruby: 1.8.6
Versión de Rails: 2.1.1

Sería interesante que instalaras un entorno para las pruebas que quieras hacer mientras lees los manuales. La instalación básica es muy fácil. Todas las instalaciones de RoR que he hecho (incluso en mi eeePC) han sido usando este pequeño y efectivo tutorial: How to install Rails 2.1 on Ubuntu in 5 steps, aunque voy a poner las pasos rápidamente a continuación:

1.- Instalar ruby

sudo apt-get install ruby rdoc irb ruby1.8-dev rubygems libopenssl-ruby

2.- Actualizar el gestor de paquetes Gem a la última versión

sudo gem update --system

3.- Eliminar la versión antígua de Gem

sudo apt-get remove rubygems

4.- Creamos un enlace para que los programas que busquen el Gem eliminado ejecuten el Gem nuevo

sudo ln -s /usr/bin/gem1.8 /usr/bin/gem

5.- Instalar Rails

sudo gem install rails

Además, lo suyo es ejecutar Ruby on Rails sobre MySQL, así que deberíamos instalar el servidor MySQL con la librería de Ruby correspondiente:

sudo apt-get install mysql-server libmysql-ruby

Una vez se tiene el entorno montado simplemente es cuestión de seguir algun manual. Qué manuales deberíamos seguir? Bueno, aquí la cosa depende de los gustos de cada uno. Voy a dar una lista de manuales que valdria la pena seguir desde mi punto de vesita.

• Pargmatic Bookshelf - Programming Ruby (2nd edition). Ideal para aprender el lenguaje Ruby. No se toca nada de Rails. Genial para coger base en el lenguaje
• The Rails Way. Enseña la forma de trabajade Rails, explicando las capas de abstracción que Rails usa. Según mis compañeros de moterus.es, "indispensable"
• Rails for PHP developers. Genial libro dónde da por supuesto que sabemos programar en PHP, usando ésto para enseñarnos Rails. Se avanza muy rápido, y no sustituye los dos anteriores.

He puesto lo enlaces de Amazon para tener claro qué libros son, pero supongo que no tendréis problemas para encontrar sus versiones en PDF por internet

Qué otros recursos son interesantes?

Isaac y Francesc me pasaron un listado de enlaces interesantes. Simplemente los voy a reproducir aquí:

• http://api.rubyonrails.org: Toda la API de Rails
• http://www.ruby-doc.org/: Documentación de Ruby
• http://railscasts.com/: Imprescindible para iniciarse en las best-practices
• http://buildingwebapps.com/site/home: Lleno de artículos, podcast interesantes
• http://www.ruby-forum.com/: Foro de Ruby
• http://www.railsenvy.com/: Podcast semanal, algo más avanzado
• http://www.caboo.se/: Buena calidad de artículos

A medida que vaya aprendiendo más sobre este entorno escribiré más. Ahora en SyntaxError tenemos un nuevo tag Ruby on Rails

Salu10.

El problema viene cuando la cantidad de registros se vuelve grande... En unas pruebas con registros de producción nos encontramos que el grid se demoraba mucho en mostrarse... Pusimos algunas alertas y llegamos a la conclusión que de 20 segundos que tardaba en montarse el grid, sólo 5 correspondían a la generación del XML y el resto era tráfico de red y proceso javascript.

Pero cuánto pesa el XML? Un mega y medio de XML? Y cómo lo hacemos más pequeño para generar menos tráfico y ganar tiempo? Comprimiendo el XML de salida...

¿De qué se trata?

Los datos que se encargan de montar una página web son básicamente imágenes y diferentes tipos de datos en texto plano. Las imágenes habitualmente ya vienen comprimidas (JPG, PNG, GIF,...), pero el texto plano (HTML, XML, CSS, ...) es altamente comprimible... Simplemente es código ASCII que se repite y repite en el mismo archivo. Si enviamos el texto plano comprimido estamos enviando realmente menos datos por la red, consiguiendo que la totalidad de los datos llegue antes al navegador, quien descomprime los datos y obtiene el código HTML, XML, CSS o lo que sea como si se hubiese enviado así directamente.

¿Y los navegadors lo soportan?

Casi la totalidad de navegadores actuales soportan la compressión de datos HTTP. De hecho, desde 1998 los navegadores han ido soportando el protocolo HTTP 1.1, que esencialmente indica que el navegador soporta "content encoding".

Internet Explorer soporta compresión HTTP desde la versión 4 (teniendo que activar HTTP 1.1 en sus propiedades) aunque las versiones para Mac 4.5/5 no lo soportan. Netscape lo soporta desde la versión 4 aunque da bastantes fallos. Su versión 4.5 empieza a ser más interesante y la 6 funciona ya plenamente. Opera soporta la compresión desde su versión 5. Firefox desde su versión 1.

Para asegurarte que tu navegador soporta compresión puedes usar el test HTTP trace. Si aparece una línea dentro del cuadro "HTTP request received from browser" con un texto similar al siguiente es que sí que lo soporta:

ACCEPT_ENCODING: gzip,deflate

¿Cómo implementarlo?

Se puede hacer de 3 formas:

1. Activar a nivel TOTAL del ámbito del php del servidor (editar php.ini)
2. Activar a nivel LOCAL para un sólo site de todo el ámbito del PHP (.htaccess)
3. Activar a nivel de SCRIPT (un sólo archivo.php)

1.- TOTAL

1. Editar el php.ini de apache
   

   $ vim /etc/php5/apache2/php.ini

2. Cambiar el valor de los parámetros siguientes:
   

   zlib.output_compression = On
   zlib.output_compression_level = 7

3. Guardar y salir
4. Reiniciar apache
   

   $ /etc/init.d/apache2 restart

2.- LOCAL

1. Editar o crear el archivo .htaccess en el directorio del sitio a aplicar
   

   $ vim /var/www/misitio/.htaccess

2. Insertar las siguientes líneas:
   

   php_flag zlib.output_compression on
   php_value zlib.output_compression_level 7

3. Guardar y salir (no es necesario reiniciar)

3.- SCRIPT
Hay dos formas de hacerlo:

1. Insertar al inicio del script la siguiente línea
   

   ini_set('zlib.output_compression', 'On');

   NOTA: Según el comentario en php.net esta forma no funciona.
   Personalmente yo no lo he probado.

2. Insertar al inicio del script la siguiente línea
   

   ob_start("ob_gzhandler");

   NOTA: Sin haber activado el zlib desde php.ini, al ejecutar ésta línea me causaba un error.

Niveles de compresión:

Van de 0 a 9 indicando de menos a más compresión respectivamente. A menos compresión más rápido es y menos CPU consume, pero menos comprime. A más compresión se tarda más en comprimir y consume más CPU, pero la compresión es mejor. Establecer el valor a -1 hace que se deje a elección del propio PHP el nivel de compresión (generalmente 6).

¿Cómo saber si está funcionando?

Se pueden usar herramientas de testeo como HTTP Analysis Tools. Para este caso, probar la primera herramienta "Compression Check"

Experiencia personal

En el proyecto que he descrito, el XML medio pesaba sobre 1,5 MB. Al comprimir la salida se queda en unos 35 KB, una muy buena mejora. La solución que tomé fué aplicar la compresión a todo el site setando los parámetros directamente en el php.ini. La generación del XML sigue tardando lo mismo pero el tiempo total para tener el XML listo en el navegador descendió de 25 segundos a unos 10 segundos... una muy buena mejora

Luego, quise hacer lo mismo en este blog. Como está alojado en un servidor compartido no tengo acceso al php.ini, así que probé de hacer el setado por .htaccess, pero obtuve siempre un error 500. La única forma de hacerlo funcionar fué editar el archivo index.php y colocar en la primera línea el ob_start("ob_gzhandler"). La compresión funcionó y los registros mejoraron, pero la experiencia del usuario empeora debido a que el el navegador no renderiza hasta que no le han llegado todos los datos... y cómo hay algunos scripts de publicidad que se llaman y demoran todo el conjunto, la web se queda unos segundos (que se hacen eternos) en blanco. Así que lo quité dejándolo sin comprimir. Así, almenos, el usuario ve que se le va renderizando la web sobre la marcha y no tiene la sensación de que el sitio está colgado.

Más información:

• http://es.php.net/manual/es/ref.zlib.php
• http://www.pmichaud.com/wiki/Cookbook/OutputCompression

Uno de los problemas más habituales aparece cuando tengo muchas fotos de varias cámaras tomadas del mismo viaje. Al juntar las fotos y tratar de verlas me encuentro en que (obviamente) es casi imposible verlas respetando un órden cronológico. Windows permite ordenar por fecha de captura y luego visualizarlas correctamente, pero a la hora de hacer un redimensionado masivo se pierde la información de la ordenación y del EXIF (dónde se guarda la fecha de captura).

El sencillo programa que presento aquí recoge todas las fotos de una carpeta, las ordena por fecha de captura, y las renombra con un nombre general dado y un número de foto para hacerlas consecutivas. Así, una vez realizado el proceso podremos usar cualquier programa de tratamiento masivo, aunque pierda la información EXIF, porque ya las tendremos en el orden correcto.

Para más información y descargas del programa, visitad la página del proyecto: Autonombrado Ordenado v1.0, dónde también se encuentra el código fuente para Visual Basic 2005.

Resulta que tengo una query... sencilla en concepto, un par de joins cruzados... La construyo en local contra MySQL 4 y funciona perfectamente... y al subirla al servidor de producción con MySQL 5 simplemente me devuelve 0 rows. Estoy literalmente alucinando.

Explicación del escenario

Se trata de tres tablas con relación N:M, es decir, dos tablas principales y una que las une:

variables
---------
id (pk)
name

var_questions
-------------
id (pk)
id_variable (fk)
id_language (fk)
question

languages
----------
id (pk)
name
enabled

La tabla de variables contiene todas las variables registradas en el programa. La tabla languages contiene todos los idiomas disponibles en el programa. La tabla var_questions relaciona variables con languages y presenta el campo question que viene a ser el texto de la variable en el idioma determinado, es decir, para cada variable e idioma debe haber un texto.

Entonces yo necesito una query que me saque las inconsistencias (no las coincidencias), porque se trata de tablas MyISAM y en el proceso de desarrollo se puede haber creado un idioma sin haber generado ningún texto para él y para todas las variables. Mi query debe encontrar "lo que queda suelto".

La query

Usando la lógica (la mía, claro...) pensé: teniendo la lista de variables y la lista de idiomas, lo que debe presentar inconsistencias es la tabla intermedia. Entonces, podría hacer una query enlazando las variables con var_questions con un left join i la última con languages con un right join, para encontrar los nulls en la tabla intermedia var_questions. Luego le digo en el where que sólo quiero los nulls et violà.

La ejecuto en MySQL 4 y perfecto. Me saca justamente la información que necesito. Subo la query a producción, con un servidor MySQL 5 y me devuelve (con los mismos datos) 0 rows. Y justo ahí empieza mi odisea.

Investigando

La verdad es que poco más puedo investigar a parte de lo que haríamos todos: Googlear mucho, buscar problemas de compatibilidad, buscar documentación de JOINs, preguntar a cracks en el tema, dejar mensajes en foros, ...

Las versiones con las que juego son, en local, un MySQL 4.1.22-community-nt sobre Windows Vista, y en producción un MySQL 5.0.24a sobre Linux 2.6.9-023stab046.2-enterprise (Red Hat 3.4.5-2).

Durante las pruebas he encontrado una query que parece devolver los mismos resultados, pero no me gusta por el simple hecho que usa una CROSS JOIN que no podría explicar exactamente qué hace, pero parece hacer una producto cartesiano de las tablas enlazadas y no acepta un ON:

Cómo probar?

Tengo unos datos preparados por si alguien quiere hacer algunas pruebas (que serán agradecidas profundamente):

El resultado correcto debería ser el siguiente:

Colofón

Vale. No soy capaz de encontrar el problema. Será un problema de algún bug en la versión que uso para producción? Está mal planteada la query? A alguien se le ocurre algo?

Una cervecita para quien dé con la solución

Salu10

Todos los lenguajes incorporan parsers con los que poder leer y generar XMLs de una forma más o menos amena. Con la evolución de PHP a su versión 5 apareció una extensión llamada SimpleXML que, con un funcionamiento al estilo de objetos, simplificaba el acceso a los datos abandonando el método de llamadas a ciertas funciones al encontrar tags de apertura y cierre en el archivo XML.

Es una forma muy cómoda de trabajar es muy fácil acostumbrarse, pero a veces nos encontramos con hostings sólo en PHP 4 y nos vemos obligados a programar parsers a la vieja usanza.

Recientemente encontré una portabilidad de SimpleXML para PHP 4 que, aunque no dispone de absolutamente toda la funcionalidad de la extensión original (sobretodo al generar XML de salida), suple perfectamente la necesidad.

SimpleXML44 es el nombre de este backport de la extensión SimpleXML (escrito en PHP5) a PHP4. Según la web del autor, simplifica y optimiza el acceso a los datos y permite cambios en nodos CDATA y atributos, pero no es posible agregar o borrar ciertos nodos del árbol DOM. En mi toma de contacto (sólo lectura) cumplió perfectamente mis expectativas y ya lo tengo en mi biblioteca de paquetes de programación PHP.

Está escrito íntegramente en PHP. Requiere la versión de PHP 4.4.2 o superior y tener instalada la extensión XML Parser (Expat). La licencia es de tipo BSD. Actualmente forma parte del Ister PHP4 Framework aunque es posible descargarlo atómicamente, con lo que facilita nuestro desarrollo en nuestro propio framework.

Se puede descargar desde SourgeForge. La documentación del SimpleXML44 es algo limitada, pues se dan pocos ejemplos, pero habiendo usado el SimpleXML original nos hacemos una idea rápida de su funcionamiento.

Ejemplo de funcionamiento

Vamos a suponer un ejemplo rápido para ver lo simple que es. Pongamos que tenemos un archivo XML de la siguiente forma, guardado como 'clientes.xml' en la raíz:

Pues bién, lo primero es descomprimir el archivo bajado en un directorio, donde queramos, por ejemplo en /simplexml44. En el script PHP pondremos lo siguiente:

Como vemos, es una forma de trabajar similar al SimpleXML original, muy sencilla e intuitiva.

Notas a tener en cuenta

• Cada elemento hijo es un objeto.
• Para extraer la información de un elemento se usa $elemento->CDATA(), aunque el campo no esté definido como CDATA.
• Si un elemento tiene atributos, usando $elemento->attributes() obtenemos un array asociativo dónde la clave es el nombre del atributo y el valor es el valor del atributo.
• Si un elemento está repetido (en nuestro caso el elemento 'cliente') en vez de un objeto se devuelve un array de objetos (en nuestro caso, un array de objetos 'cliente').
• Si esperábamos un array de elementos pero sólo tenemos un sólo elemento, no se nos devuelve el array (lógico) y nuestro script puede fallar al esperar un array que no existe. La forma de manejarlo es mirando si es un array y si no lo es, poner el elemento dentro de un array:
  PLAIN TEXT
  PHP:

  if(!is_array($doc->clientes->cliente)) $aux = array($doc->clientes->cliente);
  else $aux = $doc->clientes->cliente;

• Si no es seguro que un elemento venga dado en el XML de origen, podemos preguntar si existe con isset():
  PLAIN TEXT
  PHP:

  if(isset($doc->clientes->cartera)) ...

Los errores que devuelve SimpleXML44

SimpleXML44 devuelve errores si los encuentra. Tanto si el archivo de entrada no existe, como si hay algun fallo en el XML, devuelve un error al estilo Warning que no es enviado al log, sino que se muestra por pantalla en una forma un tanto peculiar.

Si no encuentra el archivo muestra por pantalla la ruta dónde debería estar, sin más, algo cómo:

/ruta/al/archivo.xml

Si el código del script hacer referencia a un elemento que no existe y no lo hemos protegido con el isset() se quejará devolviendo un Fatal Error así:

Fatal error: Call to a member function on a non-object in /var/www/script.php on line xx

Si el XML no está bién formado devolverá un Warning propio al estilo:

WARNING isterxmlexpatnonvalid->parse(): expat: mismatched tag [217021/43/1846]

dónde los números entre los corchetes significan lo siguiente:

• El primero: Posición del Byte dónde está el error
• El segundo: Columna en el archivo XML donde está el error
• El tercero: Línia en el archivo XML donde está el error

Conclusión

SimpleXML44 es una portabilidad a PHP4 que nos permite la comodidad de la extensión SimpleXML de PHP5. Algo limitada y sufrida con los errores, pero versátil y fácil de usar. Si debes portar una aplicación a PHP4 a causa de las limitaciones que el servidor dónde te hospedas, usas XML y estás acostumbrado al SimpleXML original, dále un vistazo que puede ser muy útil.

Salu10

Después de un tiempo comunicándonos mediante la lista de correo, un par de quedadas birreras para romper el hielo y una primera conferencia en el horizonte, uno se alegra de tener por fin una web en el aire y le deseo un buen SEO para el 2008

Si programas en PHP y eres de Barcelona no puedes dejar escapar ésta oportunidad de conocer más programadores como tú e intercambiar opiniones y métodos.

Salu10.

En primer lugar cabe decir que antes de meterme con ésto intenté la solución de Joomla SEF Patch creyendo (erróneamente) que me permitiría tener el control sobre los títulos HTML, así que puede que los números de línea sean incorrectos y es por éso que hago referencia a los nombres de las funciones y métodos, con su estado inicial.

1.- Crear un campo nuevo en la lista de parámetros
El primer paso es añadir un parámetro nuevo a la lista de parámetros de los componentes que nos interesen para poder personalizar el título. El texto a introducir es la definición del nuevo campo que se añadirá:

<param name="title_cust" type="text" size="20" default="" label="Título de la página" description="Un título personalizado a aplicar a la página, ésto permite títulos individuales por página" />

Los archivos que deberemos editar son los XMLs de configuración de los componentes a los que querremos personalizar el título HTML. En mi caso he pecado de "lo hago en todos", pero normalmente se querrá editar solamente los XMLs de los contenidos dinámicos (com_content) y estáticos (com_typedcontent). La lista entera es la siguiente:

-> administrator/components/com_menus/component_item_link/component_item_link.xml
-> administrator/components/com_banners/banners.xml
-> administrator/components/com_banners/com_contact/contact.xml
-> administrator/components/com_banners/com_contact/contact_items.xml
-> administrator/components/com_content/content.xml
-> administrator/components/com_frontpage/frontpage.xml
-> administrator/components/com_login/login.xml
-> administrator/components/com_massmail/massmail.xml
-> administrator/components/com_media/media.xml
-> administrator/components/com_menumanager/menumanager.xml
-> administrator/components/com_newsfeeds/newsfeeds.xml
-> administrator/components/com_poll/poll.xml
-> administrator/components/com_search/search.xml
-> administrator/components/com_syndicate/syndicate.xml
-> administrator/components/com_trash/trash.xml
-> administrator/components/com_typedcontent/typedcontent.xml
-> administrator/components/com_users/users.xml
-> administrator/components/com_weblinks/weblinks.xml
-> administrator/components/com_weblinks/weblinks_item.xml
En principio en todos los componentes de administrator/components que tengan un archivo de configuración XML

Ahora aparecerá un campo más en los parámetros de los componentes editados, pero aún no hará nada

2.- Editar la llamada al setado del título
El setado del título se hace llamando a un método del objeto que construye la página. Este método se llama simplemente pasándole el título pero ahora necesitamos que reciba también la lista de parámetros para que recoja el título que le hemos especificado.
Para ello tenemos que editar el archivo components/com_content/content.php y sobre la línea 1676 encontramos el siguiente código:

Debemos modificarlo para que acepte también los parámetros:

3.- Editar la función de setado del título
Ahora la función recibirá los parámetros. Debemos modificarla para que los acepte correctamente y recoja el posible título setado, si existe, y lo defina como tal. Para ello editamos el archivo includes/joomla.php y buscamos la declaración del método setPageTitle() que está dentro de la clase mosMainFrame sobre la línea 507:

Sustituiremos la función por la siguiente. Debemos poner especial atención en la propia declaración del método, que ahora debe aceptar un segundo parámetro, que serán los parámetros definidos en la administración (valga la redundancia):

Si nos fijamos, lo que hemos añadido es un checkeo para ver si recibimos el nuevo parámetro $params, y si es así recogemos el parámetro 'title_cust'. Si no intentará generar los parámetros según el estado actual del Item a mostrar para recoger el título definido. Y si aún así no hay título, pues setará el título que Joomla ya hacía de por sí.

4.- Asegurarnos que siempre se sete el título
Siguiendo el threat del tutorial original ví que no siempre se setaba el título. La forma para obligar siempre a setar el título pasa por llamar al método setPageTitle() justo después de crear el objeto que se encarga de montar la página. Así, editamos el archivo index.php situado en la raíz del Joomla (ojo, no el de la plantilla!) y sobre la línea 105 tenemos la inicialización del objeto MainFrame:

Justo debajo añadiremos la siguiente línea:

Una vez realizado ésto ya podremos personalizar los títulos HTML de nuestras páginas.

5.- Añadir soporte para JoomFish
Si tenemos una web multilingüe nos daremos cuenta que no es correcto tener el contenido en un idioma y el título en otro... Para solucionar ésto debemos dar soporte a la traducción de los parámetros en la pantalla de traducción del JoomFish. Deacuerdo, no es muy correcto poder "traducir" todo el objeto de parámetros, pero digamos que es la forma fácil/rápida de darle soporte.
Para ello debemos añadir un nuevo campo en el archivo de configuración de la plantilla de traducción de contenido de JoomFish, editando el archivo XML administrator/components/com_joomfish/contentelements/content.xml y añadiendo la línea siguiente:

<field type="textarea" name="attribs" translate="1">Attributes (inc. Title Custom)</field>

Y dado que no sólo hemos editado los componentes de contenido sino que también otros componentes (ver paso 1) deberemos dar soporte también a ésos tipos de elementos en las traducciones añadiendo la siguiente línea:

<field type="textarea" name="params" translate="1">Atributos (inc. Title Custom)</field>

en los siguientes archivos:

-> administrator/components/com_joomfish/contentelements/category.xml
-> administrator/components/com_joomfish/contentelements/contact.xml
-> administrator/components/com_joomfish/contentelements/newsfeeds.xml
-> administrator/components/com_joomfish/contentelements/polls.xml
-> administrator/components/com_joomfish/contentelements/section.xml
-> administrator/components/com_joomfish/contentelements/weblinks.xml

Y ya tenemos soporte para la traducción del título. ¿Cómo lo traduciremos? Pues bién, al entrar en la traducción de un elemento, por ejemplo, un contenido, veremos una sección más debajo de todo dónde se vuelca todo el contenido de los parámetros. Uno de ellos es el título llamado title_cust. Debemos copiar TODO EL OBJETO y pegarlo en la caja de texto, separando cada parámetro por un salto de línea, y luego procedemos a traducir el título al idioma deseado.
Guardamos y listo!

Saludos.

1.- Modificación de las plantillas

Primero de todo debemos modificar las plantillas de la administración para insertar un campo de texto nuevo que será el que controle el atributo title. Debemos hacerlo tanto para el contenido normal como para el contenido estático:

Contenido normal:
Editamos el archivo administrator/components/com_content/admin.content.html.php y sobre la línea 890, debajo del TR del texto de la etiqueta, insertar:

Contenido estático:
Editamos el archivo administrator/components/com_typedcontent/admin.typedcontent.html.php y sobre la línea 636, debajo del TR del texto de la etiqueta, insertar:

2.- Modificar la función Javascript

Debemos modificar la función Javascript que aplica los cambios introducidos, para que tenga en cuenta el nuevo campo que hemos insertado. Para ello debemos editar el archivo includes/js/joomla.javascript.js, y sobre la línea 250 encontramos la función:

Aquí debemos añadir el nuevo campo title al final de todo, dejando la función de la siguiente manera:

Notar que después del form._width.value hemos añadido un separador más y justo debajo una línea nueva con el valor del campo title.

También debemos modificar la función que muestra las propiedades de la imagen cuando pinchamos sobre una de las imágenes de la lista. En el mismo archivo, sobre la línea 232 tenemos la función showImageProps():

La debemos modificar, incluyendo el nuevo campo title. Para ello añadimos una línea más justo después del form._width.value que adquiera el valor del title, quedando la función de la siguiente manera:

3.- Modificación del Mambot

Joomla sustituye en tiempo de ejecución el tag {mosimage} por la imagen que hemos definido y le aplica las propiedades que hemos puesto. Así que será ahí dónde debemos tocar el código PHP para que recoja el nuevo campo y lo aplique como title. Para ello debemos editar el archivo mambots/contents/mosimage.php y, sobre la línea 99 encontramos la declaración de la función processImages(). Dentro de ella se recoge el string que contiene los parámetros de la imagen separados por un "pipe" y lo convierte en un array, por lo que como en el paso anterior hemos añadido nuestro title al final, será la última iteración del array.
Así que sobre la línea 159, justo debajo del IF que comprueba y seta el atributo 7 (la anchura o width) debemos insertar el siguiente código:

Este código hace el mismo trabajo que para el atributo 2 (el alt) pero trabajando sobre el nuevo campo title.
Finalmente, en la línea 186 (después de haber insertado el código anterior) encontramos la siguiente línea:

Como vemos, Joomla usa el mismo texto del alt para el alt y para el title. Como ahora tenemos un atributo nuevo para el title, simplemente tenemos que cambiar el atributo al que se hacer referencia para el title, de 2 a 8, quedando la línea de la siguiente forma:

Y ya tenemos soporte para los dos atributos por separado

Saludos!

Realmente no nos vamos a meter a modificar la forma en que se maqueta el contenido (de momento ) así que sencillamente mantendremos la columna pero añadiremos un H1 rodeando el echo del título y moveremos la declaración de la clase que le da el estilo al H1. Dejaremos la función de la siguiente manera:

En mi caso no ha sido necesario, pero puede que debamos ajustar un poco la hoja de estilos. Éso es todo