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 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.
Hi Juanito, I have the same problem with the same OJS version 2.4.8. I tried that mysql dump because I found it in other forum. But it didn’t work:
mysqldump -u user-p --opt --quote-names --skip-set-charset --default-character-set=latin1 ojs > dump_latin1_26-09-2021.sql
When I tried to import the DB, the error is:
ERROR 1062 (23000) at line 362: Duplicate entry '-aun' for key 'article_search_keyword_list.article_search_keyword_text'
I tried the export as always
mysqldump -u user -p ojs > dump.sql
and the import works fine but the problem with Latin1 persist. It fails during upgrade process with this error message
ERROR: Upgrade failed: DB: Incorrect string value: '\xD9\x86\xD8\xB4\xD8\xA7...' for column 'subject' at row 1
Thanks.
After I read the chain of the subject, I remove all that INSERT entries (article_search_keyword_list, etc.) from de SQL dump and I am trying to import the DB. It seems that is working fine.
Well, it didn’t work.
I export DB with the option:
mysqldump -u user-p --opt --quote-names --skip-set-charset --default-character-set=latin1 ojs > dump_latin1_26-09-2021.sql
I create a new DB with UTF8 charset.
Then I remove the lines that fail when importing from de SQL Dump. The import finished OK. But the tools/upgrade process fails again with the line:
ERROR: Upgrade failed: DB: Incorrect string value: '\xD9\x86\xD8\xB4\xD8\xA7...' for column 'subject' at row 1
¿Any help?
Ok, I resolve it with this post
The difference that I apply was that, instead of dumping with option utf8mb4 it was latin1.
For the DB backup
mysqldump -uusername -ppassword -c -e --default-character-set=latin1 --single-transaction --skip-set-charset --add-drop-database -B dbname > dump.sql
The rest was like the post in the link. It works for the upgrade from 2.4.8-4 to 3.0.2
Thanks,