Para ello seguiremos los siguientes pasos:

1.- Nos vamos a la configuración del módulo en cuestión.

2.- En la opción “Posición” hay una select con las posiciones predefinidas para módulos. Sin embargo, pero esta select es escribible y podemos indicar una posición que no sea ninguna de las predefinidas. Ponemos una que nos sirva de identificador del módulo y guardamos los cambios.

3.- Creamos un artículo que va a ser el que se va a asociar a una opción de menú y que va a contener el módulo y simplemente ponemos:

{loadposition id_posicion_modulo}

Donde “id_posicion_modulo” es el id que hemos dado previamente para la posición del módulo. En realizado con esta línea no estamos incrustando el módulo sino que estamos definiendo ese artículo como una posición de módulos. Así, si creamos otro módulo con esta misma posición, también nos aparecería en este artículo.

Nota: No he puesto en práctica el incrustar más de un módulo, pero por lo que he leído por encima puede dar problemas a la hora de posicionarlos dentro del artículo.

4.- Creamos una nueva opción de menú y le asociamos este artículo.

Al pinchar sobre la opción de menú se nos debe aparecer el conjunto de pestañas cada una con el contenido del artículo que le corresponde.

Mejorando la solución: Extensión “Modules Anywhere”

A pesar de que la solución anterior me ha funcionado de entrada, no ha tardado en darme problemas. Concretamente, al intentar incrustar un módulo dentro de un artículo, que a su vez estaba dentro de una pestaña de la extensión Tabs Manager GK2. El contenido que quería para esa pestaña era un módulo reproductor de audio que no me ha funcionado. Así que de nuevo a buscar apaños. Lo que he encontrado ha sido el plugin “Modules Anywhere” muy sencillo y efectivo y además mejora lo anterior en qué si quieres puedes incrustar un único módulo y no posiciones de módulos. Se puede bajar de

http://www.nonumber.nl/modulesanywhere?tab=Download

La instalación es directa y su utilización es muy sencilla. La sintaxis se puede consultar aquí.

Aunque también la adjunto por si acaso fallara el enlace:

CSS que se adapte al navegador para que nuestro código sea cross-browser, sin utilizar hacks que provoquen errores de validación css2.0 ó css3.0.

Notas:

Para la solución del problema se usan ficheros PHP pero es igualmente válida para cualquier otro lenguaje de servidor.

El ejemplo se basa en el index.php de un tempalte Joomla, donde utilizamos el template.css para todos los navegadores más otros ficheros css que amplían o sobreescrbien a éste.

Solución

En la cabecera html, como último link a una css  (para que en el caso que sea necesario pueda sobreescribir los estilos anteriores) pondremos lo siguiente:

<link rel=”stylesheet” href=”templates/mi_template/css/styles.php” type=”text/css” />

Donde, como se puede ver, enlazamos con un fichero PHP, pero se le indica al navegador que el enlace es a una css.

En el PHP enlazado querremos obtener información sobre el navegador que se está usando para poder adaptar el código a éste. el script es el siguiente:

<?php

header(“Content-type: text/css”);

$d = detect();

$b = $d['browser'];

$v = $d['version'];

function detect()

{

$browser = array (“IE”,”OPERA”,”MOZILLA”,”NETSCAPE”,”FIREFOX”,”SAFARI”);

$info['browser'] = “OTHER”;

$info['os'] = “OTHER”;

foreach ($browser as $parent)

{

$s = strpos(strtoupper($_SERVER['HTTP_USER_AGENT']), $parent);

$f = $s + strlen($parent);

$version = substr($_SERVER['HTTP_USER_AGENT'], $f, 5);

$version = preg_replace(‘/[^0-9,.]/’,”,$version);

if ($s)

{

$info['browser'] = $parent;

$info['version'] = $version;

}

}

return $info;

}

if ($b == “IE” && $v == 6){

include ‘ie6.css’;

}

else if($b == “IE” && $v == 7){

include ‘ie7.css’;

}

else if($b == “IE” && $v == 8){

include ‘ie8.css’;

}

?>

Como vemos en función del navegador y versión que encontremos incluimos una u otra css, donde se incluirán los códigos específicos para dicho navegador que ampliarán o sobreescribirán los estilos genéricos definidos previamente.

Con esto ya podemos tener nuestro código crossbrowser css válido.

Referencias:

http://www.stylegala.com/articles/no_more_css_hacks.htm

SEO

Search Engine Optimization. Se refiere al hecho de preparar tu web para que los buscadores (o sea google) lo posicionen en los primeros puestos en búsquedas relevantes para el contenido de la misma.

SEF

Search Engine Friendly. Se refiere a que las urls sean lo más comprensibles posible. Si tomamos como ejemplo las dos url’s siguientes:

http://www.nerja-centro.com/index.php?option=com_content&view=article&id=1&Itemid=2&page_nr=17

http://www.nerja-centro.com/comercios/inmobiliarias

Nos daremos cuenta que tanto para las personas como para los buscadores es mucho más fácil deducir el contenido de la página que se mostrará en la segunda url (url SEF) que el de la primera (de ahora en adelante la llamaremos “parametrizada”) aunque en realidad, ambas pueden apuntar al mismo contenido.

Así pues si conseguimos que nuestras url’s sean SEF google podrá indexar mucho mejor los contenidos de nuestras web’s. Para ello se utilizan una serie de herramientas que consiguen la redirección de url’s, traduciendo url’s parametrizadas (necesarias para paso de parámetros get) a direcciones web más claras y conceptuales. Estas herramientas son básicamente ficheros de configuración de Apache que permiten este redireccionado.

mod_rewrite

Es un módulo de Apache que precisamente se utiliza para poder reescribir url’s. En posts posteriores veremos qué se debe hacer para activar el módulo.

.htaccess

Es el fichero donde se mapean las url’s parametrizadas con las correspondientes SEF. Este fichero dispone de una sintaxis (lenguaje gramatical) que permite mediante pocas líneas definir mapeos genéricos que valgan para todas las posibles url’s de nuestra web. Igualmente, si nuestra web es pequeña, también se pueden hacer mapeos concretos uno a uno. Más adelante se hablará un poco de esta sintaxis poniendo algún ejemplo.

robots.xml

También dispone de una sintaxis propia que, imagino, debe de ser bastante completa y llegar a permitir bastantes virguerías, pero a mi de momento me ha bastado con saber que sirve para indicar al buscador quédirectorios de nuestro sitio no queremos que indexe (temporales, librerías, directorios de instalación…) así como para indicar en qué xml se encuentra el mapa de nuestra web (generalmente fichero sitemap.xml).

sitemap.xml

XML que leerá el robot de google  y en el que le podemos indicar qué url’s queremos que indexe (aquí ya ponemos las url’s SEF), cada cuanto las modificamos e incluso definir una prioridad entre las diferentes páginas de nuestro sitio.

Google Analytics

Todavía desconozco el 90% del potencial de esta herramienta pero está claro que es imprescindible para poder hacer un buen seguimiento de las visitas de nuestras webs, informándote de las estadísticas más importantes, tanto para saber de donde vienen como para conocer las palabras clave que mas pueden optimizar tu posicinamiento en buscadores.

Pagerank

Puede que sea una de las grandes mentiras entorno al posicionamiento web. En la documentación de google y en muchas webs se destaca como algo totalmente crítico si queremos que google nos tenga en cuenta. De otras fuentes podemos leer que no sirve absolutamente de nada. Concretamente el pagerank es un índice que se asocia a nuestro sitio, según el número de links externos que lo referencian. Cuantos más sitios nos referencien mayor será nuestro pagerank y, teóricamente, mejor posicionados estaremos en google. Igualmente no todos los links que nos referencian cuentan igual, de manera que aquellos sitios que nos referencien que, a su vez, tengan un pagerank elevado, ponderarán más en el cálculo de nuestro índice y ahí es donde entra el concepto de directorios web.

Existen páginas que, al indicar una url, te dicen el pagerank, así como toolbars y plugins de firefox que hacen la misma función. Desconozco la fiabilidad de éstas.

Directorios Web

Son sitios web que basicamente agrupan links a páginas, clasificándolas por su contenido. La gestión de estos sitios es manual y se supone que hay unas personas detrás repasando las solicitudes de alta en directorios, que validan la calidad de los sitios y los clasifican. Se supone que estos sitios tienen un elevado pagerank y por tanto conseguir que te referencian dispara tu índice. Los más conocidos son el de Yahoo (privado) y el dmoz (mantenido por  voluntarios). Sinceramente yo he intentado darme de alta en los dos y meses después aun no aparezco referenciado.

Como se ha dicho en futuros posts se profundizará en los conceptos aquí mencionados, para ver como los podemos utilizar para el posicionamiento de nuestras webs.

Se puede bajar desde http://www.fckeditor.net/download. Inicialmente me bajé la versión 2.6.4 pero no me funcionaba con google Chrome. Me consta que esto es solucionable pero por temas de tiempo opté por bajarme la versión FCKeditor_N.zip con la última versión, subida la noche anterior, y se acabó el problema.

En cualquier caso la aplicación  es  muy completa, válida para usar con php, asp, perl, aspx y tal. Además incluye ejemplos para ver el funcionamiento multiidioma y diferentes configuraciones y skins del editor.

La instalación que busco (inicalmente) tiene las siguientes características:

• Php como lenguaje de servidor.
• Lengua española.
• Un skin cualquiera (los tres que trae están muy bien).
• Cogeré el ejemplo completo para, a partir de éste,  capar las opciones que no me interesen.

Así que todo lo que me sobra lo eliminaré.

Por otro lado me quiero quedar con una carpeta que contenga todo lo necesario (y sólo lo necesario) para disponer de una instalación del editor totalmente portable y limpia. Tendré que documentar un poco como se debe referenciar esta carpeta para integrar el editor en cualquiera página de cualquier aplicación, así como de qué manera se recogen los datos.

1.-ELIMINACIÓN DE FICHEROS INNECESARIOS

El directorio raíz de FCK es fckeditor/, las rutas se indicarán relativas a esta raíz.

1.1.-Lenguajes de servidor

Como he dicho la descarga viene con un conjunto de conectores y carpetas para poder integrar FCKEditor con cualquier lenguaje de servidor. Los directrorios en los que se encuentran los ficheros para los diferentes lenguajes son:

• /

Me quedo únicamente  con los js y fckeditor.xml. Personalmente preferiría que estos ficheros estuviesen organizados en un par de directorios, pero eso implicaría una serie de cambios de rutas que de momento prefiero evitar.

• /editor/filemanager/connectors

En este directorio se puede eliminar todo menos la carpeta php.

• /_samples/

De momento lo borro todo menos la carpeta html y el fichero sample.css. En realidad acabaré reubicando estos dos para cargarme la carpeta samples completamente (ya que como su nombre indica son ejemplos de utilización y esto no lo quiere tener dentro del directorio del editor), pero eso lo explico más adelante.

1.2.- Otros directorios prescindibles

• /editor/sources

Por ahora, se escapa del ámbito de mis objetivos el meterme en las fuentes del editor a nivel de js/AJAX, así que este directorio va completamente fuera.

• /editor/lang

Dentro de este directorio sólo dejo “es.js” (para español ).

• /editor/skins

Dentro de este directorio me quedo únicamente con el “default“.

Con esto ya me he quitado de encima todo lo que no voy a utilizar.

2.- REUBICANDO LOS EJEMPLOS PARA SACARLOS DEL DIRECTORIO DEL EDITOR

2.1.-Cambio de directorio

Del directorio “_samples” copiaré:

• sample.css (css que se sustituirá por la que utilicemos en nuestra aplicación)
• html/sample01.html (html que incluye el editor – En nuestra aplicación podría ser una php)
• sampleposteddata.php (action que recoje la cadena que se ha introducido en el editor)

Y los moveré fuera del directorio fckeditor/, al mismo nivel que éste. En este momento se puede eliminar la carpeta fckeditor/_samples.

2.2.-Cambios en las rutas que aparecen en los ficheros reubicados

En este punto indicaré las referencias cuyas rutas  se han de cambiar, aunque, en los casos reales, el valor de la ruta dependerá de donde se encuentre cada uno de estos ficheros.

sample.css no continen ninguna ruta así que éste no habrá que modificarlo.

• sample01.html

Contiene referencias a sample.css (ahora en su mismo directorio), fckeditor.js (al que ahora se referenciará como fckeditor/fckeditor.js) y el action del formulario sampleposteddata.php (ahora en su mismo directorio). También en este fichero se informa la propiedad BasePath del objeto javascript FCKeditor. Cambiamos el valor que se le da por “fckeditor/”.

• sampleposteddata.php

Contiene una referencia a sample.css. En este caso (como en el caso de sample01.html) se encuentra en su mismo directorio.

3.-OTROS CASOS

No sé por qué pero en el sampleposteddata.php, a la hora de mostrar por pantalla la información recibida del editor lo hace como

<?=$postedValue?>

A mi esto no me mostraba la info. Lo he tenido que cambiar por el <?php echo $postedValue ?> de toda la vida.

NOTA: Posiblemente para alguna configuración concreta serían necesarios algunos ficheros de los que se han eliminado. Si alguien detecta esta situación sería de agradecer un comentario explicándolo.

——————————————————————————————————————————–

Me faltaría explicar como configurar las opciones de la toolbar, pero ya miraré de hacerlo en un otro post.

Pasos previos

1. Evidentemente disponer de un alojamiento web.
2. Crear un usuario ftp para poder subir Joomla al alojamiento.
3. Crear una base de datos y un usuario administrador.
4. Conocer la lista de extensiones Joomla instaladas en la aplicación y disponer de los zips para instalarlos en remoto.

Empezamos con la migración

• Descomprimios el zip de joomla en local (recordar hacerlo dentro de un directorio vacío si no queremos que se nos mezclen los ficheros y directorios de Joomla con los demás).

• Subimos dicho directorio al servidor vía ftp.

• Accedemos al alojamiento vía web para realizar la instalación inicial de Joomla. En este punto no me entretengo demasiado ya que doy por hecho que el que va a hacer una importación ya ha instalado Joomla al menos una vez. Simplemente decir que aquí introduciremos los datos de conexión a la Bd que previamente hemos creado y los datos de la cuenta FTP.

Nota: Hasta ahora nunca había creado la capa ftp para Joomla y no me había hecho falta, pero acabo de averiguar que esto evita eventuales problemas con los permisos de los directorios. Estos problemas los detallaré en el próximo post de esta categoría ya que me ha llevado toda esta mañana encontrar la solución.

• Instalar todas las extensiones Joomla que hayamos necesitado en nuestro entorno local. Una vez tenemos Joomla instalado, accedemos al administrador y a través de “Extensiones->Instalar/Desinstalar” nos dedicamos a instalar las que necesitemos.

• Importar la base de datos local a la base de datos remota. Cualquier cliente de base de datos (sea mediante aplicación local – HeidiSQL, MySQLFront…- o aplicación web – phpMyAdmin i.e.) permite crear un fichero de exportación (que no dejan de ser los scripts sql para crear la base de datos con todo su esquema y contenido) e importar una base de datos a partir del fichero de exportación.

Nota 1: En mi caso inicialmente he creado el fichero de exportación con Heidi y he intentado importarlo desde mi alojamiento con phpMyAdmin. Por alguna opción de configuración que no le ha gustado me ha dado errores en los scripts. Por no entretenerme demasiado en encontrar el error he probado generar el script de importación con MySQLFront y se ha acabado el problema.

Nota 2: En otros casos, había realizado la importación de la BD previamente a la reinstalación de las extensiones. En este caso me ha dado problemas y creo que es menos problemático hacerlo en el orden que aquí indico para evitar conflictos al instalar extensiones debido a datos que se han importado a BD.

• Finalmente, como  dentro de Joomla había creado un directorio con código propio (al cual accedía mediante el plugin jumi para ejecutar php propio), he subido dicho directorio vía ftp.

Y con esto y un bizcocho he conseguido publicar mi aplicación Joomla. No dudo que para aplicaciones más complejas puedan aparecer problemas que obliguen a algún paso intermedio pero para una aplicación normalita me ha ido bien. Eso si, imprescindible escribir el post sobre los problemas con permisos de directorios y la capa FTP.

Aquí tenemos a un fulano que se ha currado un par de herramientas para cumplir el objetivo de crear copias de seguridad automáticamente cada cierto tiempo. Eso sí, sólo de la BD (mysql) aunque por lo que he visto hasta ahora, una primera aproximación al objetivo será realizar la copia de BD mediante una aplicación y la de las fuentes con otras (de hecho en el momento de escribir esto ya he encontrado otra herramienta que evita esto pero por respetar el orden de los acontecimientos pues  mantengo el comentario ).

Lo primero es su url.   http://www.dwalker.co.uk/

Aquí podéis encontrar las aplicaciones que he utilizado (más una tercera de gestión de usuarios, creo, que no he estudidado). Como digo son un par de webapp’s, en php-mysql:

• phpMySQLAutoBackup. Te descargas un zip, lo descomprimes y pones la carpeta resultante en el servidor web. Se le debe tocar el fichero run.php, donde se indican los datos de la conexión a la bd y a correr! Eso sí, sólo funciona en máquinas Linux, lo digo porque lo probé en local y, al ser un mundano que usa windows, el asunto no me funcionaba y ni daba ninguna pista del error ni encontré nada en el miniforo, hasta que caí en la cuenta y al subirlo al alojamiento (Linux) ya sí funcionó.

El resultado es un fichero de texto con los scripts para restaurar la bd (estructura y datos, claro) que te puede mandar por mail y/o guardar en su directorio backups (se le indica en parámetros adicionales de run.php).

• phpJobScheduler.  Buena herramienta (si los tests confirman que funciona tal y como se espera) para ejecutar scripts de manera planificada. Se descarga el  zip y  se descomprime. También se le debe indicar la conexión de la BD en un fichero config.inc.php.  La carpeta resultante se debe copiar como directorio de la aplicación donde se encuentren los scripts a ejecutar (este dato lo debería confirmar ya que sería una cierta limitación, pero creo que los tiros van por ahí). En el index de la aplicación se debe incluir (<include…/>) un php (si el index también lo es) o un tag imagen si es index.html. Esto lo explica en las instrucciones, no acabo de ver muy bien porque esto es así pero siguiéndolas me ha funcionado.

Este no sé si tiene como requisito que la máquina sea Linux ya que directamente lo puse en remoto.

He creado una tarea planificada en phpJobScheduler para que haga copias de seguridad de una base de datos remota cada hora y de momento me ha llegado el primer mail con el script de la BD. Mañana comprobaré que me han llegado cada vez que tocaba.

Si alguien quiere probar estas aplicaciones recomiendo ver las instrucciones del tal dwalker, ya que con lo que he puesto aquí seguramente el asunto cojea.