Thom A wrote:
Yep, I amended everything I could. Noticed no loss of characters, so it appears that everything does go through that one line that you highlighted for change.
Excellent. I posted the PR last night:
Prevent Unicode conversion to 8-bit code page in wp-db.php
And I just checked the schema and can't find any columns of the following datatypes:
- DATETIME (all "timestamps" are stored as DATETIME2)
There are only 11 date columns (technically 14, but 3 of them have a duplicate in GMT), and some appear to be non-updatable (e.g. "registered_date").
So that reduces the number of potential issues.
Looking at the schema I found other areas that should be tested, though I am not asking you, Thom, to do that as you have already tested a lot. I'm just listing them here (and will copy to the PR) as notes.
Some dates that might not have been tested:
- Email User signing up / registering (
- User activating their registration (
- WordPress follower registration (
registration_log table, I think)
- Updating a user (
- Creating / Updating a link (
- Updating blog metadata / appearance / layout / etc (
- Creating / updating blogs on a multi-site installation (
Some string columns that might not have been tested:
- Terms (are these Categories? they have a "slug" and a taxonomy that includes a "description") (
- Comments: "author" (
- Links: "name", "description", and "notes" (
- Options? "name" (
- Posts: "name" (different from "title"), "excerpt", "password" (
- Users: "login", "password", "nicename", "display_name" (
- Signups (WordPress users, I think): "title" (their blog title, I think) (
And, yer quite welcome 🙂 .
Take care, Solomon...