Sin que yo realizara ningún cambio en la revista ni en el servidor, el 30-10 comenzó a mostrar caracteres raros en lugar de tildes, ñ “ . Consulte al hosting y la única solución que me dieron fue actualizar la base a una versión del 24 de noviembre. Conecte la revista y continuaba igual.
Exporté la base a la pc, la corregí con el Notepad++ reemplazando los caracteres raros, cree otra base y al importar la corregida el PhpMyadmin me marca un error que adjunto de todos modos la revista ahora se ve bien pero cuando intento subir un nuevo artículo, al darle aceptar, me aparece: una página con “Error: Duplicate entry ‘0’ for key ‘PRIMARY’” , lo mismo me aparece si corrijo algún carácter extraño en el resumen de los artículos al hacer guardar.
Intenté mil soluciones como Copiar la tabla article_search_keyword_list desde la base que funcionaba con caracteres extraños y tb copiar la tabla acces_keys que esta con autoincrementar y nada.
hola Patricio @Ppantaleo , muchas gracias por tu respuesta. Ya pude solucionarlo reparando (no la base completa sino tabla por tabla) con el bloc de notas y leyendo todo el tiempo los logs. Lo extraño es que restaurando la base a un tiempo anterior de normal funcionamiento también aparecia corrupta y obviamente perdíamos los artículos y dois subidos. Por eso preferí reparar la última. Fue casi como reescribir ocho años de edición en 3 dias Por eso ahora, aparte del BK propio del sistema, descargo diariamente a la pc la base y archivos jeje.
Con respecto al consejo de actualizar el ojs ya realizamos pruebas exitosas de migración pero como nuestro OJS está muy tuneado con ayuda de este mismo foro y REDIB (ej: servimos referencias completas por oai, mejoramos las estadísticas y algunos cambios estéticos) esos cambios se pierden. Y, no sé vos, pero cuando uno hace cambios no suele anotar los pasos de prueba error de modo que aplicar esos cambios a la última versión llevaría mucho trabajo y tal como está, para nosotros esta perfecta. Si queres podes verla en Fundación MenteClara.
¿Entonces el problema ya está resuelto? ¿Tenéis claro a que era debido?
Te lo pregunto pq si el problema sigue ahí (error de configuración en el charset de la BD, base de datos corrupta, etc), es probable que dentro de un tiempo volváis a estar en las mismas.
Sobre el cambio de versión, entiendo perfectamente que os cueste desprenderos de una versión en la que habéis trabajado pero hay varios motivos por los que no es una buena idea mantenerse en una versión tan obsoleta.
La versión que usáis tiene más de 10 años y en ese tiempo OJS ha corregido múltiples problemas de seguridad y ha añadido infinidad de mejoras que vuestra revista no incorpora. Además, con versiones tan viejas es imposible seguir dando soporte.
Hola @marc, El problema no está resuelto. Pude limpiar toda la base de datos manualmente y ahora la revista se ve y funciona perfecta nuevamente pero no pude saber que ocasionó el problema de que la base se rompiera. Y la gente del hosting tampoco pudo encontrar a que se debió el error . Como señalas sería importante conocer que pasó para poder prevenirlo. Por ahora aparte del backap diario automático estoy descargando todos los dias la base al ordenador
Lo mas extraño es que se rompió sin que hubiéramos hecho ningún cambio, el último artículo se publico el 27-10 y se rompió el 31-10 a la noche.
Entiendo que te sumes al consejo de actualizarla pero, como dije, sería una tarea monumental y nuestra revista sigue el modelo diamante y además, para evitar conflicto de intereses no aceptamos contribuciones económicas externas que puedan comprometer la independencia editorial con lo cual contamos con fondos limitados para publicar 30 artículos por año. Esperamos, en algún momento, reunir el dinero necesario para alojarla en los servidos de PKP y que sea PKP quien se ocupe de ela migración y la actualización. Como te dije, no tenemos recursos para afrontar esa actualización. La pandemia menguó nuestros fondos. Te mando un abrazo y quedo a tu servicio, Oscar
Adicional a lo que menciona @marc que es sumamente importante, mantener una versión muy vieja del OJS hace que el Mysql y el PHP también tienen que ser versiones viejas y eso en un momento u otro ya no será soportable por el mismo server ni por el proveedor. Aparte de las decenas de vulnerabilidades que se han corregido y a las cuales estas expuesto.
Hace tiempo PKP lanzo una convocatoria precisamente para que las revistas que no tuvieran recursos tanto humanos como técnicos pudieran migrar a la versión más estable, hubo varias instituciones y universidades que se unieron, te lo digo porque yo participe actualizando varios sitios totalmente gratis. Puedes preguntar a Juan Pablo Alperin (@juancomander en twitter) si habrá otra convocatoria y participar.
Hola @dagosalas , que alegría ver tu mensaje, hace años que no intercambiamos.
Y, que buena la posibilidad que me comentas.
Agrego que el problema mayor es que cuando creamos la revista en 2016 la creamos en Español-Argentina y cuando intentamos actualizarla, hace años, no estaba ese idioma, si estaba es_es, de modo que al actualizarla perdíamos toda la metadata de los artículos. Ahora estoy tratando de terminar de limpiar alguna  que quedaron en espacios vacío revisando la metadata de estos ocho años. Cuando termine te molesto nuevamente para ver si actualizamos. Abrazoss y gracias por seguir atento, Oscar
Hola @dagosalas , estuve viendo los intentos anteriores que hicimos y hasta el 3.2 podíamos mantener “es_ar”. Lo que cerramos la prueba porque mientas estábamos probando se crearon nuevos dois y recibimos una factura de crossRef por más de 100 artículos y hacia una página que no era la de la revista Por suerte la gente de CrossRef nos perdono la factura esa.
¿Sabes cómo se puede hacer una prueba en otro servidor, con php7.4, para el 3.2 sin que se guarde en loocks ni crossref?
Me hiciste picar el bichito de la actualización jejejej
Sobre el problema de la desaparición es_AR, te recomiendo que no pierdas esos metadatos, sinó que dupliques la traducción es_ES como es_AR.
Para hacerlo, solo tienes que copiar el directorio es_ES y cambiarle el nombre a es_AR.
Luego busca dentro de las traducciones cualquier referencia a es_ES y también la cambias por es_ER.
Finalmente, solo tienes que añdir ese nuevo lang (es_AR) a tu fichero registry/locales.xml y el idioma te aparecerà entre las opciones disponibles de OJS.
Justo hace poco se ha empezado a hablar de como mantener los metadatos y las traducciones como algo independiente. En realidad, me soprende que no hayamos pensado en esto hasta ahora y que tengamos dos cosas tan distintas vinculadas… pero en todos lados faltan manos.
Hola @marc, muchas gracias por el mensaje.
Hasta el 3.2 es así como decís. Por eso le comentaba a Dago que hace tiempo lo habíamos intentado de esa forma pero no nos convenció la nueva versión.
De todos modos agrego que en lenguaje (como la imagen adjunta) hay que dejar también “es_ES” como idioma primario y tildar en el otro español UI, formularios y envíos, para que los links a las diferentes partes del OJS se muestren traducidas y no ###pliguin….###. Es mucho trabajo cambiar el locale en todos los muchos pligins.
Ahora bien, en el 3.4 se complica porque en “registry” no existe esa posibilidad de agregar el nuevo lenguaje.
@dagosalas ,me convenció de intentarlo nuevamente en otro server con php 7.4 anulando Loock y CrossRef.
Pude instalar bien una versión de OJS 3.2 pero al cambiar la base de datos, creando otra e importando la de la revista actual (2.4.89) devolvía una página en blanco y en los logs error aparecía:
esto lo solucionamos cambiando a mysqli pero ahora nos aparece lo siguiente:
“/Argentina/Buenos_Aires] PHP Fatal error: Uncaught Exception: DB Error: Unknown column ‘context_id’ in ‘on clause’ Query: SELECT v.*
FROM versions v LEFT JOIN plugin_settings ps ON
lower(v.product_class_name) = ps.plugin_name
AND ps.setting_name = ‘enabled’ AND (context_id = ? OR v.sitewide = 1)
WHERE v.current = 1 AND (ps.setting_value = ‘1’ OR v.lazy_load <> 1) in /xxxxxxx/xxxxx/revista/lib/pkp/classes/db/DAO.inc.php:703
Stack trace: #0 /xxxxxxx/xxxx/revista/lib/pkp/classes/db/DAO.inc.php(103): DAO->handleError(Object(ADODB_mysqli), ‘SELECT v.\n\t\t\tF…') #1 /xxxxxxx/xxxxx/revista/lib/pkp/classes/site/VersionDAO.inc.php(231): DAO->retrieve('SELECT v.\n\t\t\tF…’, Array, false) #2 /xxxxxx/revista/lib/pkp/classes/core/PKPApplication.inc.php(352): VersionDAO->getCurrentProducts(Array) #3 /xxxxx/revista/lib/pkp/classes/core/PKPApplication.inc.php(376): PKPApplication->getEnabledProducts(‘core’) #4 /xxxxx/revista/lib/pkp/classes/file/FileWr in /xxxxxx/revista/lib/pkp/classes/db/DAO.inc.php on line 703”
Y no sabemos por dónde comenzar
Querido amigo @dagosalas , insistís en que vale la pena el esfuerzo jejej, abrazos al todo el grupo
Por eso ahora, aparte del BK propio del sistema, descargo diariamente a la pc la base y archivos jeje.