- This topic has 2 replies, 3 voices, and was last updated 6 days, 1 hour ago by
.
-
Posts
-
Hi,
I’m reporting a bug in the anonymous open/click statistics code. Our site uses a custom WordPress table prefix (not wp_), and two places query the stats table with a hard-coded wp_ prefix instead of the site prefix:
Reports add-on 4.7.8 — newsletter-reports/plugin.php, lines 517 and 522:
SELECT COUNT(DISTINCT(message_id)) FROM wp_newsletter_stats WHERE message_id > 0 AND email_id = %d AND url <> ”
SELECT COUNT(DISTINCT(message_id)) FROM wp_newsletter_stats WHERE message_id > 0 AND email_id = %d AND url = ”
Newsletter core 9.4.6 — newsletter/statistics/statistics-admin.php, lines 197 and 202 (same two queries).Everything else in those functions correctly uses NEWSLETTER_SENT_TABLE / NEWSLETTER_USERS_TABLE; only these four queries use the literal table name.
Effect on a non-wp_ site:
Every time a newsletter’s report is computed for the first time (when stats_time is empty), MySQL returns “Table ‘…wp_newsletter_stats’ doesn’t exist” and WordPress logs two database errors per newsletter. Opening the Reports page once produced 56 error-log lines for us.
$anon_open_count / $anon_click_count silently come back as 0, and those zeros are then written into anon_open_count / anon_click_count in the emails table and cached via stats_time, so even after a fix the cached rows would need recomputing.Fix: use NEWSLETTER_STATS_TABLE (or $wpdb->prefix . ‘newsletter_stats’) in those four queries, as the rest of the file does.
Environment: WordPress 7.1.2, PHP 8.3, Newsletter 9.4.6, Addons Manager 1.4.1, Reports 4.7.8, Automated 4.7.8, Extended Composer Blocks 1.7.3, custom table prefix. The old Reports 4.6.2 did not have these queries, so this appeared with the anonymous-tracking changes (4.7.6+).
Minor, while you’re there: newsletter-blocks/blocks/buttons/block.php (1.7.3) uses the ${var} string-interpolation form in 13 places (lines 19–29, 60, 64, 75), which PHP 8.2+ reports as deprecated on every render of the Buttons block. Switching to {$var} fixes it.
- You must be logged in to reply to this topic.