|
guiapenin
|
January 24, 2019 at 7:38 am
I have to find attendees in the database table ‘Attendee_meta’ using EE4. I am writing their first and last name using the searcher in page ‘espresso_registrations’.
It works, but the searcher only return any result if I write the first name and last name with exactly their lowercase and uppercase. If I write, for example, “Pablo Gómez”, I won’t have any result unless in the database ‘ATT_fname’ was “Pablo” and ‘ATT_lname’ was “Gómez”. I mean, if in the database I have “pablo” in ‘ATT_fname’ and “gómez” in ‘ATT_lname’, I won’t have any result.
I need to make case insensitive searches by tipping the attendees first name and last name together, can you please tell me if is it posible, or how can I do it?
|
|
Tony
|
January 24, 2019 at 8:15 am
Hi there,
The search should already be case insensitive, for example: https://monosnap.com/file/b4LKFg0x8BwV1sDNgEWRENjJHsxHi6
and – https://monosnap.com/file/5P881tTJZSc7JLuVPYFetHcNnMOTkZ
However it depends on the collation of the tables in your database, mine are utf8mb4_unicode_ci, what are your database tables set as?
|
|
guiapenin
|
January 24, 2019 at 8:37 am
Hi, thanks for reply so fast!
My database tables was set as ‘utf8general_ci’, but i’ve just changed to ‘utf8mb4_unicode_ci’ and it’s still not working.
There you have a capture of the database tables collation:
http://salonescopia.salonesguiapenin.com/wp-content/uploads/2019/01/tabla_codificacion.jpg
Also, it is a capture of the problem:
http://salonescopia.salonesguiapenin.com/wp-content/uploads/2019/01/busquedasEE4.jpg
|
|
Tony
|
January 24, 2019 at 8:52 am
My database tables was set as ‘utf8general_ci’, but i’ve just changed to ‘utf8mb4_unicode_ci’ and it’s still not working.
Why did you change them?
The _ci in both of those stands for case insensitive.
There you have a capture of the database tables collation
That’s not the collation for the DB tables, that’s for the individual columns but either way, both of those should have worked.
What collation does your _posts table use? (not all of the columns within it, the table itself), don’t change what it is currently set to, just post what it is now.
|
|
guiapenin
|
January 24, 2019 at 9:01 am
My _posts table use ‘utf8_bin’
|
|
Tony
|
January 24, 2019 at 9:27 am
What version of WordPress are you running?
|
|
guiapenin
|
January 24, 2019 at 9:28 am
I am using WP 4.9.9
|
|
Tony
|
January 24, 2019 at 9:39 am
You’re currently using WordPress 4.9.9, correct?
In WP 4.2 the tables were updated to use utf8mb4_unicode_ci if your environment supported it, so the first question is why didn’t yours.
It could be your server doesn’t meet the requirements, or you may have specific collations defined within your wp-config.php file and thats the easiest to check, so take a look in yours and check for something like:
define( 'DB_COLLATE', '' );
|
|
guiapenin
|
January 24, 2019 at 9:45 am
I have found define( 'DB_COLLATE', '' ); in wp-config.php
should I define DB_COLLATE as ‘utf8mb4_unicode_ci’ in the php file?
|
|
Tony
|
January 24, 2019 at 9:50 am
No, that’s the default and is fine. It’s when another collation is set that prevents the update.
So, in that case, it could be one of these conditions are not met:
- You’re currently using the utf8 character set.
- Your MySQL server is version 5.5.3 or higher (including all 10.x versions of MariaDB).
- Your MySQL client libraries are version 5.5.3 or higher. If you’re using mysqlnd, 5.0.9 or higher.
https://make.wordpress.org/core/2015/04/02/the-utf8mb4-upgrade/
|
|
guiapenin
|
January 24, 2019 at 9:55 am
I’ve checked that those conditions are met
could it be for another reason?
|
|
Tony
|
January 24, 2019 at 11:18 am
Not that I know of and it’s a WordPress core function so I have no idea why those tables haven’t been converted.
Actually, its possible your server didn’t meet the requirements when 4.2 and 4.3 were released, the update doesn’t happen after that but you can force it:
https://florianbrinkmann.com/en/3457/switch-wordpress-from-utf8-to-utf8mb4-retrospectively/
Note, I highly recommend you backup your database before moving forward, if anything goes wrong with the above you’ll need that backup.
|
|
guiapenin
|
January 25, 2019 at 1:46 am
It has worked, thank you very much!
|
