Support

What you describe points to one thing: bad settings for OPcache.

The problem is that most hosts do not understand how OPcache actually works. OPcache doesn't magically know if a .php file –whether it is included in a PHAR archive, or extracted into a directory such as kicktemp– exists and is the same as what was previously cached. This behaviour is configurable.

The configuration you see suggested for live hosts is not geared towards shared hosting. It is geared towards the CI/CD pipeline use case. In this use case a new virtual machine is created each time new code is being deployed. In this very specific use case you don't want OPcache to waste time determining if the PHP files have changed because, by the very definition of the use case, they never do. When a PHP file changes it's a new deployment. In this use case you want an essentially static OPcache and you only worry about cache warm-up, not cache refresh.

However, we do not and cannot use shared hosting this way. We need to upload PHP files to an application server which is not created afresh or even restarted when we deploy new files. Extracting a backup, updating Joomla / WordPress, installing or updating software for our sites, even using file-based caching and log files for our caching does create and modify PHP files on the host. OPcache will not work properly in this use case unless it's configured to check whether the cached files still exist, and whether they match what OPcache has already cached.

The most pertinent OPcache configuration options are:

• opcache.validate_timestamps This MUST be enabled (set to 1 or true). This is the toggle switch for this OPcache feature I described.
• opcache.revalidate_freq This MUST be set to something fairly low. A value between 2 and 5 allows OPcache to be effective in speeding up the server without causing issues when the PHP file on the server change.

The default settings in PHP are opcache.validate_timestamps=1 and opcache.revalidate_freq=2 which is perfectly fine for both development servers, and for live shared hosting.

You might wonder why you'd get missing files errors if OPcache is misconfigured. It's because OPcache caches two things: the compiled contents of the files (also known as op-code, hence the name “OPcache”), and the metadata of a file (does it exist, when it was created and last modified, what is its size). The latter is controlled by a different setting, opcache.enable_file_override, which is disabled by default.

This means that it's possible and common to misconfigure OPcache in such a way that it "remembers" the compiled contents of files, and file metadata, but is out-of-date with the actual files in your filesystem. The cached executable op-code executes up to the point it needs to include a class file to continue. That file is reported as non-existent even though it's shipped with Kickstart itself, therefore you get an error.

You can temporarily work around that by using a different filename for Kickstart and its kicktemp folder. This creates a new path for loading code files from. However, this will also get out of sync with the filesystem very soon which is why it's a bad workaround.

The correct solution is to work with your host to configure OPcache correctly for the use case of a Joomla or WordPress site:

• opcache.validate_timestamps=1
• opcache.revalidate_freq=2
• opcache.enable_file_override=0

Your host will probably tell you that OPcache can't have anything to do with your problem. That's because they don't know how OPcache actually works. We do. It's our job to know that. Moreover, we have seen every person with a similar problem applying those OPcache settings on their server –and making sure to afterwards restart PHP-FPM or the web server itself, depending on how PHP execution is configured– saw these problems disappear once they followed our instructions to reconfigure OPcache.

As a side note, misconfigured OPcache is worse than just getting in your way of restoring a backup. It also means that any updates you install in your core CMS and its software is not applied. You may have installed a security update as soon as it was available... but your site kept running the old, vulnerable code exposing you and your site to known and otherwise preventable danger. You may have installed updates to the software you run on the site, but the old code with known bugs still runs and you blame the developer for not addressing your issue even though they already have.

A properly configured OPcache can make your site faster. A misconfigured OPcache will render your site broken. Understanding the OPcache inner workings and configuration is, therefore, of paramount importance.

First of all, it makes no sense that just the presence of kicktemp would cause that since it won't do anything by itself. It would only do something in two cases:

1. If you place a file called nophar.txt inside it. In this case you would be bypassing PHAR, having Kickstart extract itself inside a subdirectory of kicktemp.
2. If you start the restoration using the Hybrid or FTP mode, having entered connection details, in which case Kickstart will extract each file there before uploading it to its final destination.

Do you have the nophar.txt file in kicktemp or not?

Further to that, you are telling me that you are using Joomla 3.10 but have no information on the PHP version. Kickstart 9 requires a newer PHP version. I have a feeling that your blank page may be because it runs… but it breaks because your server is using an older PHP version by default. I would recommend using Kickstart 8 for your Joomla! 3.10 site. Please remember that Joomla 3.10 is frozen in time, in August 2021 to be exact. It was never updated to work with newer PHP version, and neither was Akeeba Backup 8 (it would make no sense supporting PHP versions Joomla does not).

So why don't you just go back to Kickstart 8 which is what you should be using for this site to begin with.