Hooks, Data, Privacy and Uninstall

This page is for developers and site owners who look after the database. It covers the actions you can hook into, the tables Core Tables creates, its caching, the privacy tools and what happens when you remove the plugin.

Actions

Core Tables fires these actions after the database change is committed. It has no filters.

Action	Arguments	When it fires
core_tables_published	int $id, int $revision	A dataset revision is published
core_tables_unpublished	int $id	A dataset is unpublished
core_tables_trashed	int $id	A dataset is moved to Trash
core_tables_restored	int $id	A dataset is restored from Trash
core_tables_deleted	int $id	A dataset is deleted permanently
core_tables_cache_invalidate	int $id	After any of the above, during the cache purge

core_tables_cache_invalidate is the one to use for CDN or host cache purges:

add_action( 'core_tables_cache_invalidate', function ( int $dataset_id ) {
    // Purge the pages that embed this dataset in your CDN or host cache.
} );

If a hooked function throws, the change still stands. Core Tables logs “Core Tables: a post-commit integration hook failed. Purge page caches manually.”

The Google Sheets worker runs on the cron hook core_tables_refresh_tick, every 5 minutes. The public PHP function core_tables_agent( string $command, array $input = [] ): array is covered in Build Tables with Site Agent.

Caching

Core Tables purges 2 page caches on its own when you publish, unpublish, trash, restore or permanently delete a dataset:

• LiteSpeed Cache, through its purge-all action
• WP Super Cache, by clearing its cache

Both purges clear the whole site cache. Other caches, such as Cloudflare, WP Rocket or your host’s cache, are not purged. Use the core_tables_cache_invalidate action or purge them by hand.

Saving a draft doesn’t purge anything, and neither does saving the Appearance settings. Cached pages keep their old styles until their cache expires or you purge it.

The REST API sends every response with Cache-Control: private, no-store. Table styles are printed inline, so there’s no Core Tables stylesheet to cache. Posts share 1 <style> tag for all their embeds, and an embed outside post content prints its own.

Where Data Lives

Datasets aren’t posts. Core Tables keeps them in its own tables, with your site’s table prefix:

Table	Holds
ctb_datasets	Each dataset’s name, owner, version, draft and published pointers and Trash state
ctb_revisions	Every saved revision, as an unchangeable snapshot
ctb_indexed_revisions	The public columns and row count of each indexed revision
ctb_rows	Public rows for each revision
ctb_cells	Public cell values used for search, sort and filters
ctb_sources	Google Sheets settings and the encrypted key
ctb_jobs	Google Sheets refresh jobs
ctb_commands	Records that stop a retried save from saving twice
ctb_activity	Saves, publishes, unpublishes, cleanups, trash and restore events

Image cells point at ordinary Media Library attachments. Back up every ctb_ table with the rest of the database, and keep the site’s original AUTH_KEY. The license and the Google Sheets key are encrypted with it.

Settings live in these options: ctb_schema_version, ctb_appearance, ctb_ai_settings, ctb_license and ctb_has_sources. Update information is cached in the ctb_update_metadata transient for 3 hours.

Privacy Tools

Core Tables adds to the WordPress Export Personal Data and Erase Personal Data tools under Tools:

• Export: “Core Tables dataset ownership” lists the datasets a person owns, with the name, last update and whether it’s in Trash. It doesn’t search the rows.
• Erase: “Core Tables dataset review” deletes nothing. It reports the data as kept and asks for a manual review, because Core Tables can’t tell which cells describe a person.

To remove personal data from a dataset, edit the rows and publish, then delete older revisions with revision cleanup, or delete the whole dataset permanently from Trash. Media Library files, connected spreadsheets and backups need separate handling.

Core Tables also adds suggested text to the WordPress privacy policy guide, under “Core Tables”.

Deactivate and Uninstall

Deactivating only stops the Google Sheets check. Every dataset, setting, capability and key stays, and the check comes back when you activate the plugin again.

Uninstalling deletes nothing. The ctb_ tables, the options, the *_core_tables capabilities and the encrypted keys all stay in the database. There’s no “delete data on uninstall” setting.

To remove everything, delete datasets from Trash first, then drop the ctb_ tables and options with a database tool after a backup. The plugin doesn’t do this for you.

The Sodium and AUTH_KEY requirements and the rest of setup are in the installation and license guide.