Problemas con caracteres especiales luego de actualizar de 3.1.0.1 a 3.3.0.13

¡Saludos, comunidad!

Estoy teniendo el siguiente problema: he actualizado OJS de la versión 3.1.0.1 a la 3.3.0.13. La actualización se efectuó sin problema, pero al finalizar veo que los caracteres especiales (los acentos en español, por ejemplo) no se ven correctamente. Por ejemplo: “Marín González” y “Vásquez Martínez”, en lugar de “Marín González” y “Vásquez Martínez”. No ha habido alteración de dichos textos en la base de datos. Antes y después de la actualización se ven igual, como en los primeros ejemplos de arriba, sin embargo en el frontend en la versión 3.1.0.1 se mostraban correctamente.

He buscado en este foro y he tratado de aplicar lo que he encontrado (collation and settings en config.inc.php), pero sin ningún resultado, ¿alguna idea que pueda ayudarme?

¡Muchas gracias!

Hola @avasquezd
Al subir de la v 3.1 tuviste que pasar por la versión 3.2.x y luego ya la 3.3.x
La versión 3.3.x requiere que la base de datos sea InnoDB y si tu revista está en español con una codificación utf8_general_ci es suficiente.
Seguramente tu codificación era otra, y por eso tienes ese problemas.

En el foro ya hay compañeros que han tenido el mismo problema. Puedes seguir por ejemplo esta
https://forum.pkp.sfu.ca/t/problems-displaying-utf-8-encoded-latin-characters/67387/10

Espero te ayude.

1 Like

Hola, @dagosalas, ¡gracias por tu pronta respuesta!

He hecho la actualización de ambas maneras, directamente de 3.1 a 3.3 (en algún mensaje de este foro he visto a @asmecher decir que no hay problema en hacerlo sin pasos intermedios), y en dos pasos, con 3.2 en el medio, con el mismo resultado. En ambos casos se ha completado la actualización pero los textos que anteriormente se veían bien, ya no. He probado con diferentes codificaciones y modificado la configuración correspondiente en config.inc.php, pero no he logrado nada.

En la versión 3.2.1-4 también se ven correctamente las eñes y las vocales acentuadas.

La solución que aparece en el mensaje que compartes es mediante el uso de ftfy, pero la verdad es que no termino de entender cómo se usa.

Sigo buscando, ¡y gracias otra vez!

Hola, ¿has visto esto?

Hola, @Ppantaleo

No, no había visto este hilo en particular. Probaré por allí.

¿Tuviste que hacer uso de ftfy para resolver el problema?

¡Gracias, Patricio!

Hola, @Ppantaleo

Hice lo ahí indicado, aunque no usando VIM sino Notepad++:

Reemplacé ENGINE=MyISAM por ENGINE=InnoDB
Sólo quedó en MyISAM la base de datos, todas las tablas están en InnoDB, ¿cambiar también la base de datos hará alguna diferencia?, ¿será esa la solución? No puedo cambiarla yo mismo desde el cPanel.
Cambié en todos los casos CHARSET=latin1 por CHARSET=utf8
Me aseguré de que en todas las tablas la “collation” fuese utf8_general_ci

Volví a importar la base de datos, pero el resultado es el mismo, ningún cambio.

En config.inc.php tengo lo siguiente:

; Database collation
collation = utf8_spanish_ci

[i18n]

; Default locale
locale = es_ES

; Client output/input character set
client_charset = utf-8

; Database connection character set
connection_charset = utf8

Así se ven algunos apellidos acentuados en la base de datos, al igual que en el frontend, aunque en las versiones anteriores (3.1 y 3.2) estaban igual en la base de datos pero en el frontend se mostraban correctamente,

algunos apellidos

Entiendo que tú sí lograste resolver el problema, ¿no es así?, ¿cómo lo hiciste?

¡Gracias por tu ayuda!

Hola @avasquezd
Cuando me ha tocado el caso mi solución personal es haciendo CAST de Latin a UTF8

update TABLE_NAME set COLUMN_NAME = convert(cast(convert(COLUMN_NAME using latin1) as binary) using utf8);

Por ejemplo:

update authors set first_name = convert(cast(convert(first_name using latin1) as binary) using utf8);

Estoy convirtiendo en la tabla authors la columna first_name.
Inténtalo en una copia de tu BD, nunca en tu BD de producción y nos cuentas.
Saludos!

1 Like

¡Gracias, @dagosalas, por tu sugerencia!

Probaré, como dices, en una copia de mi BD.

Ya contaré por aquí el resultado.

@dagosalas: tu sugerencia resolvió mi problema, ¡te estoy muy agradecido!

Para otros miembros de la comunidad que se encuentren con este problema: en la versión 3.3.0-13 tuve que aplicarlo en las tablas:

user_settings
author_settings
publication_settings
journal_settings
announcement_settings

(tal vez se me escape alguna, ya me enteraré.)

y en todas, el campo a alterar es “setting_value”

1 Like

Saludos, @dagosalas y @Ppantaleo

Después de mi anterior mensaje encontré otras tablas que tuve que modificar también, Aquí va la lista de todas (hasta nuevo aviso :slight_smile: ):

En cada caso indico la tabla y la columna a la que hay que aplicar los cambios:

Ejemplo:

update user_settings set setting_value = convert(cast(convert(*setting_value* using latin1) as binary) using utf8);

user_settings > setting_value
author_settings > setting_value
publication_settings > setting_value
journal_settings > setting_value
announcement_settings > setting_value
event_log_settings > setting_value
user_group_settings > setting_value
submission_file_settings > setting_value

email_log > from_address
email_log > recipients
email_log > cc_recipients
email_log > bcc_recipients
email_log > subject
email_log > body

notes > title
notes > contents

submission_search_keyword_list > keyword_text
submission_comments > comments

This topic was automatically closed after 2 days. New replies are no longer allowed.