Multisite Setup
Super Speedy Chat runs on a WordPress Multisite network, but it is worth understanding exactly how it behaves before you roll it out, because the plugin has no multisite-specific code of its own. It relies entirely on the way WordPress resolves options and database tables per site. In practice that gives you clean per-site isolation for chat data and settings, with a single shared Ultra Ajax file at the network level. This article explains what that means and where the sharp edges are.
Per-site activation or network activation
You can activate Super Speedy Chat either way. There is nothing in the code that requires one model over the other, and no network settings screen is registered, so both the chat settings and the licence live under each individual site’s admin.
On network activation the plugin becomes active on every site in the network. Its activation routine creates the database tables and installs the Ultra Ajax file. Because that routine does not loop over sites, the tables are created immediately only for the site where activation runs. Every other site gets its tables created lazily on its first page load: on each request the plugin compares the stored ssc_db_version option against the current schema version and builds the tables if they are missing. A freshly network-activated subsite has no stored version, so its tables are created the first time anyone loads it. The upshot is that tables always end up present per site, just not all at the same instant.
If you would rather keep chat on only some sites, activate it per site instead. That is the cleaner model when only a handful of sites in the network need live chat.
Chat data and settings are per site (confirmed)
Every chat table is created with the current site’s table prefix, not the network base prefix. That means each site gets its own ssc_conversations, ssc_participants, ssc_messages, ssc_canned_responses and the Discord and WhatsApp thread tables, prefixed for that site (for example wp_2_ssc_messages on site 2). Conversations, participants, messages, canned responses and channel threads never cross between sites.
Settings are stored the same way. The main settings blob (ssc_options), the Customizer appearance options (ssc_customizer) and everything derived from them are ordinary per-site options. So the welcome message, colours, polling intervals, spam controls, LLM configuration, Discord settings and WhatsApp settings are all configured separately on each site. There is no network default and no inheritance: a setting changed on one site has no effect on any other. If you run ten sites you configure the chat widget ten times.
Ultra Ajax is network-wide, enablement is per site
The Ultra Ajax speed layer works differently, and this is the one genuinely network-level piece. On activation the plugin copies a single file, ssc-fast-ajax.php, into the network’s mu-plugins directory. Must-use plugins load on every request across the whole network, so there is exactly one copy of this file and it serves all sites.
That single file is still per-site correct at runtime. By the time must-use plugins load, WordPress has already resolved which site the request belongs to, so when the file reads ssc_options and queries the tables it automatically reads the current site’s option and the current site’s prefixed tables. It also rebuilds the REST route prefix from the site’s own URL each request, so subdirectory networks (where each site sits under its own path) are matched correctly. Enablement is therefore per site: the fast path only engages when that site has ssc_mu_enabled switched on, and it respects that site’s Require Login setting. One site can run Ultra Ajax while another leaves it off, from the one shared file. See the Ultra Ajax Performance Guide for what the speed layer does and how to confirm it is active.
Licensing across the network
The licence key is stored in the standard per-site superspeedy_options option, and the settings menu that manages it is a normal per-site admin menu with no network-admin equivalent. In code terms the licence is not shared across the network. Whether a single purchased licence key may be entered on more than one site in the network is a commercial question about how the key is validated on the licence server, not something the plugin decides locally, so treat licensing as per site: enter and check the key on each site where you want chat active and where you want updates to flow. Update checks are likewise wired up per site. For the activation and update mechanics, see Installing Your License, Activation and Updates.
Per-site and network gotchas
The deactivation and uninstall behaviour is where multisite needs care, because both act on the shared Ultra Ajax file. Deactivating the plugin removes ssc-fast-ajax.php from the network mu-plugins directory. Since that file is shared by every site, deactivating on one site under a per-site model removes the fast path for all sites until the plugin is reactivated somewhere and the file is written back. If you use Ultra Ajax across the network, prefer network activation so the file’s lifecycle is managed once for the whole network rather than by individual sites.
Deactivating Super Speedy Chat on one subsite deletes the shared ssc-fast-ajax.php from network mu-plugins, which turns Ultra Ajax off for every site at once until it is written back. If you run the speed layer network-wide, activate the plugin at network level so a single subsite deactivation cannot pull the file out from under the others.
Uninstalling has a matching limitation. The uninstall routine drops tables using only the current site’s prefix and deletes the shared mu-plugin file. It does not walk every site in the network, so uninstalling from one site leaves the other sites’ ssc_ tables in the database as orphans. If you are removing chat from a whole network, expect to clean up leftover per-site tables yourself.
The uninstaller only drops tables for the site it runs on. To clear chat from a whole network cleanly, remove it site by site (or drop each site’s ssc_ tables manually), then delete the shared mu-plugin file last.
Before any uninstall or migration, take a backup as described in Backing Up and Migrating Chat Data, and remember that each site’s tables must be handled individually.
Summary
Treat Super Speedy Chat on multisite as an ordinary per-site plugin for data, settings and licensing, with one shared network-wide file for the Ultra Ajax speed layer. Configure and licence each site separately, and be deliberate about activation and uninstall so the shared mu-plugin file is not removed out from under sites that still need it.
Comments