Cuando una revista solicita soporte y responde que utiliza “OJS 3”, todavía falta el dato más importante. OJS 3.1, 3.3, 3.4 o 3.5 no son intercambiables: cambian los requisitos de PHP, la estructura interna, la compatibilidad de plugins, los procedimientos de actualización y el tipo de mantenimiento disponible. Incluso dentro de una misma rama, el número de compilación puede incluir correcciones que no estaban presentes unas semanas antes.
Conocer la versión exacta es, por tanto, el primer paso antes de instalar un plugin, cambiar PHP, preparar una migración o evaluar una falla. También sirve para evitar un error frecuente: intentar “actualizar para ver qué pasa” sin haber identificado antes el estado real de la instalación.
Qué significa realmente el número de versión de OJS
Una versión puede aparecer como 3.3.0-19, 3.4.0-10 o con cuatro componentes separados por puntos, según el lugar desde el que se consulte. Lo importante no es memorizar el formato, sino registrar la cadena completa. Decir únicamente “OJS 3.3” elimina información necesaria para comparar requisitos, notas de seguridad y compatibilidad.
Versión del código y versión de la base de datos
OJS mantiene una versión asociada a los archivos instalados y otra al estado de la base de datos. En una instalación sana ambas deberían ser coherentes. Pueden diferir cuando alguien reemplazó los archivos, pero no ejecutó correctamente el proceso de actualización; cuando se restauró una base de datos antigua sobre código nuevo; o cuando un despliegue quedó a medio camino.
Esta distinción explica por qué el panel público o un archivo del servidor no siempre bastan. Para una revisión técnica seria conviene confirmar, al menos, el dato que muestra OJS en Administración y la comprobación desde la línea de comandos.
Método 1: revisar Información del sistema en el panel de OJS
Es el método más sencillo cuando se dispone de una cuenta de administrador del sitio. No basta con ingresar como editor o gestor de una revista: en instalaciones con varias publicaciones, las opciones globales suelen estar reservadas al administrador principal.
- Inicie sesión con una cuenta de administrador del sitio.
- Abra Administración —en versiones antiguas puede aparecer como Administrador del sitio—.
- Entre en Información del sistema.
- Registre el número completo que aparece como versión actual.
Esta pantalla informa la versión reconocida por la base de datos. Es un dato más fiable que una estimación basada en el diseño de la revista, pero no demuestra por sí solo que todos los archivos correspondan a esa misma versión.
Qué anotar además del número
Si la consulta forma parte de una evaluación, conviene guardar también la fecha, la versión de PHP, el motor de base de datos y cualquier mensaje de actualización que muestre el panel. Una captura puede ser útil para documentar el punto de partida, pero no debe publicarse si muestra rutas internas, nombres del servidor u otros datos sensibles.
Método 2: buscar la versión en el código fuente público
Cuando no se tiene acceso administrativo, algunas instalaciones declaran OJS y su versión mediante una etiqueta meta en el HTML. Desde el navegador puede abrirse una página de la revista, elegir Ver código fuente y buscar palabras como generator u Open Journal Systems.
Un resultado típico tiene una forma similar a esta:
<meta name="generator" content="Open Journal Systems 3.x.x-x">
También puede hacerse una consulta preliminar desde una terminal:
curl -s https://revista.ejemplo.org/ | grep -i generator
Por qué este método no es concluyente
La etiqueta puede haber sido retirada por el tema, por una personalización o por una decisión del administrador. Un caché o una copia estática también puede mostrar información antigua. Y aunque el HTML entregue un número, sigue siendo una observación de la capa pública: no confirma que la base de datos haya completado la actualización.
Que la versión no aparezca en el código fuente tampoco prueba que la plataforma no sea OJS. En una revisión externa debe informarse como “versión no expuesta públicamente”, no adivinarse.
Método 3: comprobar los archivos de la instalación
Si se dispone de acceso autorizado al servidor, las distribuciones de OJS incluyen información de versión dentro del código. En muchas instalaciones OJS 3 empaquetadas puede consultarse dbscripts/xml/version.xml y localizar el valor de release.
Esta comprobación responde a la pregunta “¿qué versión de código hay desplegada?”. No responde necesariamente “¿qué actualización reconoce la base de datos?”. Por eso no debe utilizarse de manera aislada después de una migración o de un intento de actualización.
Precaución con copias y directorios antiguos
En servidores que han pasado por varias intervenciones es común encontrar carpetas como ojs-old, respaldos descomprimidos o una versión nueva preparada fuera del directorio activo. Leer el archivo correcto exige identificar primero qué ruta utiliza realmente el servidor web. Revisar una copia abandonada puede producir un diagnóstico completamente equivocado.
Método 4: comparar código y base de datos desde la línea de comandos
Para mantenimiento técnico, la comprobación más útil es ejecutar el modo de consulta de la herramienta de actualización desde la raíz de la instalación:
php tools/upgrade.php check
En las ramas de OJS que incluyen este comando, la salida separa la versión del código y la versión de la base de datos. Debe ejecutarse con el usuario y la versión de PHP adecuados para esa instalación. El objetivo es consultar, no iniciar una actualización.
Cómo interpretar el resultado
- Código y base de datos coinciden: es una buena señal, aunque todavía deben revisarse plugins, requisitos y registros de errores.
- El código es más nuevo: puede haberse reemplazado la aplicación sin completar la actualización de la base.
- La base parece más nueva: puede haberse restaurado código antiguo o estar consultándose el directorio equivocado.
- El comando falla antes de informar: revise la versión de PHP, permisos, dependencias y la ruta desde la que se ejecutó.
Una diferencia entre ambas versiones es motivo para detener cualquier cambio adicional. Antes de corregirla hay que verificar respaldos, archivos, configuración, plugins y el historial de la intervención. Ejecutar el proceso de actualización repetidamente sin restaurar el estado previo suele dificultar la recuperación.
Método 5: consultar la base de datos en una auditoría avanzada
Un administrador con acceso autorizado puede consultar la tabla de versiones. En instalaciones OJS que conservan el esquema habitual, una consulta de solo lectura utilizada para este fin es:
SELECT major, minor, revision, build FROM versions WHERE product = 'ojs2' AND current = 1;
El nombre histórico ojs2 puede resultar extraño en una instalación OJS 3, pero ha permanecido en distintos esquemas por compatibilidad. Como la estructura puede cambiar entre ramas, la consulta debe contrastarse con la documentación de la versión correspondiente y nunca ejecutarse con permisos innecesarios de escritura.
Este método es útil cuando el panel no carga o cuando se necesita corroborar una restauración. No reemplaza la comparación con el código desplegado.
Qué método conviene usar en cada situación
- Visitante o editor sin acceso técnico: revisar el código fuente y tratar el resultado como indicio.
- Administrador del sitio: consultar Información del sistema y registrar la versión completa.
- Responsable del servidor: comparar panel, archivo de versión y
tools/upgrade.php check. - Auditoría después de una falla: añadir la consulta de base de datos, registros del servidor, plugins y respaldos.
En la práctica, la respuesta más sólida no es un número aislado, sino una frase verificable: “el código y la base de datos informan la misma versión, comprobada en tal fecha”.
Ejemplo práctico: una revista que parece estar actualizada
Una revista universitaria informa que utiliza una rama reciente porque el proveedor reemplazó los archivos meses atrás. El sitio público carga y el pie de página no muestra errores. Sin embargo, el panel indica una versión anterior y la comprobación por consola muestra código nuevo con una base de datos más antigua.
El problema no se resuelve continuando inmediatamente con otra actualización. Primero hay que identificar cuándo se sustituyeron los archivos, confirmar si existe un respaldo anterior al intento, revisar config.inc.php, el directorio de archivos, los plugins instalados y los registros de la operación. Solo después puede prepararse una copia de ensayo y repetir el procedimiento de forma controlada.
Este caso aparece con frecuencia porque la página pública puede seguir funcionando durante una actualización incompleta. Los síntomas surgen después: tareas programadas que fallan, plugins incompatibles, errores al guardar formularios o diferencias en el flujo editorial.
Instalaciones con varias revistas
Si varias revistas pertenecen al mismo portal OJS, normalmente comparten el código y el esquema de base de datos de la instalación. No tiene sentido asignar una versión distinta a cada revista solo porque usan temas o configuraciones diferentes. Lo que sí puede variar son los plugins habilitados, el tema, los idiomas y la configuración editorial de cada título.
Errores frecuentes al intentar identificar la versión
Confundir apariencia con versión
Un tema puede hacer que una instalación antigua parezca reciente, y una plantilla conservadora puede ocultar cambios de una rama nueva. Los colores, menús o la disposición del artículo no son una prueba técnica.
Informar solo “OJS 3”
Ese dato no permite evaluar compatibilidad. Para revisar PHP, plugins o una ruta de actualización se necesita el número completo.
Confiar únicamente en la etiqueta generator
Es útil para una revisión externa, pero puede estar ausente, modificada o servida desde caché. Nunca debe prevalecer sobre la comprobación administrativa y de servidor.
Leer un archivo sin confirmar la ruta activa
Los respaldos descomprimidos y despliegues anteriores son habituales. Antes de revisar version.xml, confirme qué directorio atiende el dominio de la revista.
Suponer que código nuevo significa actualización terminada
Reemplazar archivos es solo una parte. Si la actualización de la base no terminó, OJS puede quedar en un estado incoherente.
Exponer información sensible para pedir ayuda
Una captura de Información del sistema o una salida de consola puede revelar rutas, versiones del servidor y detalles de configuración. Comparta únicamente los datos necesarios y oculte credenciales, rutas privadas y direcciones internas.
Buenas prácticas para mantener un inventario técnico de OJS
Identificar la versión una vez no basta. Una revista debería mantener un registro breve y actualizado con:
- versión exacta de OJS;
- coincidencia entre código y base de datos;
- versiones de PHP y del motor de base de datos;
- plugins y temas no incluidos en la distribución principal;
- fecha y resultado del último respaldo probado;
- fecha de la última actualización;
- persona o proveedor responsable del mantenimiento.
Este inventario reduce el tiempo de diagnóstico y evita que un cambio de personal deje a la revista sin información básica. También permite leer correctamente los avisos de PKP: una recomendación dirigida a una rama concreta solo puede evaluarse si se conoce el número instalado.
Para profundizar en los riesgos operativos puede revisarse la guía sobre fallas comunes en revistas gestionadas con OJS. Si la instalación pertenece a una rama anterior, también conviene conocer qué cambia en OJS 3.5 y por qué una actualización debe planificarse.
Preguntas habituales
¿La versión de OJS siempre es visible para cualquier visitante?
No. Algunas instalaciones exponen el dato en el HTML y otras no. La ausencia de la etiqueta pública no impide que el administrador consulte Información del sistema.
¿Un gestor de revista puede ver la versión?
Depende de sus permisos y de la versión instalada. En portales con varias revistas, la información global suele estar reservada al administrador del sitio.
¿Una versión anterior significa que la revista debe actualizar hoy mismo?
No necesariamente. Primero deben revisarse soporte vigente, avisos de seguridad, requisitos del servidor, compatibilidad de plugins, respaldos y una ruta de ensayo. El siguiente artículo de esta serie abordará precisamente cuándo conviene actualizar OJS.
¿Actualizar el tema cambia la versión de OJS?
No. El tema es un componente separado. Puede tener su propia versión y compatibilidad, pero no modifica por sí mismo la versión del núcleo.
¿Todas las revistas de un portal utilizan la misma versión?
Si funcionan dentro de una sola instalación multirrevista, normalmente sí. Pueden verse distintas porque cada título tiene su configuración y tema. Si usan instalaciones independientes, deben revisarse por separado.
Conclusión
La forma correcta de saber qué versión de OJS utiliza una revista depende del acceso disponible. El código fuente sirve como indicio público; Información del sistema confirma el estado reconocido por la base de datos; y la línea de comandos permite comparar esa base con los archivos desplegados. Para una decisión de mantenimiento, esta última comparación es la que evita los diagnósticos más peligrosos.
No actualice OJS basándose solo en su apariencia o en un número incompleto. Registre la versión exacta, confirme que código y base sean coherentes y prepare cualquier intervención sobre una copia de ensayo con respaldos verificables.
Si necesita confirmar el estado de una instalación o preparar una actualización controlada, el servicio técnico OJS de journals.cl puede realizar una revisión inicial del entorno, los plugins y la ruta de actualización.