Closed silsbyc closed 3 months ago
itmaybejj
commented
4 months ago Oh dear.
No; these DB calls are not needed for any recording purposes at all -- they are just there to replace the user ID number with their human readable nice name on the dashboard.
How do you access user information? Will WP_User_Query work? If so, I can replace the join against the user table with a second DB hit to run a WP_User_Query to get a list of nicknames.
silsbyc
commented
4 months ago Yes, WP_User_Query should work.
On Tue, May 21, 2024, 5:24 PM John Jameson @.***> wrote:
Oh dear.
No; these DB calls are not needed for any recording purposes at all -- they are just there to replace the user ID number with their human readable nice name on the dashboard.
How do you access user information? Will WP_User_Query https://developer.wordpress.org/reference/classes/wp_user_query/ work? If so, I can replace the join against the user table with a second DB hit to run a WP_User_Query to get a list of nicknames.
— Reply to this email directly, view it on GitHub https://github.com/itmaybejj/editoria11y-wp/issues/29#issuecomment-2123466420, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4ENY5VRIPH25FIBF7HF4LZDO3P3AVCNFSM6AAAAABICLDE6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRTGQ3DMNBSGA . You are receiving this because you authored the thread.Message ID: @.***>
itmaybejj
commented
4 months ago Oh...missed one, in the CSV export. I'll include that in the next release.
itmaybejj
commented
3 months ago fixed in 1.0.17
I get errors saying the table doesn't exist for the calls in src/controller/class-editoria11y-api-results.php:186 and class-editoria11y-api-dismissals.php:202
It appears that this is related to the definition of $user_meta = $wpdb->prefix . 'usermeta' on src/admin.php:754, src/controller/class-editoria11y-api-dismissals.php: 168, and src/controller/class-editoria11y-api-results.php:121.
Not sure if this is specific to our database, or Wordpress Multisite in general, but our usermeta tables cannot be called directly using SQL with the same structure as a site table. They are a network-wide table as opposed to site-specific tables. If this is just because of our database, you can close this, and I'll just figure out a workaround.
Deleting these specific variable definitions, and the portions of the direct DB calls that used those variables seems to have stopped the errors. I realize this means I won't be able to attribute specific dismissals to specific users. But is there anything else that would be affected by removing these direct DB calls?