I have a D9 website set up already and I want to add another that shares the same code base. (This is on a shared hosting environment)

Below is an example my current php.ini settings for the opcache with 'MyWebSite1.com' as the initial website cache directory path. I want to have the two sites cached in different directories.

How do I specify the path in this php.ini set up for the second 'MyWebSite2.com' website? Or, does this cache directory contain generic php info that can be shared between multiple sites so that only one directory can be specified?

Thank you.

date.timezone = 'America/City'

  • Do you really need to store the cached files on disk? Memory would be much faster. If you have to then the position of .opcache doesn't matter. You should be able to place it in the user home folder. If in doubt ask the hosting provider, this has nothing to do with Drupal.
    – 4uk4
    Jan 27, 2021 at 7:23

2 Answers 2


If I understand your question correctly, I believe you can use ini_set() in your settings.php files if your multisite required different PHP ini configurations.

Example 1a:

// @file docroot/sites/default/settings.php
ini_set('opcache.file_cache', '/path/to/opcache/default');

Example 1b:

// @file docroot/sites/my-other-site/settings.php
ini_set('opcache.file_cache', '/path/to/opcache/my-other-site');
  • Setting up the 1st site initially gave the "PHP OPcode caching Not enabled". My hosting provider instructed adding the php.ini as the way to control opcache - ionos.com/digitalguide/websites/web-development/… It says to put this configured php.ini in the "the main directory of your website". I put it in the top level 'root' of the Drupal directory (where .htaccess, web.config, robots.txt are located) This seemed to work but now I'm wondering if I should have put it in the /sites/myWebSite.com folder, where settings.php is? I'll try this.
    – corE
    Jan 27, 2021 at 2:47
  • Your approach is interesting and, with that approach, I think I would have to take out the directory path in the php.ini that I have above - so that the php.ini initiated the opcache but the path would be specified in settings.php. Something else for me to try. It would be easy if this could be specified in the php.ini somehow. There doesn't seem be be a lot written on this with clarity.
    – corE
    Jan 27, 2021 at 2:49

So the reason I posted under Drupal is because the Drupal installation was throwing an opcache error. These technologies and systems are interconnected so this is in the interest of some Drupal users even though opcache may be a external technology. Drupal doesn't exist in a vacuum, I wish it did because it would probably be easier to manage.

Here is what I found, in case anybody else is having this issue (disclaimer: I'm not an expert on this item... just sharing what I found). I don't know how to put the opcache in memory/database, as suggested (sounds like a good idea) and my host, and Drupal error message, seemed to be wanting a location for this cache, so that's how I proceeded.

Due to some word choices in the directions I found (by host and Drupal), I was under the impression that the cache might be specific for each site (I'm running a multi-site shared code base Drupal install) But the cache seems to be just for any php on the system, so I put the opcache folder under the 'sites' folder in the Drupal directory structure and pointed to it there in my php.ini. So Drupal built a cache folder in there, with a very long number string name. The PHP status information, from the Drupal Status page, will indicate if the opcache is enabled and it's perimeters.

Another problem I had was, when a new cache was built the old ones lingered and ate up a file number limit I had. It seems to be safe to delete these opcache entries and free up space (a lot of space). The caches will rebuild with the current date. So it's safe to play around with this, this is just a cache of PHP code so the server doesn't have to re-run it each time (for efficiency). This (opcache) seems to be new for D8+, I don't recall this issue for prior Drupal versions.

I think it's important to remember that everybody situation is different and there is a reason people reach out for help here. The setup that works for some may not be the case for someone else, and these technologies and networks are getting more and more bloated, complex and tangly. I hope someone may find this useful if they happen to have a similar problem and find themselves here. Thanks for the replies!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.