Database source table can differ from Show Results after One-time import

[pirate-bot]

Summary

A database-source table can show different values on the embedded frontend output than the values shown by the SQL Show Results preview.

Expected behavior: After saving a database-source table, the rendered table displays the same result set shown by the preview for that query, or clearly reflects an intentionally cached snapshot.

Actual behavior: The reported query preview shows current timestamp values from 2026, while the embedded table displays older dates from 2025.

Impact: Users may publish tables that appear to use the configured SQL query but display stale or inconsistent data.

Customer context

• Product / area: Visualizer Tables and Charts Manager, table chart using Database source
• Version: Not provided in the thread
• Environment: WordPress site using a local database source; site health attachment was not inspected
• Integration / third party: Local SQL query against custom sensor tables; no external integration confirmed
• Reported error / symptom: Show Results displays timestamps in 2026, but the embedded table displays dates in 2025
• Impact: Published table output does not match the SQL preview/direct database query result

Reproduction notes

Reported workflow:

1. Create or edit a Visualizer table using Import from database.
2. Enter a SQL query against local custom tables.
3. Click Show Results; the preview shows current timestamp values from 2026.
4. Embed or view the saved table on the frontend.
5. The displayed table shows older dates from 2025 instead of the preview/direct SQL results.

Repository reproduction status: Not runtime-reproduced in this session. Source inspection confirms a reachable cached-content path for DB-source charts that can make the frontend output differ from the current Show Results query preview.

Missing details: plugin versions, selected sync schedule, saved chart meta values, exact table date-format settings, and whether the chart was saved immediately after the preview was generated.

Diagnosis

Conclusion

The report is consistent with a product defect in the database-source rendering flow. The strongest source evidence is that the Show Results AJAX path executes the SQL and returns direct HTML preview output, while the saved chart/frontend path can use serialized chart content and skip re-running the query when the DB schedule meta is non-empty. The “One-time” option stores -1, and ! empty( '-1' ) evaluates as true in the refresh guard, so the frontend filter path can treat a one-time DB chart as cached instead of live. This does not prove the customer’s exact chart meta, but it gives a concrete product-code path that can produce a current preview with stale published rows.

Where this likely occurs

• User-visible surface: Visualizer chart editor, Import from database source, Show Results, Save Schedule, embedded table frontend rendering.
• classes/Visualizer/Render/Layout.php — Visualizer_Render_Layout::_renderData()/database import UI approx. lines 1207–1243: the DB import form posts refresh, and the default schedule option is '-1' => 'One-time'.
• classes/Visualizer/Module/Chart.php — Visualizer_Module_Chart::getQueryData() lines 1529–1553: Show Results parses the submitted query, instantiates Visualizer_Source_Query, fetches with $as_html = true, and returns the direct preview table.
• classes/Visualizer/Source/Query.php — Visualizer_Source_Query::fetch() lines 170–218 and Visualizer_Source_Query::html() lines 258–260: local DB rows are fetched via $wpdb->get_results(), transformed into preview HTML for the admin result grid, or into normalized chart data for saved/rendered chart usage.
• classes/Visualizer/Module/Chart.php — Visualizer_Module_Chart::saveQuery() lines 1586–1629: invalid or absent refresh values become -1; the method stores CF_DB_SCHEDULE = $hours, stores the query/source/series, writes serialized query results into post_content, and adds an entry in the DB schedule option using time() + $hours * HOUR_IN_SECONDS.
• classes/Visualizer/Module/Setup.php — Visualizer_Module_Setup::__construct() lines 42–48 and Visualizer_Module_Setup::refresh_db_for_chart() lines 301–330: the chart refresh filter delegates to refresh_db_for_chart(), but the method returns the existing chart before executing the SQL whenever CF_DB_SCHEDULE is non-empty and refresh is not forced.
• classes/Visualizer/Module.php — Visualizer_Module::get_chart_data() lines 784–816: frontend/chart output reads serialized post_content and then applies the chart-data filter, so a refresh guard bailout leaves cached content available to render.
• Git history: d253049b7 (feat: improve import from WordPress and database UX with stepped flow (#1284)) introduced the current stepped DB schedule UI around the One-time option. The -1 DB schedule storage dates back to older save-query logic (507651341/a92f5dfb8 in blame), while the cache guard around non-empty DB schedule meta was introduced in 1307bfc5a.

Engineering notes

• The customer is using local WordPress database import, not the Pro remote database wrapper based on the provided SQL and transcript.
• Visualizer Pro gates the feature and adds schedule choices, but the inspected local DB preview/save/render flow is in the free Visualizer repository.
• The inspected path explains a stale-data mismatch; the reported date-format symptom could also be affected by DataTables date formatting, but the code-level evidence for a preview/current-query versus frontend/cached-content split is stronger.
• The final table renderer applies column renderers after PHP serializes data into the chart object. js/render-datatables.js — renderSpecificChart() lines 180–226 builds DataTables columns from saved series metadata and rows from saved chart data; addRenderer() lines 270–275 applies Moment formatting for date-like series only when source/display formats are present.
• MySQL/MariaDB TIMESTAMP handling may be another compatibility detail. The local PHP runtime reports MYSQLI_TYPE_TIMESTAMP = 7, while classes/Visualizer/Source/Query.php — Visualizer_Source_Query::get_col_type() lines 228–247 maps type codes 10, 12, and 14 to date but not 7. This was not proven to be the cause of the 2025 display in the customer case.
• Customer screenshots and site links were not opened per evidence-boundary requirements.

Test coverage status

• Relevant PHPUnit coverage was found for the DB preview AJAX endpoint in tests/test-ajax.php — Visualizer_Ajax_Test::test_ajax_response_get_query_data_valid_query() lines 64–90 and related invalid-query/capability tests through approx. line 276. These tests verify request success/error behavior, not parity between preview output and saved frontend table output.
• No relevant PHPUnit coverage was found during inspection for CF_DB_SCHEDULE = -1, refresh_db_for_chart() frontend refresh behavior, or stale cached DB chart content.
• Visualizer Pro has an e2e placeholder for database import in tests/e2e/specs/general/chart-sources.spec.js — import from database lines 168–193, but the Show Results, save, and assertion flow is commented out with a BUG(to investigate) note.

What to verify or explore next

• Reproduce with a table chart using Database source, default One-time schedule, and a query whose result can be changed after saving; compare Show Results with the embedded frontend table after a page reload.
• Inspect the saved chart’s visualizer-db-schedule, visualizer-db-query, visualizer-source, and serialized post_content values before and after saving a DB query.
• Check the same workflow with an explicit scheduled interval on a Business/Developer plan to confirm whether scheduled refresh eventually updates the embedded output.
• Verify date-column behavior separately with raw TIMESTAMP, DATETIME, and calculated ADDTIME(...) expressions to see whether type inference or DataTables formatting contributes to the displayed year mismatch.
• If reproducible in e2e, the commented database-source test in the Pro suite is a useful starting point for coverage.

Unknowns / follow-up

• The customer’s exact Visualizer and Visualizer Pro versions are not in the transcript.
• The selected sync schedule, saved chart metadata, table date-format settings, and whether the chart was re-saved after changing the SQL are not available from the transcript.
• The attached screenshots and site health file were not inspected.

Confidence

Confidence: 82/100

The transcript gives a clear preview-vs-frontend mismatch, and repository inspection found a reachable database-source path where saved DB charts can render cached rows while the preview executes the current SQL.

---

Source: HelpScout #3375318406
Generated by bug-report-triage (ID: bug-report-triage_6a475e0785ccf1.59532717)