Luego de unos días de investigación sobre las posibilidades actuales de DokuWiki, he llegado a la conclusión de que sería conveniente utilizarlo como plataforma para unificar los diversos “sitios web” que hemos estado alojando por separado en inmabb.criba.edu.ar y catalis.uns.edu.ar, así como futuros espacios como p.ej. un blog.

Algunas características de esta propuesta:

• Decidir si se alojará en CONICET o UNS (Biblioteca Central). Una ventaja importante del alojamiento en la UNS es la posibilidad del acceso por shell, y de acceder más directamente al servidor con bases de datos ISIS. Habrá que tramitar un dominio nuevo, e.g. inmabb.uns.edu.ar. Ver conversación por mail con Santiago Aggio (16-03-2009).

• Decidir si el DocumentRoot para ese dominio apuntará a la carpeta dokuwiki o a una carpeta superior. Notar que si DocumentRoot es dokuwiki aun puede alojarse contenido extra-wiki dentro de esa misma carpeta, aunque resulte algo sucio. Una mejor solución podría ser: DocumentRoot es dokuwiki, y definimos Alias para acceso a otras carpetas.

• Planificar la migración de los sitios existentes (ver tips:htmltowiki para convertir desde HTML, especialmente HTML::WikiConverter), y asegurar mecanismos de redireccionamiento (HTTP 3xx, ver URL redirection).

• Usar una única instalación, y organizar los “sitios” usando namespaces. La alternativa de configurar varios wikis por separado (atados a una instalación común), i.e. farming, parece atractiva pero tal vez algo complicada para nuestras necesidades. Corrección: hice la prueba y no parece nada complicado (16-03-2009).

inmabb-conicet.gov.ar
www.inmabb-conicet.gov.ar
revuma.inmabb-conicet.gov.ar
opacmarc.inmabb-conicet.gov.ar

wiki farm:
  biblio.inmabb-conicet.gov.ar
  catalis.inmabb-conicet.gov.ar
  *.inmabb-conicet.gov.ar

FTP/SSH?

  inmabb
      dokuwiki
      opacmarc
      [otros]

• PHP
• Python

• Virtual hosts
• Logs

Backups, etc.

  instituto/
    investigacion/ o proyectos/
      - una página (o namespace?) por cada proyecto?
    private/  (acceso sólo a miembros del grupo instituto) 

  gente/
    - una página (o namespace?) por cada integrante del INMABB
    fernando_gomez/
      proyectos/  (quizás puedan ir en proyectos [informales] de la biblioteca, o dentro del namespace catalis?)
        abr/
        museo-mitre/
        ...
    leticia_giretti/
    adriana_starkloff/
    andrea_benitez/
    silvia_arroyo/
    julia_redondo/
    ines_platzeck/
    luis_piovan/
    ...

  biblio/
    blog/
    private/  (acceso sólo a miembros del grupo biblio)

  publicaciones/
    - una página por cada publicación? para los números nuevos, tabla de contenido y acceso a los PDF

  catalis/
    - páginas del viejo sitio (inmabb.criba.edu.ar/catalis/)
    - contenido del CatalisWiki
    private/  (acceso sólo a miembros del grupo catalis)

  revuma/
    - páginas del viejo sitio (inmabb.criba.edu.ar/revuma/)
    issues/
      - una página por cada volumen o nro. publicado
    private/   (acceso sólo a miembros del grupo revuma)
      edicion/
      scielo/

  files/ (?)   (no sé si esto tiene sentido en el wiki; los "media files" quedan asociados a namespaces ya existentes)

  user/
    una página (o namespace?) por cada usuario registrado en el wiki (tengan o no relación con INMABB)

  group/
    una página (o namespace?) por cada grupo de usuarios del wiki; útil p.ej. para group sidebars

  playground/ -- built-in

  wiki/ -- built-in

Al menos uno para la biblioteca. ¿Pueden coexistir varios blogs en el mismo wiki sin que se produzcan conflictos (e.g. al buscar por tags)?

• avatar
• blog
• bloglinks
• captcha
• discussion
• feedmod
• include
• linkback (ver config, parece complicada)
• pagelist
• tag

• blockquote
• cloud
• comment
• note

• superacl2

Va a ser conveniente instalar algún plugin que permita incluir matemática en las páginas del wiki. Aunque esto creará un requisito importante en el servidor: una instalación al día de LaTeX… excepto si usamos jsMath, que usa JS (pero se recomienda instalar fuentes TeX en el cliente). Ver plugins?plugintag=math.

• editsections
• displaywikipage
• loadskin
• multitemplate_styleman
• s5
• batchedit (útil para cambios globales en varios archivos usando expresiones regulares)
• sidebar (creo que ya no)

default y arctic; tal vez alguno más.

Sería bueno asociar diferentes templates a ciertos namespaces (vía plugin loadskin, aún no testeado). De acuerdo a lo visto con el template multitemplate, podrían darse cambios de template no deseados, potencialmente confusos para los usuarios.

IDEA: si sólo buscamos pequeñas variaciones de CSS entre namespaces (i.e., sin cambios a nivel de HTML), podríamos modificar el template (main.php) para que incluya el namespace como valor del atributo class o id del elemento body, y luego desde una hoja de estilo (inmabb.css) aplicar los cambios. MediaWiki ofrece eso, y en el foro de DokuWiki encontré apenas esta leve insinuación. Luego de probar, modificando main.php del template arctic,

<body id="<?php echo getNS($ID)?>">

veo que queda un problema: getNS('catalis:blog:probando_tags') = 'catalis:blog', pero queremos que getNS('catalis:blog:probando_tags') = 'catalis'. Arreglado con

<body class="<?php echo str_replace(':', ' ', getNS($ID))?>">

El uso de tags no necesita limitarse al contexto de blogs. ¿Hay un namespace para tags? Estudiar plugin:tag.

Probar {{tag>tagA tagB}} versus {{tag>tagA}} + {{tag>tagB}} ⇐ funciona, pero no es bueno porque separa en filas.

Hay varias funcionalidades, propias de un wiki, que no queremos tener habilitadas para los sitios más estáticos. Por ejemplo, al visitar una página inexistente, en lugar de “Este tema no existe todavía” habría que redireccionar a la página principal del sitio, o usar un 404 (probé la config send404 y no dio resultado). Ver las versiones anteriores de una página podría ser una función no deseada.

La deshabilitación puede hacerse a un nivel “cosmético”, simplemente ocultando con CSS los respectivos elementos de la interfaz, pero esto no impide que un usuario decidido (o sin CSS) pueda acceder a dichas funciones.

La deshabilitación real se controla desde el Administrador de configuración, y tiene un alcance global: no se puede aplicar sólo para un namespace.

Así que aquí tenemos un problema pendiente.

Una sidebar por namespace. Pero en biblio deberíamos poder ver la sidebar de instituto también. Probar un include.

Probado. Aparece el botón “Editar esta página” para todo el mundo, junto al encabezado de la página incluida.

¿Cómo puedo tener una sidebar en el namespace blog sin que la página sidebar aparezca como una entrada del blog? El plugin blog considera “entrada” a todas las páginas que viven dentro del namespace especificado.

Las TOC de las páginas (que en arctic pueden ubicarse en la sidebar) empiezan desde el H1, y eso me parece innecesario, pues no agrega información útil, pero agrega un nivel de indentación (y no sobra el espacio!). Solución: ver config:toptoclevel.

Creé un usuario genérico user, para pruebas. Fue creado, pero “No se pudo enviar la notificación por correo electrónico”.

¿Qué debería mostrar la página raíz del wiki? Una de estas dos opciones:

• Una página con el menú de sub-sitios disponibles
• Redirección automática a inmabb.uns.edu.ar/instituto/

Los metadatos no aparecen cuando estamos viendo una entrada aislada; sí cuando vemos la lista de entradas.

Los permalinks que aparecen al pie de las entradas del blog, generados por el plugin include, muestran el nombre de la página, pero me gustaría más si mostrase sólo el texto “Permalink”, o tal vez sea mejor omitir el permalink.

Está usando el formato YYYY/MM/DD. ¿Cómo cambiamos al formato DD/MM/YYYY? Arreglado: config:dformat. Pasar a dd-mm-yyyy

Para wiki en más de una lengua, ver plugin:multilingual.

• ¿Páginas de wiki, o archivos HTML? Los primeros tienen la ventaja de que son editables desde el wiki; los segundos requieren acceso por FTP, pero permiten tener control fino sobre el HTML.

• Ejemplo de menú de navegación horizontal: http://wmi.math.u-szeged.hu/xaos/doku.php?id=topbar . Ver también el template:simple, del mismo autor del arctic.

• 2009-03-12: voy a intentar incorporar al template:arctic la topbar del template:simple: agrego un <div> en main.php, una función tpl_topbar en tpl_functions.php, los estilos asociados a navi (ojo: están en simple_design.css y simple_print.css), csshover3.htc (para IE), agrego a style.ini algunos parámetros del style.ini del simple. Anda bien.

• Plugins que se ocupan de cuestiones de navegación (plugins?plugintag=navigation):
  • plugin:indexmenu: no es lo que necesitamos
  • plugin:navilevel: demo
  • plugin:navi: probarlo. Permite tener menúes jerárquicos sin requerir una estructura jerárquica de namespaces. Este parece que nos resuelve el problema de resaltar el ítem correspondiente a la página actual sin complicar el CSS (sólo usamos una clase “curid”). La pequeña molestia es que cada bloque de la sidebar (becarios, investigadores, etc.) requiere un navigationmenu aparte.

El problema que queremos resolver se encuentra claramente descripto p.ej. en Where Am I? (A List Apart).

Básicamente se trata de que:

• El ítem del menú de navegación correspondiente a la página/sección actual esté resaltado
• El ítem del menú de navegación correspondiente a la página actual no sea un link
• El ítem del menú de navegación correspondiente a la sección actual sea un link (excepto por el punto anterior)

Explicar lo que buscamos.

Una buena solución sería hacer que PHP …

Otra, con CSS puro …

• IE6 no reconoce los attribute selectors de CSS. Hay solución con JS.

Uso de curid en el código de DokuWiki:

En la versión 2009-02-14 aparece en dos lugares:

• inc/template.php: function tpl_breadcrumbs, usa <span class=“curid”> para resaltar el último crumb
• inc/parser/xhtml.php: function internallink, usa <span class=“curid”> para resaltar link a la página actual

Sin embargo, no se usa .curid en el template default (ni en al arctic).

Ejemplo: este es un link a la página actual (en el código fuente se podrá ver class=“curid”).

(En el foro y en el wiki de DW apenas se menciona este tema.)

En algunos templates que utilizan sidebars o menubars para navegación (e.g. arctic), no se usa el <span class=“curid”> debido a que no es compatible con el mecanismo de cache para el elemento incluido (sidebar o menu), ver template:arctic#enhancementwork_with_span_class_curid; de todos modos aparece esta mención en la página del plugin navilevel. Tendríamos que ver si vale la pena sacrificar las ventajas del cache para nuestro caso.

En el artículo Navigation Menus: Trends and Examples de Smashing Magazine se describe una técnica que me gusta, consistente en agregar unas palabras descriptivas al texto de cada ítem de un menú de navegación. Un buen ejemplo se ve en http://lonnroth.info/:

<ul id="nav">
  <li><a href="/#web" title="View works in web design and development"><strong>Web design</strong> and development</a></li>
  <li><a href="/#illustration" title="View works in icon and identity design"><strong>Illustration</strong> of icons and logos</a></li>
  <li><a href="/#music" title="View musical works"><strong>Music</strong> in misc. genres</a></li>
</ul>

/* Navigation */
 
#nav {
	list-style: none;
	width: 475px;
	background: #3d2e2a;
	overflow: hidden;
	margin-left: 310px;
	padding-left: 10px;
}
#nav li {
	width: 155px;
	float: left;
}
#nav li a.active {
	outline: none;
}
#nav li a {
	display: block;
	text-decoration: none;
	text-transform: uppercase;
	font-size: 0.70em;
	font-weight: normal;
	color: #806650;
	padding: 15px 0 15px 10px;
}
#nav li a strong {
	display: block;
	color: #f5e4cc;
	font-size: 1.31em;
}
#nav li a:hover {
	background: url('img/nav.gif') 0 0 repeat-x;
}

Queremos lograr esto en el wiki, preferentemente con el mecanismo de navegación que venimos usando: la topbar del template:simple. Lo único que necesitamos es poder insertar formato (strong) dentro del texto de un link. No parece trivial, dado que el parser ignora formato dentro de un link, e.g. no podemos poner [[.:|**Bold text** normal text]] y obtener “Bold text” en negrita, aunque sí funciona esto: **[[.:|Bold text]]**. Oficialmente, “The image formatting is the only formatting syntax accepted in link names.” (fuente: syntax).

Caminos posibles:

• Afectar (mediante plugin?) el comportamiento del parser para que permita formato en linksde manera general (tal vez tocando la class Doku_Parser_Mode_internallink en parser.php)
• Crear un plugin que defina una sintaxis específica para links con formato.
• Aplicar una solución ad hoc para el template que usamos; p.ej. un simple reemplazo con una expresión regular sobre el xhtml de la topbar:

php > $xhtml = '<a>Link **bold** text</a>';
php > print $xhtml;
<a>Link **bold** text</a>
php > print preg_replace('/\*\*([^<]+)\*\*/','<strong>$1</strong>',$xhtml);
<a>Link <strong>bold</strong> text</a>
php > $xhtml = '<ul><li><a href="#">Link **bold** text</a></li><li><a href="#">**Another link** not bold text</a>';
php > print preg_replace('/\*\*([^<]+)\*\*/','<strong>$1</strong>',$xhtml);
<ul><li><a href="#">Link <strong>bold</strong> text</a></li><li><a href="#"><strong>Another link</strong> not bold text</a>

Esto último funciona bien.

2009-04-07. Luego de examinar el sitio con Paula Coscia, nos pareció conveniente que la portada de cada sección (e.g. gente:start) no incluya la barra lateral con el menú de navegación asociado a esa sección (o namespace), y que ese menú aparezca como contenido de la página. Para lograrlo hay que hacer algunas modificaciones, no sé bien en qué partes del código.

Una primera y sucia solución, sin alterar el código, se puede lograr con CSS, ocultando el menú para páginas específicas. Para esto necesitamos poder reconocer la página “start” mediante el atributo id o class del body.

2009-05-07: probé el plugin:alphaindex para mostrar un índice de las materias en el namespace guias:materias de la Biblioteca.

El orden alfabético pone “é” antes que “a”.

• En main.php del template, los atributos id que generamos llevan un doble guión bajo (__), para evitar posibles conflictos con los id que DokuWiki genera automáticamente para las secciones de una página; éstos nunca pueden contener __ (tomado de devel:css).

• En main.php del template añadir al body un atributo class='do_'.$ACT HECHO

Aplicar background al container del post en la lista de posts, <div class=“include hentry”>. ¿Imagen de fondo?

Deberíamos tener un favicon por cada subsitio. Modificar main.php del template.

Ver cómo esconderlas. La opción config:mailguard no parece suficiente protección (Sebastián prefiere reCaptcha). Ver en el foro http://forum.dokuwiki.org/thread/2167

En Wikipedia: Address_munging.

Vamos a necesitar incluir algunos formularios en páginas específicas (además de los formularios para comentarios en el blog u otras páginas).

Ejemplos:

• Sugerencias sobre la biblioteca y sus servicios
• Pedidos: compra de libros, copias de artículos
• Consultas: búsquedas de información, etc.

Ver plugin:bureaucracy.

El sitio tendrá una sección para ser leída y usada solamente por el personal de la Biblioteca. Si queremos que un link a esta sección aparezca en el menú principal de navegación, pero que sólo sea visible para usuarios logueados con permiso, habrá que investigar cómo hacerlo (los links que ponemos en topbar aparecen siempre, apunten o no a páginas de acceso público).

Siguiendo las indicaciones de tips:farm2 estuve haciendo unas pruebas con una granja de wikis.

Esta es la estructura de carpetas para las pruebas:

~/www/html/dokufarm
   /farm
      /animal1.wikifarm.localhost    <= datos del wiki "animal1"
         /conf
         /data
      /animal2.wikifarm.localhost    <= datos del wiki "animal2"
         /conf
         /data
   /farmer                           <= el wiki maestro
      /bin
      /conf    <= sólo se usa al crear nuevos animales
      /data    <= idem
      /inc
      /lib
      /doku.php

Usé el setup basado en virtual hosts. Para eso, aprendí a crear subdominios de localhost. La línea inicial del archivo /etc/hosts queda así:

127.0.0.1 localhost wikifarm.localhost animal1.wikifarm.localhost animal2.wikifarm.localhost

Para dar de alta los virtual hosts en Apache, creo el archivo /etc/apache2/sites-available/dokuwiki-farm:

NameVirtualHost *:80
<VirtualHost *:80>
 
    ServerName wikifarm.localhost
    ServerAlias *.wikifarm.localhost
 
    DocumentRoot "/home/fernando/www/html/dokufarm/farmer/"
 
    <Directory "/home/fernando/www/html/dokufarm/farmer/">
 
        Order allow,deny
        Allow from all
        Options -Indexes
 
        AllowOverride AuthConfig FileInfo Limit
 
    </Directory>
 
</VirtualHost>

y en el directorio /etc/apache2/sites-enabled/ creo este link simbólico:

dokuwiki-farm -> ../sites-available/dokuwiki-farm

Luego de reiniciar Apache, tengo que ajustar los parámetros en preload.php, y luego visito el animal1 (habiendo creado previamente la carpeta asociada):

http://animal1.wikifarm.localhost/

que me redirecciona a

http://animal1.wikifarm.localhost/doku.php

Si visito el animal2:

http://animal2.wikifarm.localhost/doku.php

(antes de crear el directorio correspondiente a animal2), recibo el mensaje:

DokuWiki Setup Error

Sorry! This Wiki doesn't exist!

Para crear el animal2 uso el script de tips:farm2#using_a_script_to_setup_farms. (De paso, en ese script cambié cada uso incorrecto de “farm” por “animal”.)

Resultado exitoso. Instalé dos templates en dokufarm/farmer/lib/tpl, y ya tengo dos animales, cada uno con su propio template.

<note> A partir de la versión 2009-02-14 de DokuWiki, el archivo conf/local.php del animal no necesita la línea

@include(DOKU_CONF.'local.protected.php');

pues inc/init.php se encarga de ese include. </note>

Ver la página Embeber OpacMarc en DokuWiki.

Para generación de feeds desde DokuWiki, ver syndication, plugin:feed, tips:blogging#feed_setup