Creating a “wire” to a site B from within site A

[DrQuincy]

If I had sites A and B is there a way in site A to create an instance of ProcessWire\wire() that is connected to a completely different site? The reason I ask is to sync some data between two different sites on the same server on the fly.

E.g. on site A:

$page1 = wire('pages')->get(/foo-bar/);

$page1->of(false);

$page2 = new \ProecssWire2\Page;

$page2->template = $page1->title;
$page2->title = $page1->title;
// and so on
$page2->save(); // Saves to site B

 

[Robin S]

If your two sites are on the same server then this blog post explains how to do it: https://processwire.com/blog/posts/multi-instance-pw3/

[DrQuincy]

Oh wow, thanks. That looks (as everything tends to be with PW) so simple!

[JayGee]

On 8/21/2023 at 11:06 AM, DrQuincy said:

If I had sites A and B is there a way in site A to create an instance of ProcessWire\wire() that is connected to a completely different site? The reason I ask is to sync some data between two different sites on the same server on the fly.

E.g. on site A:

$page1 = wire('pages')->get(/foo-bar/);

$page1->of(false);

$page2 = new \ProecssWire2\Page;

$page2->template = $page1->title;
$page2->title = $page1->title;
// and so on
$page2->save(); // Saves to site B

 

Purely out of curiosity can I ask the nature of your project you need this for? We’ve done a few app projects where we’ve considered separation of concerns over multiple PW instances but have never ultimately thought it would be beneficial versus just running 1 site. 

[MarkE]

47 minutes ago, JayGee said:

Purely out of curiosity can I ask the nature of your project you need this for? We’ve done a few app projects where we’ve considered separation of concerns over multiple PW instances but have never ultimately thought it would be beneficial versus just running 1 site. 

I have also done an multi-instance app. The context is a holiday cottage booking system where the admin system is one site and the public website is separate. The connection is for the availability and prices. There can be more than one public website, for multiple properties. That way, the (fairly simple) public site does not get entangled in the rather more complex admin app. If there was a simple way of segregating different categories of templates, fields and pages in the back-end then maybe it would not be necessary (I.e. different “views” of the database), but even so I think a physical separation is best. 

[DrQuincy]

The client basically has two sites. One is in the UK and the other in the EU but serves customers internationally. There is a lot of shared information on both sites but at the same time they are different enough to warrant individual sites. But the client didn't want to, for example, add (and keep up-to-date) the same product twice.

What I have set up is a root site that doesn't have a front-end but stores all the shared data. Then there is a folder for each site within that, each a separate PW instance.

/root/
/root/uk/
/root/eu/

My question above was really to see if I could copy info between the sites within the same script. While Robin S's link was useful, it would appear to be for read-only so I didn't end up using it.

Instead, the root site has hooks that saves all data into JSON files and associated assets and the EK and EU then take the and convert it to PW pages.

If you're wondering why the EU and UK sites are within the root site folder as opposed to being siblings, it's because they share the same templates, models, JS, SCSS, etc.
 

[JayGee]

Cool - interesting insight thanks just to see what others are doing.

 

11 hours ago, DrQuincy said:

My question above was really to see if I could copy info between the sites within the same script. While Robin S's link was useful, it would appear to be for read-only so I didn't end up using it.

You could also try the bootstrapping method which I think would allow you write between sites too through the regular PW API.

https://processwire.com/docs/front-end/include/

[DrQuincy]

I believe bootstrapping for when your other script is not already a PW instance, including command line (I have used that on a project before, by the way, and it's very useful and easy).

With the multi-instance option, due to the PHP namespace, you can only write to the main instance. You can read from as many others as you want but you can never save anything as when you run new \ProcessWire\Page you are always creating a page in main instance's namespace. In my case, I needed to read from the main instance and write to the secondary one so it wouldn't work for me.

At least that's how I understood it! I couldn't see anything in the doc that allows you to create new pages in secondary instances.

[Robin S]

3 minutes ago, DrQuincy said:

I couldn't see anything in the doc that allows you to create new pages in secondary instances.

This topic came up when I searched: 

 

[DrQuincy]

Interesting, you learn something new every day! I'll bear that in mind for next time.

I think I was put off by this:

Quote

As you can see, there are a lot of potential pitfalls, so use care with multi-instance. However, we suspect many will be using multi-instance simply as a way to pull data in a read-only manner, and in that context you shouldn't have to worry about much.

Since I was reading and writing quite complex models I was more comfortable using JSON and sharing data that way.

[JayGee]

Quote

As you can see, there are a lot of potential pitfalls, so use care with multi-instance.

I think some of the confusion arises around mixing terms for bootstrapping and multi-instance.

Unless I'm mistaken, I've always taken multi-instance to mean a multi-site scenario. I.e. multiple sites running off one core or database (or various combinations of this). Whereas bootstrapping allows one codebase to interact (including page creation) with the API of 2 disparate ProcessWire installations without needing to create your own custom endpoints.

But as @Robin S has highlighted above I'm pretty sure I've been able to write ok to bootstrapped PW instances, although it has been a while since I've done it so would need to test to be sure.