Yes. SleekView reads the bridged thread table and the reaction meta directly through whatever schema the active XenForo Bridge version exposes. Older 1.x bridges store reactions in a flat counter column, and newer 2.x bridges use the synced xf_reaction_content rows. Both shapes are handled without extra config on the board side.

They do. The XenForo mobile app reacts to a thread through the XenForo REST API, which writes to xf_reaction_content the same way a desktop browser does. The bridge syncs the new count to WordPress on the next interval, and SleekView Feedback picks it up on the next board render without any extra mobile-specific config.

Yes. The data source picker lets you filter the underlying query by node ID, prefix ID, thread state, or any meta column the bridge syncs. A single feature-requests node, a Planned-only view, or a curated set of high-signal threads can each get its own SleekView board on a separate WordPress page.

Status pill changes update the XenForo thread prefix through the bridge write endpoint, so the chip on the forum index updates as well. Reaction counts, replies, and the original first post stay untouched. Moderators can revert a status by editing the prefix on either side and the next sync reconciles the change.

Soft-deleted and moved threads update on the next bridge sync. Soft-deletes drop the row off the board because SleekView queries only visible threads by default. Moves update the node mapping, so a thread that hops from one node to another shows up under the new category pill on the next render without any manual intervention.

No. SleekView paginates the underlying query, caches the sorted set per page slug, and only fetches the rows it needs for the current page. A board over half a million bridged threads serves in the same time as a board with five hundred because the database does the heavy lifting once and the cache covers every subsequent visitor.

Anonymous voting is off by default because xf_reaction_content expects a user ID. You can enable a SleekView session-based fallback that stores guest votes in its own table and merges them on login, which suits public roadmap pages that receive traffic from non-members reading from search engines or external links.

The board keeps rendering as long as the mirrored tables stay in the database. Deactivating the bridge freezes the data at the last sync, so the board still serves with stale counts until reactivation. A bridge upgrade that changes column names is detected on the next render and SleekView falls back to the new schema automatically.