Both. The integration reads the topic custom post type that the free plugin registers and writes through standard WordPress core APIs. Paid Documentor features around theming and access are unaffected by the board and continue to behave normally.

Yes. Any select or radio meta field on the Documentor topic post type can be the grouping axis. Teams that run a richer editorial flow tend to register a workflow_state field with options like Outline, Drafting, Review, and Scheduled and group by that instead.

WordPress core handles the publish through wp_cron. When the scheduled time hits, the topic transitions to publish, fires transition_post_status, and the card moves from the Scheduled column to Published on the next board reload after the transition.

Yes. The plugin writes through wp_update_post, which triggers WordPress object cache invalidation. Documentor reads the sidebar tree from the same cache, so newly published topics appear in the public navigation on the next request after the move.

Yes. The parent book renders as a primary badge using the book label, and sections render as a row of chips beneath the title. Filters in the toolbar narrow the board to a single book or section for a focused review session.

Yes. Contributors with edit_posts move only their own topics, editors with edit_others_posts move every card, and users without edit_posts on the topic post type see a read only board with the drag handles hidden behind a tooltip explanation.

No. Vertical order inside a column writes to a dedicated _sleekview_kanban_order meta key on each topic. Documentor menu_order remains the authoritative source for the public site sidebar tree and the front end topic navigation order.

Cards load lazily per column, so the practical limit is whatever a WP_Query call can return on your server. Boards stay responsive into tens of thousands of topics as long as the grouping field has an index on post_status or on its meta_value column.