Table of Contents
Introduction
When an OJS journal moves to a new server, an OJS missing stylesheet problem can appear immediately. The journal still loads, but instead of the normal design, you only see plain HTML, raw text, and basic links.
At first, this can look serious. However, the theme files are usually still available on the server. The real problem is that OJS cannot load or render the active theme correctly in the new environment.
Several issues can cause this behavior. For example, OJS may still use cache files from the previous server. In other cases, some theme files may not have transferred correctly. In addition, configuration paths or database settings may still reference the old environment.
Therefore, the key is not to rebuild the website immediately. Instead, you need to identify where the theme-loading process stopped working.
Problem Overview
After migrating an OJS 3.3.0.7 installation to a new server, the journal may load without any styling. The page can appear as sequential HTML with no navigation bar, colors, spacing, or proper layout.
Moreover, the Website Settings → Appearance section may show no available themes. As a result, the Journal Manager cannot simply select or reactivate a theme from the backend.
In this situation, the PHP error log may reveal two different problems.
The first error is:
Call to a member function getOption() on null
OJS uses compiled Smarty templates to improve performance. Instead of parsing the original template files on every request, OJS stores compiled versions locally.
However, problems appear when the migration includes cache files from the old server.
Those compiled templates may still reference settings, paths, or theme states from the previous environment. Consequently, OJS tries to process information that no longer matches the new server.
The second common error is:
Theme class not found
This error usually has a different cause. In this case, the active theme may not support the installed OJS version.
For example, someone may have installed the theme manually by copying its files directly into:
plugins/themes/
A manual installation can bypass compatibility checks, dependency handling, and version validation that normally happen through the Plugin Gallery.
Therefore, even though the theme files exist on disk, OJS may still fail to load the theme class.
Together, these two problems explain why clearing only the cache may not solve the issue. The cache must be refreshed, but OJS also needs a valid and compatible theme.
Why This Happens
Theme registration is lost. OJS doesn’t only check whether a theme’s files exist in plugins/themes/. It also relies on registration data in the database that links the theme’s plugin path to its active status, version, and configuration for a given journal or site. When the site address or the database credentials change during a migration, that link can break. OJS still sees the folder on disk but no longer recognizes it as a registered, usable theme. Themes placed manually are especially exposed here, because they never went through the registration step that ties the files to the database in the first place.
The compiled template cache is stale. To avoid re-parsing Smarty templates on every request, OJS compiles them once and stores the compiled PHP in cache/t_compile/. That compiled output isn’t a plain copy of the template. It can embed references to the server environment at compile time, including file paths and object states specific to that install. If the cache directory is copied during the migration instead of cleared, OJS tries to run compiled code that still points at the old server. The new server’s paths don’t match, and the mismatch surfaces as runtime errors about null objects or missing properties rather than a clean failure message.
The theme was placed manually. Copying a theme’s files directly into plugins/themes/ can work on the original server if everything happens to line up. It skips the registration, dependency checks, and version validation that the Plugin Gallery performs. After a server move, OJS re-evaluates its plugin registry, and manually placed themes are the ones most likely to be dropped. Their files are present, but the system has no reliable record that they were installed correctly or that they’re compatible with the current OJS version. This is why the theme selector can look empty even when theme files clearly exist on disk.
Troubleshooting Steps
1. Activate a theme from the OJS backend
Start with the simplest solution.
Log in as Journal Manager and open:
Settings → Website → Appearance → Theme
Then select any available theme and save the configuration.
You do not need to choose your final theme yet.
Changing the active theme forces OJS to refresh parts of its theme and template state. Therefore, this step can clear problems caused by cached information from the previous server.
If the journal loads correctly afterward, switch back to your preferred compatible theme.
2. Clear the compiled template cache
If the backend does not work or changing the theme does not solve the problem, clear the cache manually.
Connect to the server through FTP or SSH.
Then empty the contents of:
cache/t_compile/cache/t_cache/cache/t_config/
Do not delete the directories themselves.
Instead, remove only the files inside them.
Before doing this, create a backup in case you need to restore the previous state.
Afterward, reload the journal. OJS should generate new cache and template files that match the current server.
3. Check theme compatibility
Next, confirm that the installed theme supports your OJS version.
Theme architecture can change between OJS releases. Therefore, a theme designed for OJS 3.1 or 3.4 may not work correctly on OJS 3.3.0.x.
For an OJS 3.3 installation, use a theme that supports the 3.3 branch.
If you find an incompatible theme inside plugins/themes/, remove or replace it.
Otherwise, the theme may continue causing confusing runtime errors.
4. Add Themes Through the Plugin Upload
To install a theme manually through the OJS interface, go to:
Settings → Website → Plugins → Installed Plugins
Then click Upload A New Plugin.
Upload the theme plugin package (.tar.gz) through the upload form and proceed with the installation.
After the theme has been successfully installed, return to:
Settings → Website → Appearance
Then select and activate the newly installed theme.
This method allows the theme to be installed directly through the OJS administration interface without manually copying the theme files to the server.
5. Check the active theme in the database
If you still cannot access the backend, inspect the database directly.
Using a tool such as phpMyAdmin, open the:
journal_settings
table.
Then find the setting:
themePluginPath
If the value points to a theme that no longer exists or no longer works, change the value to:
default
This allows OJS to use its built-in theme instead of trying to load an invalid theme.
However, always back up the database before editing it.
After changing the setting, clear the template cache again. Otherwise, OJS may continue using compiled templates from the previous theme configuration.
6. Verify file permissions and site address
Finally, check the server environment.
First, make sure the cache/ directory and its contents are writable by the web server.
Typical permissions may use:
755for directories644for files
However, the correct permissions can depend on your server configuration.
If OJS cannot write to the cache directories, it cannot generate new compiled templates.
Next, verify the site address in the OJS configuration.
The configured URL should match the new domain exactly.
A wrong domain or path can prevent CSS and other assets from loading. As a result, the problem may look like a broken theme even though the theme itself works correctly.
Recommended Troubleshooting Order
For easier troubleshooting, follow these steps in order:
- Activate another theme from the backend.
- Clear the compiled template cache.
- Check theme compatibility.
- Reinstall the theme through Plugin Gallery.
- Check
themePluginPathin the database. - Verify file permissions and the configured site address.
This order starts with the simplest solutions.
Then, if the problem continues, you can move gradually toward database and server-level troubleshooting.
Conclusion
Losing your site’s styling right after a server move is unsettling, but it rarely means anything is permanently broken. The cause is almost always one of a few known issues: a stale template cache still pointing at the old server, a theme that was never properly registered because it was placed manually, or a database setting still referencing a theme plugin that no longer exists. None of them require rebuilding the site.
Work through the fixes in the order they most often help. Activate a theme from the backend to force a cache rebuild. If that alone doesn’t do it, clear the compiled template cache by hand. Confirm the theme is actually built for your OJS version, and reinstall it through the Plugin Gallery if it isn’t. If the backend is completely blocked, correct the themePluginPath setting in the database. Then check file permissions and confirm the site address in your configuration matches the new domain. These six steps cover most of what journal managers run into after a migration, and you can usually get through them without a deep technical background.
Some cases are harder. When several of these problems overlap, when server-level access is limited, or when a journal is mid-migration or mid-upgrade and can’t troubleshoot layer by layer, it helps to have someone handle it. The Open Journal Theme team works on theme issues, server migration, version upgrades, plugin configuration, and server setup. You can reach them at openjournaltheme.com.
References
- PKP Forum: Website is missing Stylesheet
- PKP GitHub #11396: Fatal error after upgrade
- PKP GitHub #9794: Upgrading can leave site inaccessible
- PKP Forum: Theme error after 3.4 upgrade
- OJS Guidebook: Themes
- PKP Forum: Themes not appearing after 3.5
- PKP Forum: getOption() on null error
