Utf8 collation on upgrading ojs 2.4.8 to 3.1.1.2

I upgraded from ojs 2.4.8 to 3.1.1 but i got a problem my page is in spanish so as you know we have acute accent or diacritical mark. I have already modified the tables and the collation of the bd. Fix the “utf-8” error in connection_charset and in database_charset by changing it to “utf8”. The problem persists because the content of the site, for example, the name of a magazine called “Acción” appears as “Acción” and is not displayed correctly because that word use acute accent, however, if I create a new number right now and put “Acción” it displays correctly and saves well on the bd. The problem is with the content that was already saved in BD and does not display well in the browser Please anybody knows how to solve that problem thanks

Hello @Carlos_Alberto_Rivad .

Perhaps, you can do: WARNING!

1.- Make a backup from your database

2.- Export with magic. Edit ‘nueva’ for your database name.

mysqldump -u root -p --opt --quote-names --skip-set-charset --default-character-set=latin1 nueva > dumplatin1.sql

3.- Import with magic. Edit ‘dumputf8’ for your database name.

mysql -u root -p --default-character-set=utf8 dumputf8 < dumplatin1.sql

Backup First. Warning.

hi juanito you first export the database with latin1 then in the import you put it utf8 whats that change ?

Can you test it? Perhaps it works.

no my friend it didnt work is there any other solution?

If your database name is, for example: OJS

mysql -u root -p
CREATE DATABASE newojs CHARACTER SET utf8;
quit
mysqldump -u root -p --opt --quote-names --skip-set-charset --default-character-set=latin1 OJS > dumplatin1.sql

mysql -u root -p --default-character-set=utf8 newojs < dumplatin1.sql

And you can to edit ‘config.inc.php’
Database settings
database name = newojs

This is for testing. You should create an user for your new db.

It’s a good signal.

Por su nombre creo que habla castellano, lo escribo así, me resulta más fácil. Si no lo habla, le escribo en inglés.

Cuidado, que ha dejado la base.sql accesible por HTTP?

Eso quiere decir, que ahora que los caracteres están bien, hay palabras que se repiten en article_search_keyword_text.

Hágase una copia de seguridad de su base de datos de producción y no la toque.

Una opción puede ser, comando:

nano base.sql

Y vamos a intentar hacer esto, pero a mano:

No ejecutar esto

DELETE FROM article_search_keyword_list;
DELETE FROM article_search_object_keywords;
DELETE FROM article_search_objects;

Es decir, busque en el archivo SQL article_search_keyword_list
después del CREATE TABLE, verá un INSERT enorme, con CTRL+k puede borrar esa línea.

Busque article_search_object_keywords
después del CREATE TABLE, verá un INSERT enorme, con CTRL+k puede borrar esa línea.

Busque article_search_objects
después del CREATE TABLE, verá un INSERT enorme, con CTRL+k puede borrar esa línea.

Ctrl + x Guardar, sí.

y entonces ahora

mysql -u root -p --default-character-set=utf8 newojs < base.sql

Hágase una copia de seguridad de su base de datos de producción, cuidado.

Si cuando termine todas las pruebas, todo va bien. Puede reconstruir esas tablas con

php tools/rebuildSearchIndex.php

Primero, hazte una copia de base.sql

cp base.sql baseBACKUP.sql

por lo que pueda pasar. Creo que WinSCP es muy posible que sea el que te rompa la codificación. Use linux o ssh y nano o vim o cualquier editor.

Sólo tiene que borrar los INSERT INTO pero ahí estoy viendo un carácter roto en “serán”, mire de abrirlo con el editor nano y busque con CTRL + w si los caracteres no están rotos.

haga también en ssh un

file base.sql

a ver que codificación le devuelve, pero si ha guardado con winscp es posible que le haya roto la codificación.

Hola @Carlos_Alberto_Rivad .

Ya ve bien los caracteres?

Pues ahora de prueba, le puede poner a config.inc.php la base de datos newojs.

A ver si hay suerte.

Para reconstruir sí, en la raíz de donde tengas instalado tu ojs. Ejecute en SSH, con php-cli

php tools/rebuildSearchIndex.php

Puedes volver a tu antigua base de datos o algún backup y revisar el procedimiento bien.

En SSH

mysql -u root -p newojs

show tables;

Pero ya sabes como se corrigen los caracteres. Quizás no borró bien los INSERT de las tablas.

@juanito
Juanito a que te refieres con corregir los caracteres? cuando borre los insert de esas 3 tablas que me mencionaste quedaron estas clausulas

LOCK TABLES article_search_keyword_list WRITE;
/*!40000 ALTER TABLE article_search_keyword_list DISABLE KEYS */;

/*!40000 ALTER TABLE article_search_keyword_list ENABLE KEYS */;
UNLOCK TABLES;

no comprendo a que tabla articles hace referencia si no se borro nada de eso ?

Sí, está bien.

En OJS 3 no existe tabla articles, así que puede que esté ejecutando un OJS 2 y no un OJS 3. Ya sabe el procedimiento para corregir los caracteres áéíóúñ, que están rotos. Dele un repaso a ver que pasa por ahí.

Gracias.

@juanito

Juanito disculpa que te moleste tengo una duda mira la base de datos con los pasos que me diste asoman las tablas con sus acentos eso no significa que ya arranca desde la pagina de la revista sacame de dudas al momento que elimine los inserts de esas 3 tablas obviamente ya me permitio importar ahora mi duda cual es el procedimiento siguiente debo ejecutar el comando que me diste tools/rebuildSearchIndex.php o debo ya de editar el archivo config.inc.php y proceder a ejecutar el upgrade con el comando php tools/upgrade.php upgrade desde la instalacion de ojs 3.1.1.2 porque a esa version me estoy migrando solo que ahora me sale ese error que te mostre anteriormente y no se si es por haber borrado esos inserts que debo hacer

El borrar esos INSERTs no son la causa.

La base de datos sobre la que ha aplicado la corrección de caracteres, es OJS 2 u OJS 3?

asi es juanito la base de datos origen a la que aplique la correccion es una base de datos de la version ojs 2.4.8.3 para hacerte exacto porque como te dije estoy migrando de ojs 2 a ojs 3.1.1.2

Pues entonces ahora debe leer como hacer upgrade

Si busca por el foro hay muchos hilos que explican como se hace.

base de datos de OJS 2. carpeta/directorio de ficheros (files_dir) de OJS 2. carpeta/directorio public de OJS 2.

COPIA DE SEGURIDAD DE TODO, y ponerlo en un sitio y no tocarlo, para poder volver atrás.

Se baja OJS 3.2.0-3 y siga las instrucciones.

installed = Off
files_dir = …
Database settings = newojs…

cp …/ficheros ojs32
cp …/public ojs32

php tools/upgrade.php check
php tools/upgrade.php upgrade

Lea la documentación, lo he puesto de memoria (pseudodocumentación)

Haga copia de seguridad de todo, porque le puede fallar el upgrade y debe montar de nuevo todo el entorno, no se puede intentar por segunda vez, si una vez falla.

Por los INSERT borrados no se obsesione más, OJS puede funcionar sin ellos, sólo se usan para el buscador, y puede reconstruir esas tablas en cualquier momento cuando ya lo tenga migrado a OJS 3.2, como ya le dije.

Si se encuentra más problemas, abra otros hilos, ya que el tema de este se resolvió.

Gracias.