I have a site that is using a 'fake' multi-site instance (I think, someone else implemented it). We created 3 directories in sites:

sites/site1 sites/site2 sites/site3

and in each settings.php inside these directories it includes the original settings.php from the default directory.

I am overriding the theme successfully in these files by doing $config['system.theme']['default'] = 'theme2';

When I try doing $config['system.site']['page']['front'] = '/node/239'; it works only on cache flush.

For example if I am on site 1 I see the front page set in the UI.
Then when I switch to site2.example.test I still see the default front page instead of what is on /node/239.
When I flush the cache, the reverse happens; site 2 homepage shows /node/239 and so does site 1.

I have also tried setting this in an event listener:

public function kernel_request(Event $event) {
    $config = \Drupal::configFactory()->getEditable('system.site');
    $site_path = \Drupal::service('site.path');
    $site_path = explode('/', $site_path);
    $site_name = $site_path[1];

    if ($site_name === 'site2' && $event->getRequest()->getPathInfo() == '/') {
      $config->set('page.front', '/node/239')->save();
    else {
      $config->set('page.front', '/home-content')->save();


This now does the right thing, but only after loading the page and then refreshing.

Could anyone tell me what the "correct" way of doing this would be that wont be cached?

  • Why not provide default config like this for each site? – Kevin Dec 18 '18 at 14:36
  • @Kevin I tried that with my first approach in each settings.php file but that didn't affect the outcome. Just tried that with the second approach and I still need to do a hard refresh before it displays the correct page – Jimmyb_1991 Dec 18 '18 at 14:45
  • Default config as in installable configuration from yaml files, as part of the spin-up installation of new sites. But it sounds like they all use the same database. – Kevin Dec 18 '18 at 14:51

Thanks to everyone for your responses.
I looked in to using the Domain module but am avoiding for 2 reasons:

  • It is still in Alpha14 and this is going to be a business critical site
  • I couldn't work out how to set the domain specific configurations

However, installing the Domain Module and looking at the README file pointed me in the right direction.

For anyone else who is looking to achieve setting a different Front Page per domain:

  • I used the Drupal Console to generate an Event Subscriber for Kernal.request
  • In the getSubscribedEvents method you need to set the weight to something greater than 30 which overrides the Page Cache and Dynamic Cache.

    $events['kernel.request'] = ['kernel_request', '35'];
  • I got the editable configuration for the site settings from

    $config = \Drupal::configFactory()->getEditable('system.site');
  • and the site name added in sites.php by doing:

    $site_path = \Drupal::service('site.path'); 
    $site_path = explode('/', $site_path);
    $site_name = $site_path[1];
  • Then added the logic:

    if ($site_name === 'site2') {
      $config->set('page.front', '/node/239')->save();
    else {
      $config->set('page.front', '/main-content')->save();

The Key thing I was missing was setting the Cache Context for sites.
You need to duplicate the default.services.yml from the sites/default directory and rename it to services.yml (if you don't already have this file).

Then you will need to add url.site to the required_cache_contexts array so that is becomes something similar to:

required_cache_contexts: ['languages:language_interface', 'theme', 'user.permissions', 'url.site']

Remember to flush the cache and this should work!

| improve this answer | |
  • This only works because saving this config is almost like clearing the cache and a big performance hit. But you also apply a render context, so this would be redundant concerning the render cache. And for the route cache you can try to remove only the cache entry for the front page and override page.front in settings.php. – 4k4 Dec 19 '18 at 7:53

a 'fake' multi-site instance

That's technical debt and someone has to swallow the bitter pill now to fix it.

Make it a real multisite and then set the front page per instance as usual.

I once had the same problem and I don't regret it for a second that I finally made it right.

  1. Duplicate the database for every instance
  2. Copy the settings.php file into every instance and adjust them
  3. Copy the config directory for every instance
  4. Copy the default/files directory into each instance.
  5. Fix the sites.php file if necessary

Only thing I needed to pay a little bit more attention in the end were some broken file paths, especially the ones written directly in body texts. But that was it.

| improve this answer | |
  • I would love to do that, but the client wants to only login to a single site and see all content for all sites in one place and they will also need to share the content across the sites. Hence the fake multisite – Jimmyb_1991 Dec 18 '18 at 15:58
  • 1
    How is it fake then? Isn’t this a job for Domain access? – Kevin Dec 18 '18 at 17:19
  • @Kevin – Thought the same, but wouldn't that involve multi-language? – leymannx Dec 18 '18 at 17:24
  • 1
    Not sure, any time I hear multiple sites, single point of author, and content sharing I think domain access. – Kevin Dec 18 '18 at 17:33

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.