The drag calls the standard WordPress post update API so the change is persisted to wp_posts and triggers the usual transition_post_status hook chain. SiteOrigin Page Builder rerenders panels on the next page request, caching plugins invalidate, and analytics tied to publishing react exactly as if a designer moved the page through the regular admin screen.

Yes. SleekView accepts a meta filter scoped to entries with the panels_data meta key set and excludes everything else, so the board never gets cluttered with plain Gutenberg or classic editor pages that have nothing to do with the SiteOrigin Page Builder editor.

Yes. Any taxonomy, custom meta field, or the active page template itself can be the grouping axis. Most teams add a custom refresh_status meta key for cohorts like legacy, refreshing, qa, and shipped, and group by that to track active migration projects across the page library.

Scheduled pages appear in their own Scheduled column by default with the queued publish time shown on each card. Moving a scheduled page back to Draft clears the publish timestamp, and moving it forward to Published immediately fires the publish hook so any downstream integrations run right away on the live site.

Yes. Every action on a card uses the same capability checks as the standard WordPress page edit screen, so contributors without publish capability cannot drag cards into the Published column. Any role plugin you already use controls who can drag between which columns on the kanban board view.

The post status changes back to draft through wp_update_post, which triggers the usual unpublish path. The page disappears from frontend rendering on the next request, SiteOrigin Page Builder rerenders panels on the next visit, cached versions are invalidated, and the original publish date is preserved so republishing later keeps the canonical URL.

Yes. The kanban surface uses pointer events so it works with mouse, trackpad, touch, and pen input. Long press on a card initiates the drag on touch devices, and column scrolling works even while a card is mid drag so you can move a page across columns that do not fit on the same viewport.

Each card drag is a single atomic post update so two simultaneous drags resolve in the order the server receives them, with the second drag winning. The board polls for status changes every few seconds so the other designer sees the change land in near real time without refreshing the view manually.