How WoWonder Actually Handles Multiple Sites

WoWonder is a single-tenant social network script. There is no built-in network mode, no shared user table across sites, and no concept of a parent installation managing child communities the way WordPress Multisite or a SaaS platform would operate. Each WoWonder community is a standalone PHP application tied to one database, one config.php, one set of upload directories, and one purchased license code. If you want to run two or more communities, you run two or more completely independent copies of the software.

This matters because it shapes every decision you make on a hosting account. The script stores its database credentials and site URL directly in /config.php at the document root, and it writes the activated license into the database and the installer during setup. Pointing two domains at the same files while sharing one database does not create two sites; it creates one site answering on two addresses, with shared users, posts, and media. That is almost never what people mean by "multi-site." The practical model on shared hosting is therefore isolation: separate directories, separate databases, and separate domains or subdomains, each with its own license obtained from the CodeCanyon purchase or the WoWonder vendor.

Licensing is the operational constraint people forget. A standard WoWonder Regular License covers a single installed domain. Running a second production community on a second domain requires a second license (or an Extended License, depending on whether the second site is a separate end product). Using one license key across multiple live domains typically fails the periodic license verification the script performs, which can disable the admin panel or throw activation errors after an update. Plan your license count before you provision domains, not after the second install refuses to activate.

Provisioning Isolated Instances with Subdomains and Addon Domains

Decide first how each community should be addressed. The three realistic layouts on a shared account are a subdomain (community2.example.com), an addon or additional domain (example2.com), or a subfolder of the primary domain (example.com/network2/). Subdomains and addon domains are cleaner because WoWonder writes absolute URLs everywhere and expects to own its document root; subfolder installs work but complicate .htaccess rewrite rules and cookie scope.

In cPanel Jupiter, open Domains and click Create a New Domain. Enter the subdomain or new domain, and uncheck "Share document root" so cPanel assigns a dedicated folder such as /home/USER/community2.example.com. In DirectAdmin Evolution, use Account Manager → Domain Setup → Add New for an addon domain, or Subdomain Management for a subdomain; DirectAdmin creates /home/USER/domains/community2.example.com/public_html automatically. Each document root is the key to isolation. Never let a second WoWonder install share a folder with the first.

Create a dedicated database for each instance before running the installer. In cPanel use MySQL Databases: create a database like user_wow2, create a distinct user, assign it with ALL PRIVILEGES, and record the credentials. In DirectAdmin use Account Manager → MySQL Management → Create Database. Keeping databases separate means a corrupted migration, a spam cleanup, or a restore on one community never touches the other. On CloudLinux your account also carries per-user limits (CPU, EP, I/O, memory via LVE), so remember every instance draws from the same pool; two busy communities on one hosting plan compete for the same resources and the same PHP process limit.

Upload the WoWonder archive into the correct document root using File Manager, extract it there, then visit https://community2.example.com/install/ in your browser. Walk through the installer with the dedicated database credentials and the license key assigned to that domain. After installation completes, delete or rename the /install/ directory through File Manager so it cannot be re-run. Repeat the entire sequence per community. There is no shortcut that merges these steps safely.

Per-Instance PHP, .user.ini, and Config Separation

Each document root can run its own PHP version and settings, which is useful when one community is on an older WoWonder release that is sensitive to PHP 8.2 behavior while another runs the latest build. In cPanel open Select PHP Version (MultiPHP Manager also works at the domain level) and set the version for community2.example.com independently. In DirectAdmin, PHP Selector lets you pick the version and toggle extensions per domain. WoWonder needs the usual extensions enabled: mysqli, pdo_mysql, curl, gd, mbstring, zip, and openssl. Enable them per instance rather than assuming inheritance.

Because you lack root and cannot touch php.ini or my.cnf, per-site PHP limits belong in a .user.ini file placed in each document root. A second community that handles large video uploads can carry its own tuning without affecting the first:

; /home/USER/community2.example.com/.user.ini
upload_max_filesize = 128M
post_max_size = 140M
memory_limit = 512M
max_execution_time = 180
max_input_time = 180

Changes to .user.ini apply after the PHP process recycles, usually within a minute or two under LiteSpeed. The matching WoWonder-side limits live in the AdminCP under Admin Panel → Settings → File Upload, where you set the maximum upload size the application itself will accept. Set the AdminCP value at or below your .user.ini ceiling for each site separately.

Keep the config.php files distinct and never copy one into another document root. The $sql_db_name, $sql_db_user, $sql_db_pass, and site URL values must match that specific instance. If you clone a community for staging, edit the copied config.php to point at a new database and update the system URL in the AdminCP under Settings → General Configuration → Website URL, otherwise the clone will write links back to production. When something breaks during these moves, check the per-domain error_log that LiteSpeed drops into each document root; a wrong database host or a missing extension surfaces there immediately, and reading the log for the affected site is faster than guessing.

Staging Clones, Subdomain Testing, and Avoiding License Lockouts

A safe pattern for upgrades is a staging subdomain that mirrors production. Create staging.example.com with its own document root and database, copy the production files with File Manager's archive-and-extract workflow, export the live database in phpMyAdmin, and import it into the staging database. Then edit config.php and the AdminCP Website URL to the staging address. Test the WoWonder update on staging, confirm themes and plugins still load, and only then repeat the update on production. This keeps your live community untouched while you validate a release.

The caution with cloning is licensing again. If your license is domain-locked, a staging subdomain may trip activation checks. Many operators keep staging behind an .htaccess password and treat it as temporary rather than activating a second license for it. Add Basic Auth through cPanel's Directory Privacy or DirectAdmin's Password Protected Directories on the staging document root so search engines and visitors never reach it, and so duplicate-content and duplicate-activation problems stay contained.

If you do serve the same community on both a bare domain and www, that is not a second instance and needs no second license; handle it with a canonical redirect in .htaccess rather than a second install:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

For genuinely separate communities, keep a short inventory: domain, document root path, database name, PHP version, and license key, one row per instance. On a shared plan the hard limits you will hit first are the account-wide database count, inode count, and LVE resource ceilings rather than anything in WoWonder itself. When two communities grow beyond what one hosting plan comfortably serves, moving the busier instance to its own account or plan is the correct next step, since the script gives you no way to throttle one community in favor of another from inside the application.