Split website structure?

[kongondo]

  On 6/7/2020 at 11:38 AM, MarkE said:

$config->setPath('templates', $rootPath . '/templates/');

Expand  

I had missed this bit. I am not sure I want to go down this route (unknown side effects, etc). I could probably make getDefaultPath() hookable, then devs can implement on their own.

 

  On 6/7/2020 at 8:55 AM, MarkE said:

There may be a better way of getting the root path without having to do the preg_replace, but I can't see one at the moment.

Expand  

 

$config->paths->site;

I'll have a think.

Edited June 7, 2020 by kongondo

[MarkE]

  On 6/7/2020 at 11:58 AM, kongondo said:

I could probably make getDefaultPath() hookable, then devs can implement on their own.

Expand  

You would need to add $page as a parameter to make it usable in the way I describe.

  On 6/7/2020 at 11:58 AM, kongondo said:

$config->paths->site;

Expand  

That always returns site 2, so no use. It needs to be something that takes $page as its reference point.

[kongondo]

  On 6/7/2020 at 12:05 PM, MarkE said:

That always returns site 2, so no use.

Expand  

Are you saying

$site1 = new ProcessWire('/path/to/www/');
//$site1 = new ProcessWire('/path/to/www/', 'http://domain.com/'); 
$site1SiteFolder = $site1->config->paths->site; 
echo $site1SiteFolder;// returns "root/some/path/site-2/" ???

If that's the case, that's strange or a bug maybe.

[kongondo]

  On 6/7/2020 at 11:22 AM, kongondo said:

Are you using multi-instance this way?

  Quote

While optional, we also recommend providing the URL to the installation as the second argument (preferably including the scheme and hostname). That way if you make any $page->url() or $page->httpUrl() calls, it will know where to point them to:

$site = new ProcessWire('/path/to/www/', 'http://domain.com/'); 

Expand  

i.e., including the domain parameter?

Expand  

Did you see this question I asked previously? I mean the domain parameter. Are you including that?

Edited June 7, 2020 by kongondo

[MarkE]

  On 6/7/2020 at 12:17 PM, kongondo said:

Are you saying

$site1 = new ProcessWire('/path/to/www/');
//$site1 = new ProcessWire('/path/to/www/', 'http://domain.com/'); 
$site1SiteFolder = $site1->config->paths->site; 
echo $site1SiteFolder;// returns "root/some/path/site-2/" ???

Expand  

No. I can't use $site->config->paths->site inside your module, just $config->paths->site. But if I hooked it there would be more flexibility.

 

  On 6/7/2020 at 12:18 PM, kongondo said:

Did you see this question I asked previously? I mean the domain parameter. Are you including that?

Expand  

Sorry, I missed that. I did originally add the domain parameter, but I got an "overloaded" error message, so I removed it.

Here's the code:

$config->admin_site = new ProcessWire($config->paths->root . 'site/');

Using $config means it's available everywhere in site 2 (which is actually called site-web).

[kongondo]

OK. I'll do some tests and get back to you.

[MarkE]

Here's what I have:

	public function getDefaultPath($defaultPath, $page, $mode=1) {
	    bd($page, 'page');
		$config = $this->wire('config');
		if ($mode == 2) {
            $rootUrl = preg_replace('/assets.*/m','',$page->filesUrl());
            $config->setUrl('templates_RM', $rootUrl . 'templates/');
            $config->setUrl('siteModules_RM', $rootUrl . 'modules/');
            $root = $config->urls;
        } else {
            $rootPath = preg_replace('/assets.*/m', '', $page->filesPath());
            $config->setPath('templates_RM', $rootPath . 'templates/');
            $config->setPath('siteModules_RM', $rootPath . 'modules/');
            $root = $config->paths;
        }
		if(2 === (int) $defaultPath) $defaultPath =  $root->siteModules_RM;// /site/modules/
		else $defaultPath =  $root->templates_RM;// /site/templates/
		return $defaultPath;
	}

 

[kongondo]

Hi @MarkE,

I got this to work in a multi-instance environment by making the following change (no hooks needed, no new parameters or options). 

In FieldtypeRuntimeMarkup line #500 (in the method runtimePHPFile()):

Change this:

// render PHP file(s) with different name and/or more than 1
else {
    // $filenames is a csv string: convert to array
    $filenames = explode(',', str_replace(' ', '', $field->renderPHPFile));
    foreach ($filenames as $filename) $out .= $files->render($filename, $vars, $options);
}

 

To this:

// render PHP file(s) with different name and/or more than 1
else {
    $config = $this->wire('config');
    if(2 === (int) $field->defaultPath) $defaultPath =  $config->paths->siteModules;// /site/modules/
    else $defaultPath =  $config->paths->templates;// /site/templates/
    // $filenames is a csv string: convert to array
    $filenames = explode(',', str_replace(' ', '', $field->renderPHPFile));
    foreach ($filenames as $filename) {
        $filename = "{$defaultPath}{$filename}";
        $out .= $files->render($filename, $vars, $options);
    }
}

And bob's your uncle!

This was test my setup.

Site 1 (your App)

• RM installed
• RM used with Render PHP file(s) option
• Rendered file lives in scripts/some-folder/script.php
• Multi-lingual site
• RM renders in pages OK.

Site 2 (your Web/Properties)

• RM module NOT INSTALLED 
• Instances Site 1 like below in some template file
• RM output from Site 1 displayed in Site 2 frontend

// both of these work without errors
// $parentSite = new ProcessWire($pathToParentSite);
$parentSite = new ProcessWire($pathToParentSite,"http://site1domain.tld/");

$content = "<h3>RM Field from Parent</h3>";
  $parentPagesWithRMField = $parentSite->pages->find("parent=1234,sort=created, limit=3");
  foreach($parentPagesWithRMField as $item) {
    $content .= "
      <p>
        <a href='$item->httpUrl'>$item->title</a><br />
        $item->rm_field
        <hr>
      </p>
      ";
  }

Now it is interesting that:

• In the method runtimePHPFile(), $config correctly points to the correct PW instance (if you bd() inside the method and view Site 1 versus Site 2, you'll see the path in both cases point to Site 1)
• In getDefaultPath(), $config always points to the present site (i.e. If you bd($defaultPath) and check in the page with the RM field in Site 1, it points to Site 1. If you check in the frontend of Site 2 [where we instance Site 1], it points to Site 2). Note, getDefaultPath() is in an included class in the module file (FieldtypeRuntimeMarkup.module).

This is the reason why RM was not working correctly. We were passing $files->render(/a/relative/path/). In addition, the defaultPath we were passing in its options came from getDefaultPath() which always points inward. Hence, $files was looking inward (Site 2, in our case). When we prepend $config, we are passing $files an absolute path, hence it works.

Anyway, I hope this works for you. Obviously the CSS and JS won't carry over. You'd need to sort that out. It is easy call them from Site 1 to Site 2 if you need to, so you don't duplicate code.

Edited June 8, 2020 by kongondo

[MarkE]

Many thanks for that @kongondo. 

  On 6/7/2020 at 10:47 PM, kongondo said:

RM module NOT INSTALLED 

Expand  

Any reason for that? I need it on both sites (a really useful module ? ). A quick test seems to indicate that it works OK if installed on one or both sites, but I will investigate more. As you say, my css isn't working properly after this but hopefully I can fix that. I'll spend some time with it and let you know of any issues. Thanks again!

[kongondo]

  On 6/7/2020 at 11:07 PM, MarkE said:

Any reason for that?

Expand  

I didn't need it on Site 2 and also wanted to test if it would work without it in Site 2. However, the multi-instance docs suggest installed modules should mirror each other.

  On 6/7/2020 at 11:07 PM, MarkE said:

my css isn't working properly after this

Expand  

My CSS works properly in Site 1. RM adds CSS using $config->styles() in the inputfield context. In Site 2, there is no inputfield context as we are pulling data from Site 1 using a template file.

[MarkE]

I fixed the css and it all works. I'm getting PHP notice from Tracy:

PHP Notice: Object of class ProcessWire\DefaultPage could not be converted to int in ...\FieldtypeRuntimeMarkup.module:536

That line is $root = $mode == 2... in

	public function getDefaultPath($defaultPath, $mode=1) {
		$config = $this->wire('config');
		$root = $mode == 2 ? $config->urls : $config->paths;
		if(2 === (int) $defaultPath) $defaultPath =  $root->siteModules;// /site/modules/
		else $defaultPath =  $root->templates;// /site/templates/
		return $defaultPath;
	}

Doing a bd(), it would seem that $mode is the host page for the RM field, not an integer! Not causing a problem in my case, since $root = $config->paths is OK, but odd. I wasn't getting this error with the previous version (or my hacked copy).

[kongondo]

  On 6/8/2020 at 8:43 AM, MarkE said:

I fixed the css

Expand  

How, please?

  On 6/8/2020 at 8:43 AM, MarkE said:

I'm getting PHP notice from Tracy:

Expand  

I didn't get this. On which site? 1 (app, instantiated)  or 2 (web, instancer)?

[MarkE]

  On 6/8/2020 at 9:58 AM, kongondo said:

How, please?

Expand  

Sorry, the answer to that is a bit complicated. I am not using the RM module to refer to the css file. It is linked in the PHP script. This detects whether the host site (site 2) is on a permitted list stored in the availability page in site 1 which contains the RM field. There are two such lists - one for non-PW sites and one for PW sites. The script grants the permissions required for it to access the templates/fields it needs and also passes the css as an in-line style. So I just had to make sure that the path was correct for the css (and js) like this:

} elseif (in_array($headers['Host'], $permittedPW)) {
    $currentPath = $files->currentPath();
    $calendarUser = $config->admin_site->users->get("name=calendar");  // calendar has role that only allows access to the availability page
    $config->admin_site->users->setCurrentUser($calendarUser);
    $cssText = file_get_contents($currentPath . 'styles/Availability.less.css');
    if ($cssText) {
        $out .= '<style>' . $cssText . '</style>';
    }
    $js = file_get_contents($currentPath . 'scripts/Availability.js');
    if ($js) {
        $out .= '<script>' . $js . '</script>';
    }
} else {

Maybe a bit hacky - but works ? 

 

  On 6/8/2020 at 9:58 AM, kongondo said:

I didn't get this. On which site? 1 (app, instantiated)  or 2 (web, instancer)?

Expand  

It makes no difference - I get the error from site 1 if the RM module is not in site 2, or from site 2 if it is in both.

[kongondo]

  On 6/8/2020 at 10:28 AM, MarkE said:

Sorry, the answer to that is a bit complicated. I am not using the RM module to refer to the css file.

Expand  

Sorry I put you through writing all these ?. I thought you'd managed to use RM to output your CSS files.

  On 6/8/2020 at 10:28 AM, MarkE said:

It makes no difference - I get the error from site 1 if the RM module is not in site 2, or from site 2 if it is in both.

Expand  

Hmm. I'll have a look. 

[kongondo]

  On 6/8/2020 at 8:43 AM, MarkE said:

PHP Notice: Object of class ProcessWire\DefaultPage could not be converted to int in ...\FieldtypeRuntimeMarkup.module:536

Expand  

I have not been able to reproduce this. I also don't see how Page could be ending up there. I am also not aware of a DefaultPage class. Maybe this has something to do with your particular setup? The only change with the code I posted above was that we are now providing $file with an absolute path instead of a relative one. So, I am a bit confused about this one ?.

[MarkE]

  On 6/8/2020 at 7:28 PM, kongondo said:

I have not been able to reproduce this.

Expand  

That's because it was caused by a bit of rogue code on my part!! Cleaned it up now - sorry for the diversion. I'm actually having some (unrelated?) issues with the RM module at the moment. I'll investigate further and post on the module thread if there is a real problem.

[MarkE]

Hi @kongondo. Back to this issue of last year. Everything had been working fine until yesterday I upgraded PW from 3.0.153 to 3.0.165. Superficially everything seemed to be working, but then it became apparent that the cross-site operation of RM as described above was no longer working - basically the $config was not making it across the sites. In case it helps anyone else, I stopped using $config to hold the admin site instance and used setting() instead (see https://processwire.com/api/ref/functions/setting/). That seems to have fixed it ?