Flex Block 1 (Latest) renders empty in frontend, works in Composer editor

Hi tagDiv team,

I have a Flex Block 1 (configured as “Latest news” widget in the homepage left column)
that renders empty in the frontend but displays posts correctly in the Composer editor preview.

DETAILS:
– Theme: Newspaper v12.7.5 (REGISTERED)
– Demo installed: Newsweek PRO
– Site: https://eurowaypoint.com
– WordPress: 6.9.4
– PHP: 8.2.30

THE PROBLEM:
– In Composer editor: the Flex Block 1 shows the latest 5 published posts correctly
– In frontend (incognito browser, logged out): the block container is generated
(div id=”tdi_96″ class=”td_block_inner td-mc1-wrap”) but completely empty —
no child modules are rendered inside
– 24 published posts exist in the database
– Other blocks on the same homepage (Big Grid Flex 1, other Flex Block 1 instances)
work correctly and display posts
– No JavaScript errors in browser Console
– The block has no special filters configured (Category: All, all filter fields empty)

WHAT I’VE ALREADY TRIED:
– Cleared all caches (SiteGround, WP Super Cache disabled, browser hard reload)
– Restored Homepage from a 3-day-old revision (no improvement)
– Disabled all third-party plugins one by one (Wordfence, SG Optimizer, etc.)
– Verified block configuration in Composer (Filter tab, Layout tab — all default/empty)
– Forced re-save of the block (changed limit number and saved)
– Removed custom CSS that contained :has() selectors

WHAT I NOTICED:
The block was working until I made some modifications today (changed page slug from
/plans/ to /newsletter/, edited some HTML custom blocks for Subscribe links).
The Latest block stopped rendering at some point during these changes.
Restoring an older Homepage revision did NOT fix it.

Could this be a corrupted block state in the database? Is there a way to reset
the block’s internal cache or regenerate its configuration?

Thank you for your help.

UPDATE — April 25, 2026
Significant new findings after deeper DOM inspection. The block is no longer empty, but articles are rendered offscreen.
What changed since my last report:

Yesterday: the block container appeared completely empty — no child modules in the DOM.
Today (verified via browser DevTools): the container #tdi_96 now contains 5 .td_module_flex elements with correct titles, dates, categories, and links pointing to the right posts.
However, the articles are rendered at top: -4729px on the public frontend — far outside the viewport, which is why they remain invisible to users despite being present in the DOM.

Detailed observations from the frontend (incognito, logged out):

Articles ARE in the DOM: confirmed via document.querySelectorAll(‘#tdi_96 .td_module_flex’) returning 5 elements with valid content.
Articles positioned offscreen: getBoundingClientRect() returns top: -4729, left: 20 for the first article. Parent #tdi_96 itself sits at normal page position with height: 234px.
Computed CSS does not explain the offset: position: relative, top: 0px, marginTop: 0px, transform: none, translate: none, inset: 0px — no positioning rule should push the elements offscreen.
No transform on any ancestor: walked up the DOM from .td_module_flex to #tdi_96 — no element has a transform or non-default position.
In tagDiv Composer editor, the block displays correctly — all 5 articles visible with normal layout. The issue manifests only on the public frontend rendering.
Block class on frontend: td_block_inner td-mc1-wrap with el_class=”td-week-slider” set in shortcode.
Image container has display: none (intentional — image_floated=”hidden” in config).
Editor still throws 8x “model does not match content” errors when opening the Homepage in tdc. These persist from yesterday and have not cleared.

Hypothesis:
The block appears to enter a ticker/slider rendering mode on the frontend (consistent with the td-week-slider class), where articles are positioned offscreen waiting for a JS animation that never executes. The editor renders the block correctly because it bypasses this ticker behavior, but the frontend runtime applies it and fails. This may be linked to the persistent “model does not match content” errors.
Concrete questions:

(a) How can I force this block to render as a standard vertical flex list (no ticker behavior) without entering Composer to edit it (since opening the Homepage in tdc shows the model errors)?
(b) Is there a way to clear the model-content mismatch from the database directly (wp_options, wp_postmeta) without going through the editor?
(c) Does the td-week-slider el_class trigger specific JS that could fail silently and leave articles parked offscreen?

I can provide additional diagnostic output from DevTools console if helpful.