====== 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: * 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 [[doku>tips:htmltowiki]] para convertir desde HTML, especialmente [[http://diberri.dyndns.org/wikipedia/html2wiki/index.html|HTML::WikiConverter]]), y asegurar mecanismos de redireccionamiento (HTTP 3xx, ver [[wp>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). ===== 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 ==== * PHP * Python ==== Apache ==== * Virtual hosts * Logs ==== 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 ==== * avatar * blog * bloglinks * captcha * discussion * feedmod * include * linkback (ver config, parece complicada) * pagelist * tag ==== syntax ==== * blockquote * cloud * comment * note ==== admin ==== * superacl2 ==== 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 [[doku>plugins?plugintag=math]]. ==== otros ==== * editsections * displaywikipage * loadskin * multitemplate_styleman * s5 * batchedit (útil para cambios globales en varios archivos usando expresiones regulares) * sidebar (creo que ya no) ===== Templates ===== //default// y //[[doku>template:arctic|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. [[wp>Help:Namespace#CSS_based_namespace_detection|MediaWiki ofrece eso]], y en el foro de DokuWiki encontré apenas [[http://forum.dokuwiki.org/thread/1574|esta leve insinuación]]. Luego de probar, modificando ''main.php'' del template arctic,
veo que queda un problema: ''getNS('catalis:blog:probando_tags') = 'catalis:blog''', pero queremos que ''getNS('catalis:blog:probando_tags') = 'catalis'''. Arreglado con ==== Configuración del template Arctic ==== ===== Tags ===== El uso de tags no necesita limitarse al contexto de blogs. ¿Hay un namespace para tags? Estudiar [[doku>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 ===== Sidebars ===== 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 [[doku>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: * Una página con el menú de sub-sitios disponibles * Redirección automática a ''inmabb.uns.edu.ar/instituto/'' ===== Metadatos de entradas de blog ===== FIXME Los metadatos no aparecen cuando estamos viendo una entrada aislada; sí cuando vemos la lista de entradas. ==== Permalink ==== 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 ====
/* 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 [[doku>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: [[doku>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 = 'Link **bold** text';
php > print $xhtml;
Link **bold** text
php > print preg_replace('/\*\*([^<]+)\*\*/','$1',$xhtml);
Link bold text
php > $xhtml = '- Link **bold** text
- **Another link** not bold text';
php > print preg_replace('/\*\*([^<]+)\*\*/','$1',$xhtml);
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 [[doku>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 =====
* 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 [[doku>devel:css]]).
*
NameVirtualHost *:80
ServerName wikifarm.localhost
ServerAlias *.wikifarm.localhost
DocumentRoot "/home/fernando/www/html/dokufarm/farmer/"
Order allow,deny
Allow from all
Options -Indexes
AllowOverride AuthConfig FileInfo Limit
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 [[doku>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.