Texto original en francés:  http://www.uzine.net/article886.html

Volver al Indice de SPIP

En las lecciones  precedente hemos comenzado a elaborar los esqueletos. El éxito de nuestro sitio web corre el riesgo de ser fulgurante.  Pensemos enseguida en las pobre neuronas de nuestro ordenador. En esta lección, nada de divertido, tampoco nada de esencial. Los y las perezosos/as aprovecharan para acurrucarse en el fondo, cerca del radiador. ;-)

Resumen para ellos y para la gente que tiene prisa:  en los ficheros de llamada de tipo  tutoriel.php3, cambiar por  $delais = 3600 ; la cifra de 0.

En el momento en el que una página es solicitada a SPIP este comprueba si, por azar, esta página ha sido ya anteriormente vista. Si la URL solicitada es http://vuestrositio.net/tutoriel.php3?id_article=12, SPIP mira en su sub-repertorio CACHE/ si este fichero existe y, en caso de que no sea así, compara la fecha del fichero caché a los  $delais fijados en le fichero de llamada tutoriel.php3.

En nuestro ejemplo hemos pasado de $delais=0  ;  que produce una renovación sistemática de páginas en cada consulta del sitio a $delais=3600 ; (el cálculo es en segundos).

Nuestra página web solo es renovada si, cuando un/una visitante la solicita, su versión caché data de más de una hora (es decir 3600 s.) De lo contrario SPIP lee simplemente el contenido del fichero caché (1) y reenvía el resultado sin conectarse a la base de datos (salvo para insertar un “hit” en las estadísticas).

¿Como fijar estos  $delais para optimizar la relación reactividad/carga del servidor? No hay soluciones milagrosas pero no dudéis en fijar el plazo de un día  (i.e. $delais=24*3600 ;) o más, para los artículos y las rúbricas. Las páginas de navegación más importantes pueden tener $delais más cortos (veinte minutos o una hora por ejemplo) si vuestro sitio está obligado a reaccionar con la frecuente validación de noticias breves y de sitios sindicados... Si estáis albergados en un servidor compartido con otros sitios, debeis ser respetuosos/as con los demás y no tomar todo el tiempo de cálculo para páginas que raramente cambian: sería especialmente tonto por lo que respecta a los artículos grandes o en los sumarios, ya que el cálculo de páginas puede tomar algunos segundos, lo que ralentiza la consulta de vuestras páginas...
 

¿Como provocar una puesta al día fuera de plazo? Acabamos de decidir $delais extremadamente largos y nos damos cuenta de una falta de ortografía en una página. Corrección en el back-office... ¿Como borrar de inmediato tal villana cicatriz del sitio?

• Después del back-office, clicar en « Ver en línea » inicia la renovación para las páginas correspondiendo a #URL_ARTICLE o #URL_RUBRIQUE del artículo o de la rúbrica correspondiente. Es el caso más frecuente. Pero si no es así...
• En la parte « Salvar/Restaurar» del back-office, un botón « vaciar la caché » borra todos los ficheros cachés (útil si hacéis muchas modificaciones y con un sitio muy complejo, evitar si no es así).
• En todo caso  la solución más sensiclla es la de solicitar a SPIP en la página de inicio el back-office, la “colocación de un cookie”. Este cookie se incrustará en vuestro navegador y SPIP os reconocerá en el momento de enviaros la página en el sitio público: os propondrá entonces, en la zona inferior de la página, un botón “Renovar esta página”.

Retorno al contexto:  Volvemos aquí sobre la noción de contexto. Si  el esqueleto es llamado con un contexto de id_article, de id_rubrique o incluso id_breve, se os propone otro botón cuando SPIP  detecta el cookie : « Modificar este artículo (ou rubrica, o breve) », que conduce directamente a la página correspondiente en el back-office. ¿Gracias a qué?

Últimos detalles:

• por razones evidentes el motor de búsqueda no dispara la cache y las páginas con forum son reactualizadas a partir de que se envía una nueva contribución.
• el repertorio CACHE/ en la ramificación del sitio se divide en 16 sub-repertorios numerados 0, 1, 2... 9, A, B... F, en los cuales los ficheros cachés se distribuyen quasi aleatoriamente; esto se llama  « hasher le cache » y solo por ello ya merece que se le mencione.
• los ficheros cachés son usables (exploités) incluso si la base de datos “cae” lo que garantiza el sitio en caso de averías transitorias del servidor mySQL.

1] Para los/las especialistas, se trata de hecho de un  include PHP del fichero correspondiente, permitiendo ejecutar el código desde la caché...