Hello,
in my log I have these errors messages, about fifty a day.
Do you have an idea I don't know where to look for exactly
thank you
https://i.ibb.co/MnchRRy/screenshot-3.png
https://i.ibb.co/C9GQpVv/screenshot-4.png
Screenshots are a little cloudy, but are you using Gmail as your email relay?
If so, https://www.simplemachines.org/community/index.php?topic=582820
Hello
no for gmail
(https://i.ibb.co/1b21Mnp/screenshot-3.png) (https://ibb.co/LvpmrPq)
(https://i.ibb.co/tXPYdD4/screenshot-4.png) (https://ibb.co/DpgwqQt)
(https://i.ibb.co/2SBwVrS/screenshot-5.png) (https://ibb.co/nBSTdyB)
(https://i.ibb.co/VgjH237/screenshot-6.png) (https://ibb.co/tqmZ837)
thanks
That looks completely different to your opening issue.
your database settings show latin1_swedish_ci and utf8mb4_unicode_ci
neither of which is correct...
Indeed. all tables and columns must have the same collation character set. You must set them to utf-8 and it should solve your issue. Make a backup first of your database, before you convert the collation character to utf-8.
Hello,
thank you i will look into that and how to do it
Quote from: fonfonsd on July 12, 2022, 03:28:58 AMHello,
thank you i will look into that and how to do it
No problem. Let us know how it will go.
Hello, by any chance could you tell me how I should proceed to do this correctly? Already I know that it is necessary to make a backup of my complete database. Then how should I do?
thank you in advance for listening and helping.
Quote from: fonfonsd on July 13, 2022, 05:09:29 AMHello, by any chance could you tell me how I should proceed to do this correctly? Already I know that it is necessary to make a backup of my complete database. Then how should I do?
thank you in advance for listening and helping.
The easiest way would be via your Admin Panel->Maintenance->Forum Maintenance->Databases->Convert HTML-entities to UTF-8 characters. If that will not work, you can always perform the utf-8 conversion via the pma.
Additionally have a look at this link on how to do a proper/thorough utf-8 conversion.
https://wiki.simplemachines.org/smf/UTF-8_Readme
Before the OP asks, that page is for 2.0.x, does it work EXACTLY the same in 2.1.x?
Um, are you sure you mean "Convert entities to UTF-8" there? Firstly that needs the database already in UTF-8, secondly it's only for changing entity form (e.g. &# some letters/numbers and a ; such as ™) into the Unicode equivalent, not doing an actual conversion.
Especially since the upgrade to 2.1 itself should perform the conversion to a UTF-8 database as a mandatory step.
Quote from: Steve on July 13, 2022, 07:59:08 AMBefore the OP asks, that page is for 2.0.x, does it work EXACTLY the same in 2.1.x?
Yes, that should work with 2.1.x as well.
Hello, yes logically my database is in UTF8, I have never made any changes to it.
Since yesterday I have an error message when I want to go to the maintenance of the forum. I have the following message displayed:
Fatal error: Cannot redeclare list_integration_hooks() (previously declared in /htdocs/Sources/Subs-IntegrationHooks.php:36) in /htdocs/Sources/ManageMaintenance.php on line 1843
thanks
Well, it would not work anyway, that way.
Doug is incorrect.
The auto convert to utf8 won't work in your case, because your system is using fifteenth collation in different areas, none of which are actually correct
You are going to have to run a series of myself commands to do the conversion and set all of your collation to the proper utf8 setting... and also possibly run a convert on the contents to change entities.
Once your database contents are correct, we'll try to deal with your file problems
Quote from: fonfonsd on July 14, 2022, 03:10:51 AMHello, yes logically my database is in UTF8, I have never made any changes to it.
Can you try this? First of all make a backup of your database, then go to the Operations tab at the phmyadmin, click it and the option to convert the database tables and columns collation to utf 8 is the very last option, at the bottom. I will attach a screenshot here of it.
That will ensure that all your database tables and columns will be converted to utf-8.
Doug, no... doing that MAY screw up entities...
give me an hour. when I get off Real World meetings, I'll post the conversion SQL
Quote from: Kindred on July 14, 2022, 08:28:35 AMDoug, no... doing that MAY screw up entities...
What entities would those be and how would they be screwed up if I may ask?
According to the OP, the database tables are on utf-8, but looking at the screenshots the columns are on latin1. Doing what I posted it will ensure that everything is on utf-8.
If the database isn't UTF-8, but SMF thinks it is (because it's offering the entity conversion), it stands a pretty good chance of being corrupted.
The entity conversion is for all entities that aren't the specific escaped ones (that correspond to quotes and things like that) where accented letters, symbols, emoji etc are all encoded in entity form which is safe in all collations and character sets that SMF supports because the bottom set of characters is the same across all in any of the ISO-8859-1 set.
But they take up more space, don't play nicely with searching and for non English languages you'll be burning 7-11 bytes per character vs the 2-4 you should be burning if the characters were encoded in actual UTF-8 rather than Unicode-via-HTMK-entity-escaping.
But if the database isn't *actually* UTF-8 you will run into the mojibake problem.
This option is only available if SMF thinks the database is UTF-8, but in this case we know it isn't (because SMF's information is not right here, it's relying on configuration that says it's UTF-8 rather than checking)
Quote from: Arantor on July 14, 2022, 09:37:58 AMIf the database isn't UTF-8
Quote from: fonfonsd on July 14, 2022, 03:10:51 AMHello, yes logically my database is in UTF8, I have never made any changes to it.
Quote from: Arantor on July 14, 2022, 09:37:58 AMBut if the database isn't *actually* UTF-8 you will run into the mojibake problem.
Hence why my recommendation in my previous post.
Anyways, I remember doing the exact same thing for
@Steve a few weeks ago and it did not cause any issues what so ever.
Same thing with this other user here too:
https://www.simplemachines.org/community/index.php?topic=582822.msg4129274
Doug,
From his pictures, we KNOW that, regardless of what the OP SAYS the settings are -- many of those tables are *NOT* collated to utf8_general_ci
fonfonsd... try this
First BACKUP BACKUP BACKUP BACKUP!!!!!
Then, run this:
SELECT table_name, column_name
FROM information_schema.columns
WHERE collation_name LIKE '%latin1%'
Use THIS information to build a list of actions for each table
I did it by hand, creating a list of the following commands
ALTER DATABASE dbname CHARACTER SET utf8 COLLATE utf8_general_ci;
and then each line per table
ALTER TABLE tablename CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE tablename CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
do note that
The CONVERT TO technique assumes that the text was correctly stored in some other charset (eg, latin1), and not mangled (such as UTF-8 bytes crammed into latin1 column without conversion to latin1).
Alternatively, you can try this script that someone suggested
SELECT CONCAT(
'ALTER TABLE ', table_name, ' CHARACTER SET utf8 COLLATE utf8_general_ci; ',
'ALTER TABLE ', table_name, ' CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci; ')
FROM information_schema.TABLES AS T, information_schema.`COLLATION_CHARACTER_SET_APPLICABILITY` AS C
WHERE C.collation_name = T.table_collation
AND T.table_schema = 'your_database_name'
AND
(C.CHARACTER_SET_NAME != 'utf8'
OR
C.COLLATION_NAME not like 'utf8%')
Capture the output of this and run it.
Quote from: Kindred on July 14, 2022, 12:10:19 PMDoug,
From his pictures, we KNOW that, regardless of what the OP SAYS the settings are -- many of those tables are *NOT* collated to utf8_general_ci
The screenshot only showed the columns from the smf_settings table, which were in latin 1. This is the exact same case like
@Steve and the op of the topic I posted the link to in my previous post, had.
Anyways, running all those sql queries is not necessary imo because the pma has a build in option that takes care of all this automatically in one go when used. No need to waste time by converting each table separately.
Not all versions of phpMyAdmin in use on hosts have that option, some will break it on some hosts, and in reality it's just meant to be doing the exact same thing that Kindred's SQL does, but I'd honestly rather trust *that*.
Hello and thank you all, I have to leave for 10 days, I won't have a computer. I note your messages and I take care of them when I get back, and I let you know.
Thanks again for your help.
hello it'ok.
thanks you
Marking solved then.