[SOLVED] Multi-instance Support in Multi-site Setup

[kongondo]

I am trying out multi-instance support in a multi-site setup (option #1, multiple databases) on a Windows Machine (but using a LAMP stack). I am getting a Fatal error in ProcessWire.php #line 877, Failed opening required  '/F:/vhosts/sandpit.dev/wire/config.php' (include_path='.;C:\php\pear') in F:\vhosts\sandpit.dev\wire\core\ProcessWire.php on line 877

I am using the following API

$path = "F:/vhosts/sandpit.dev/site-mediamanager/";
// OR
// $path = "F:\\vhosts\\sandpit.dev\\site-mediamanager\\";
$url = "http://mediamanager.sandpit.local/";
$site = new ProcessWire($path, $url);

Here is Line #877

require("$rootPath/$wireDir/config.php");

In my code, $path is an absolute path on the windows machine. In the above example, I want ProcessWire to find the /site-mediamanager/config.php, which is a multi-site running off one Wire powered through the main /site/.

As you can see in the error, ProcessWire is adding an extra forward slash to the path, i.e. 

'/F:/vhosts/sandpit.dev/wire/config.php' 

instead of 

'F:/vhosts/sandpit.dev/wire/config.php' 

which obviously fails. I have traced the origin to line #784 in ProcessWire.php

$rootPath = '/' . implode('/', $parts); // remove siteDir from rootPath

The pre-pended / causes the error. Remove that and multi-instance works fine in my environment.

Before I report this as a bug, has anyone ran into this issue? Alternatively, could someone on a Windows machine please test the multi-instance feature for me? Maybe even someone using an absolute path on any machine? Preferably test in a multi-site setup (option #1). If this is a bug, it would be nice if it gets fixed before the imminent master release.

PW version 3.0.85 (but also tested on the latest dev version).

 

Thanks.

[kongondo]

None of you cool kids use Windows ? Or you don't use multi-sites option #1?

[Zeka]

@kongondo I do. I would be able to test it tomorrow if still needed. 

[kongondo]

5 minutes ago, Zeka said:

@kongondo I do. I would be able to test it tomorrow if still needed. 

Yes, still needed. That'd be awesome @Zeka, thanks! 

[matjazp]

I don't use multi-instance support but looking at the code it's a bug for me. The culprit is here: 

$parts = explode('/', $rootPath);

Since windows path doesn't start with a slash, $parts is different on nix and windows. Temporary detour (until Ryan fix it) could be using / as the first character in the path:

$path = "/F:/vhosts/sandpit.dev/site-mediamanager";
// OR
// $path = "\\F:\\vhosts\\sandpit.dev\\site-mediamanager"

I'm not sure what impact would that have later on...

[kongondo]

28 minutes ago, matjazp said:

$path = "/F:/vhosts/sandpit.dev/site-mediamanager";
// OR
// $path = "\\F:\\vhosts\\sandpit.dev\\site-mediamanager"

I'm not sure what impact would that have later on...

Thanks. I'd already tested these and no joy. Still doesn't work. 

[matjazp]

20 hours ago, kongondo said:

I'd already tested these and no joy. Still doesn't work. 

Yeah. As / is prepended to the $rootPath. Maybe you could rename site-mediamanager to sitemediamanager  and also modify .htacces to reflect that change? But this is a hacky approach. Ryan must fix that, shouldn't be a problem (and also the realpath() where path contains ..)

[matjazp]

@kongondoWould this work? Just a workaround, until Ryan fix it...

$rootPath = "F:/vhosts/sandpit.dev";
$sitePath = "site-mediamanager";
$url = "http://mediamanager.sandpit.local/";

$cfg = Processwire::buildConfig($rootPath, $url, array("siteDir" => $sitePath));

$site = new ProcessWire($cfg);

 

[kongondo]

On 04/03/2018 at 4:58 PM, matjazp said:

@kongondoWould this work? Just a workaround, until Ryan fix it...

$rootPath = "F:/vhosts/sandpit.dev";
$sitePath = "site-mediamanager";
$url = "http://mediamanager.sandpit.local/";

$cfg = Processwire::buildConfig($rootPath, $url, array("siteDir" => $sitePath));

$site = new ProcessWire($cfg);

 

Brilliant! That did it! Meanwhile, I submitted an issue report here.

[kongondo]

Ryan committed a fix for this yesterday. I'll make this thread as solved, although a subsequent potential issue was raised.