Where Tiki Wiki Actually Keeps Its Configuration
Tiki Wiki spreads its runtime configuration across two very different layers, and knowing which layer owns a given setting saves hours of guessing. The first layer is a small PHP file on disk that establishes how Tiki connects to its database. The second layer is the enormous set of preferences stored inside the database itself and edited through the browser. Almost everything you think of as a "setting" — themes, feature toggles, cache behavior, mail parameters, editor choices — lives as a row in the tiki_preferences table, not in a file you can open in File Manager.
The on-disk file is db/local.php, located under your Tiki document root (for example /home/USERNAME/public_html/db/local.php on a primary domain, or inside the addon domain folder if Tiki runs on a subdomain). Open it with the cPanel or DirectAdmin File Manager and you will see plain PHP variable assignments defining the database host, user, password, database name, and a table prefix. On our LiteSpeed and CloudLinux stack the host is almost always localhost, so a broken connection after a migration usually points at a changed database name or a password that was reset in MySQL Databases without updating this file.
<?php
$db_tiki='mysqli';
$dbversion_tiki='28.0';
$host_tiki='localhost';
$user_tiki='USERNAME_tikidb';
$pass_tiki='YourStrongPasswordHere';
$dbs_tiki='USERNAME_tiki';
$client_charset='utf8mb4';
$api_tiki='adodb';
When Tiki throws a blank white page or a generic "unable to connect" message right after you move accounts or restore a backup, this is the first file to verify. cPanel prefixes every database and user with your account username followed by an underscore, and DirectAdmin follows the same pattern, so the values here must match exactly what appears under cPanel → MySQL Databases or DirectAdmin → MySQL Management. If you regenerate a user password there, paste the identical string into $pass_tiki. Keep the file readable only by your account — File Manager permissions of 0644 are appropriate, and never set it world-writable.
Raising PHP Limits With PHP Selector and .user.ini
Tiki is a heavy application. Large wiki pages, the file gallery, batch imports, and the admin preference screens can exhaust default PHP limits and produce truncated pages, failed uploads, or fatal memory errors written to your log. Because you are an unprivileged hosting user, the correct place to change these values is the CloudLinux PHP Selector, not any server-wide file.
In cPanel open Select PHP Version (Jupiter theme), then switch to the Options tab. In DirectAdmin Evolution the equivalent lives under PHP Selector or Select PHP Version. Set the values that match Tiki's needs — a comfortable baseline for a busy wiki is:
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 66M
max_execution_time = 120
max_input_vars = 5000
max_input_time = 120The max_input_vars value matters more for Tiki than for most applications. The global admin panel at tiki-admin.php posts hundreds of fields at once when you save a feature category, and a low limit silently drops fields so settings appear not to save. Raising it to 5000 or higher resolves the classic "my preference reverts every time" complaint.
If a directive is locked in PHP Selector, or you want per-directory overrides, create a .user.ini file in your Tiki root using File Manager. LiteSpeed honors it the same way stock PHP-FPM does, with changes applied after the cache TTL (usually a few minutes):
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 66M
max_execution_time = 120
max_input_vars = 5000Avoid putting php_value lines in .htaccess on this platform — LiteSpeed with suEXEC PHP ignores them and, on some configurations, an unknown directive throws a 500 error. The .user.ini mechanism is the supported path. After editing, confirm the values took effect through Tiki's own report at Admin → System (tiki-admin_system.php) or via a temporary phpinfo() file that you delete immediately afterward.
Cache, Compilation, and Debug Preferences
Tiki caches aggressively through Smarty template compilation and its own page and feature caches. The compiled templates and cache data live under temp/ and temp/cache/ in your Tiki root. When a theme change or an upgraded plugin refuses to appear, the culprit is usually stale compiled output rather than a wrong setting. From the browser you clear these at Admin → System (Admin Home) → Clear caches, or directly at tiki-admin_system.php, where checkboxes let you clear template, preference, and menu caches independently. If the admin UI itself is broken by a bad cache, delete the contents of temp/cache/ and temp/templates_c/ through File Manager — remove the files inside, not the directories themselves, and keep the folder permissions at 0755 so Tiki can rewrite them.
Runtime caching behavior is controlled under Admin → Performance (tiki-admin.php?page=performance). There you enable memory or file-based caching, wiki page caching, and output compression. On shared hosting without a dedicated APCu or Redis instance, keep the cache type set to file-based; do not select a memory cache backend that the server does not provide, since Tiki will fall back with errors logged on every request. If your account has APCu available through PHP Selector's extension list, you can enable it, but verify it appears in the system report first.
Debugging is deliberately quiet on a production Tiki, and that is what you want facing the public. When you must diagnose a fault, avoid displaying errors to visitors. Instead, enable Tiki's own diagnostics under Admin → Feature (or Admin → General) where Smarty debug and PHP error reporting options live, and read the results from your log rather than the page. Set PHP to log rather than display by adding to .user.ini:
display_errors = Off
log_errors = On
error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICETiki also writes to a session or error log inside temp/, and PHP writes an error_log file in the directory where the fault occurred. Use File Manager to open the most recent error_log next to tiki-index.php or inside lib/; the last lines name the file, line number, and function, which tells you whether a problem is a missing PHP extension, a memory ceiling, or a database timeout.
Validating Changes and Recovering Safely
Before touching db/local.php or any preference that affects rendering, take a copy. In File Manager, right-click db/local.php and choose Copy to keep a local.php.bak alongside it, and export the tiki_preferences table through phpMyAdmin so a bad save is reversible. To roll back a single preference without a full restore, open phpMyAdmin, browse tiki_preferences, and edit or delete the offending name/value row — Tiki rebuilds defaults for any preference it cannot find, so deleting a broken row is often the fastest recovery.
If a preference change locks you out of the admin area entirely — a common outcome of enabling an incompatible theme or a strict security feature — you do not need SSH. In phpMyAdmin, run a targeted update against the theme preference to return to a known-good option, for example setting value to thenews or another shipped theme where name='theme'. After any database-level edit, clear the caches from temp/cache/ so Tiki re-reads the corrected values. Finish by confirming the site loads and that tiki-admin_system.php reports no missing extensions or writability warnings, which is the cleanest signal that your configuration and environment are consistent again.
Treat every configuration change as a small, reversible step: adjust one PHP directive or one preference, clear the relevant cache, reload, then check the local error_log. That loop keeps a Tiki install stable on shared hosting where you control the account but not the server.