Migrating a Smarty PHP Application Between Domains on Shared Hosting: Compiled Templates, Cache, and Paths

Smarty is a template engine rather than a full content management system, so migrating an application built on it means moving raw PHP files, the Smarty library, and its working directories together. The part that surprises people is that a clean file copy almost never produces a clean running site on the new domain. Smarty writes machine-generated PHP into a templates_c directory and serialized output into a cache directory, and both of those bake in absolute filesystem paths that were valid on the old account. When those paths point at a home directory or document root that no longer exists, the application throws fatal errors or silently serves stale markup.

Because this is a shared hosting environment with an unprivileged account, every fix below happens through cPanel Jupiter, DirectAdmin Evolution, File Manager, phpMyAdmin, and the application's own configuration file. There is no shell escalation, no service restart, and no server-wide database editing. The good news is that a Smarty migration rarely needs any of that. Once you understand which directories carry state and which properties carry paths, the process is mechanical.

Why Smarty breaks after a domain or document-root change

A Smarty application typically has four directory concepts defined somewhere in its bootstrap code: the template source directory, the compile directory, the cache directory, and the config directory. In older code these are set with methods like $smarty->setTemplateDir(), $smarty->setCompileDir(), and $smarty->setCacheDir(); in very old projects you will see direct property assignment such as $smarty->template_dir = '/home/olduser/public_html/templates/';. When these are written as absolute paths tied to the previous account, the migrated copy tries to read and write to a home directory that the new account cannot see.

The second failure source is the compiled output itself. Every .tpl file Smarty renders gets converted into a PHP file stored under templates_c with a hashed name. That generated PHP contains hardcoded references to the original template paths and, depending on the Smarty version, absolute include paths. Copying those compiled files to the new account means the engine may load a stale compiled template that points at the old location, producing warnings like Unable to load template or failed to open stream: No such file or directory in your local error_log.

The third source is permissions. On CloudLinux with LiteSpeed, PHP runs as your account user via LSAPI, so the compile and cache directories must be writable by that user. After a File Manager extraction or a restore from backup, ownership is usually correct, but the directory mode can end up too restrictive. If Smarty cannot write to templates_c, it aborts on the first request that needs compilation. Understanding these three mechanics — path properties, stale compiled files, and write permissions — is what turns a broken migration into a ten-minute task.

Moving the files and clearing generated state

Start by packaging the source on the origin account. In cPanel File Manager, select the application root, use Compress to build a .zip or .tar.gz, then download it. On the destination account, upload the archive into the correct document root — /home/newuser/public_html/ for a primary domain, or /home/newuser/public_html/addon-domain/ for an addon or subdomain that DirectAdmin and cPanel map through their own document-root settings. Extract in place using the Extract action.

Before the application ever runs on the new domain, delete the generated state. Navigate into templates_c and remove its entire contents; do the same for the cache directory. Keep the directories themselves — Smarty needs them to exist — but empty them so no stale compiled PHP survives the move. If you prefer to be surgical, you can leave the folders and let Smarty regenerate, but a clean sweep eliminates the most common post-migration errors. The template source files under templates and the config files under configs stay untouched; those are your authored content, not generated artifacts.

If the project ships the Smarty library as a bundled folder (commonly libs/ or a vendor/smarty/ path from Composer), copy it exactly as-is. Do not attempt to swap in a different Smarty version during a migration, because compiled-template signatures differ between major versions and mixing them creates hard-to-trace parse errors. Match the environment instead: use the cPanel MultiPHP Manager or DirectAdmin's PHP version selector to set the same PHP major version the site ran on previously. Smarty 3 tolerates a wide PHP range, but Smarty 4 and 5 expect PHP 7.2+ and 8.x respectively, and a version mismatch surfaces as fatal syntax errors before any template renders.

Correcting Smarty paths, base URLs, and database values

Open the application's bootstrap or configuration file in File Manager's built-in editor. Look for the Smarty directory assignments and rewrite any absolute paths so they resolve relative to the current script location rather than a hardcoded home directory. The portable pattern uses the PHP magic constant __DIR__:

$smarty->setTemplateDir(__DIR__ . '/templates/');
$smarty->setCompileDir(__DIR__ . '/templates_c/');
$smarty->setCacheDir(__DIR__ . '/cache/');
$smarty->setConfigDir(__DIR__ . '/configs/');

Written this way, the paths follow the application wherever it lives, so a future document-root change requires no edits. If the code sets a base URL or canonical domain — often a constant like define('SITE_URL', 'https://old-domain.com'); — update it to the new hostname. Any application that stores absolute URLs in a database (for menus, image references, or cached HTML) needs those rows corrected too. Open phpMyAdmin from the panel, select the database, and run a scoped update against the specific table and column, for example:

UPDATE settings SET value = REPLACE(value, 'old-domain.com', 'new-domain.com') WHERE value LIKE '%old-domain.com%';

Run these replacements column by column rather than blindly across the whole schema, and take a database export first using phpMyAdmin's Export tab so you have a rollback point. If the connection credentials changed during the move, update the database host, name, user, and password in the application config to match the new account's database, which you create under MySQL Databases in cPanel or MySQL Management in DirectAdmin. The host is almost always localhost on shared hosting.

If your application relies on register_argc_argv, a specific memory_limit, or a larger max_execution_time for template compilation, set those per-directory with a .user.ini file in the document root — for example memory_limit = 256M — since you cannot touch the global php.ini. The same principle used for other PHP apps applies here, much like the environment tuning covered in our HumHub configuration guide.

Permissions, .htaccess, and final verification

With paths corrected and state cleared, confirm that Smarty can write. In File Manager, select templates_c and cache, use Change Permissions, and set them to 0755 (or 0775 if the application was authored that way). On LiteSpeed with LSAPI the PHP process is your own user, so 0755 is sufficient and avoids the security risk of world-writable 0777. Verify that the folder owner shown in File Manager matches your account user; if a restore left files owned differently, re-extract the archive rather than trying to chown, which requires privileges you do not have.

If the old site used an .htaccess file with a RewriteBase or absolute rewrite targets tied to the previous path, edit them to match the new document root. A subdirectory install needs RewriteBase /subfolder/, while a primary-domain root uses RewriteBase /. Remove any hardcoded Redirect lines pointing at the old domain unless you deliberately want cross-domain forwarding. Because LiteSpeed reads .htaccess natively, changes apply on the next request with no reload.

Load the new domain in a browser and immediately open Errors in cPanel or check the error_log file that appears in the application directory. A successful migration regenerates fresh files inside templates_c on the first page view — confirm they appear. If you see Unable to write to compile dir, revisit permissions; if you see Unable to load template, the template directory path is still wrong. Clear your browser cache and test a page that reads from the database to confirm the URL replacements took effect. Once the new domain renders correctly and the compile directory is repopulating on its own, the move is complete and stable.