Tabla de Contenidos

DokuWiki para el INMABB

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:

Alojamiento

Dominios

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

Accesos

FTP/SSH?

Estructura de carpetas

  inmabb
      dokuwiki
      opacmarc
      [otros]

Software requerido

Apache

Cron

Backups, etc.

Envío de mails

Estructura de namespaces

  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

Blog

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)?

Plugins

blogging

syntax

admin

math

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.

otros

Templates

default y arctic; tal vez alguno más.

Templates para namespaces

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))?>">

Configuración del template Arctic

Tags

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.

Deshabilitar wiki functions

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. FIXME

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

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

FIXME ¿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.

TOCs

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.

Usuarios

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

Página de inicio

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

Metadatos de entradas de blog

FIXME 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.

Fecha de creación

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

Revista de la UMA: bilingüe?

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

Barras y menúes de navegación

Tratamiento especial del ítem de navegación correspondiente a la página/sección actual

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

Básicamente se trata de que:

FIXME Explicar lo que buscamos.

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

Otra, con CSS puro …

Uso de curid en el código de DokuWiki:

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

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.

"Speaking" block navigation

El concepto

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;
}

En DokuWiki

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: 

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.

Omitir sidebar con navi menu en "start"

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.

FIXME

Plugin alphaindex

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

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

Tips varios

Blog

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

Favicons

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

Direcciones de email

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.

Formularios

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:

Ver plugin:bureaucracy.

Sección para uso interno (staff)

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).

Experimento con wiki farm

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>

Cómo encajar el OPAC en DokuWiki

Ver la página Embeber OpacMarc en DokuWiki.

Feeds

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