kongondo

Maybe try these? https://processwire.com/api/ref/sanitizer/page-name-translate/ https://processwire.com/api/ref/sanitizer/page-name-u-t-f8/

Well, depends. Backend (PHP) or frontend (mainly JavaScript)?

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

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

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. 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.

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.

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

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

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.

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. $config->paths->site; I'll have a think.

I thought so, thanks. That means $files (the API that RM uses) is restricting itself to its own file system (for security!) as stated in the docs: However, and I hesitate to mention this for potential security reasons, there is this option: Having said that, I suspect $files will still not go outside its own /site-*/ Are you using multi-instance this way? i.e., including the domain parameter? Thinking out loud, if you had a RM field in site-2(public) whose render PHP file would do a PHP include('/path/to/site-1/scipt.php') of your RM script in site-1(app), that could possibly work but it means your included site-1 script would not be in context. It wouldn't know $site_1->page for instance, unless you pass it to it maybe. Seems hacky though and somewhat defeats the purpose of RM in site-1.

So, currently, this is what is happening: App (site-1 [bookings]) has /site-1/templates/some-rm-script.php Public (site-2 [property]) when instancing site-1, is trying to read 'some-rm-script.php' FROM its own file system, i.e. /site-2/templates/some-rm-script.php Is that it?

Haven't had my coffee yet so not thinking clearly. I thought the original intention was for site 2 (the public site) to pick RM output from site 1 (app/originating site)? I thought site 1 has the RM code. Please clarify.

True, but they need a current subscription to access those boards ?.

Thanks for the explanation. Sorry, I should have been clearer ? I didn't mean that RM field. I meant the test one I requested you to set up. Or, maybe you didn't misunderstand me... ? Hmm. I am sure you have put a lot of thought into this and it does sound like a complex setup but just wondering if it would be better for the Admin App to only provide data and have a RM field in site 2 (public site) consume the data (and render it)? Of course I can't see the whole picture so my thoughts might be off base ? .

Welcome to the forums @Spencer Adding to your list: https://github.com/adrianbj/ProcessMigrator Not sure #2 does assets though.

By the way, I am wondering why you need to use RM in a multi-instance setup. Is you intention to output RM markup from site-1 in site-2? My understanding of multi-instance setups is a way to easily pass data (not markup) between sites. If you can, please also show me the code you are using to invoke RM in the second site. Thanks.

Thanks for the info. It seems that $files is only reading what is locally available to it. i.e. if I invoke $files in site-1 (where RM is) but use site-2 like so, $site1->rm_field, $files will look for the file RM is trying to render from its own file system, i.e. /site-2/templates/ instead of /site-1/templates/. This supposition is sort of supported by this: https://processwire.com/api/ref/wire-file-tools/render/ What we want is probably an absolute path to the file in site-1, maybe using $files->include(). https://processwire.com/api/ref/wire-file-tools/include/ I don't want to bother you further with more tests ? . I'll look into this when I get a moment.

Aha. OK, we are getting somewhere. I am wondering if this has to do with the new silly bug I introduced (new RuntimeMarkupUtilities) but have never gotten round to fixing. Conversely, multi-instance may still have issues with $files variable. Here's another test for you please, if you don't mind. Could you try the following (one at a time) in the test RM instance please? Instead of echoing, call your file like so: $filename = 'something';// // file will be in /site/templates/ return wireRenderFile($filename); return ProcessWire\wireRenderFile($filename); //return $files->render($filename);// @note: this SHOULD NOT work since RM doesn't know 'files' yet return wire('files')->render($filename); Are you using the Master or Dev version of RM? I haven't looked at it in a while so I am not sure what the differences are though ? Hmm. I have no clue about this one.

I am very curious about this. I am curious why both Options and RM are not working. What do they have in common? RM, as you know does not access the database and I wonder whether that is something multi-instance requires? OK. Are you able to do a quick test for me please? Could you try a test RM instance with some simple return 'hello world'; using the paste PHP option please? Thanks.

Hi @Sébastien, Welcome to ProcessWire and the forums. Perhaps not the response you were looking for but I am a bit curious about what you mean by this? What do you mean by all files? Web accessible (public) files will be available to the world, so to speak (e.g. image files in your assets folder). Protected folders/files will not be visible. Could you please clarify and/or give examples? Please clarify this. I don't understand whether you are talking about manual or programmatic access. Similar to my previous comment, please clarify what you mean by confidentiality. From whom? Things like images, css, js, cannot be hidden and the path to those assets are visible to the world. They need to be public. What type of files are you trying to hide? This is interesting. I don't have much knowledge about crawlers and others with a better grasp might chime in. My understanding though is that crawlers treat your entities as belonging to a domain? Please clarify how this access would happen. By another domain, you mean one our you site-* domains? I use multisite option 1 myself, by the way.

Thanks for reporting back. Glad it works ? Hmm. I'm wondering whether its because of some module method that these two fields (RM and Options). Have you been able to debug? Any errors or notices? Edit: In addition, how are you implementing RM's code? i.e. via a file render or code directly in the field config?

I don't think we've ever gotten to grips with this bug. It bites some people every now and then. Excellent! Glad you got it sorted ?

That line wants to execute ProcessPageView. The error means that line 53 returned null: $process = $wire->modules->get('ProcessPageView'); /** @var ProcessPageView $process */ My guess is that files were either not transferred correctly, or fully or were corrupted. FTP can be notorious for converting files on route! (ASCII vs Binary) I'd suggests this: Upload a zip of ProcessWire Unzip the files when they are on the server Install ProcessWire Upload a zip with the file assets Unzip the assets Do the database import Alternatively Install ProcessWire on the server using this script by Soma (you might need to edit it first) Follow steps #3 - 6 above Later, you can sort out your FTP file transfer settings.

You'd be setting yourself up for all sorts of complications. You really don't want to go there. How so? Manually finding files?