Jump to content

read/write data references between main- and subinstance databases in a pw multisite setup or his alternate for restricted Page/Data-view?


August
 Share

Recommended Posts

Hi there,

most of the data comes from the pw main instance. There are also sub-pages (multiple sites, e.g. sub1.pwmain.instance.net, sub2.pwmain.instance.net and so on) each with its own database. In addition to independent entries, it should be possible to select or update data records here referenced from the main instance (pwmain.instance.net). These links (Page-References to pwmain.instance, e.g. ASM-Select) should be able to be reda and updated  from the second (site-sub)database. I tried this approach, with a hook and it looks something like this...

ready.php
image.png.8df222768401199272be3a3cad76c2e5.png

Then, it was possible to choose the entries directly from main-db and save in the site-sub database,
so this is how I call an entry in home.php (on site-sub)
 image.png.65ba2e0c8b8116a38cb787dd27d4b01c.png  

Without grabbing the id, it would show only the entry from the current "site-sub" domain (test_select_main_db).
That just doesn't seem optimal. That's why I kindly ask for your opinion!
 
Why am I doing this?
For different users I only need the view of their own saved datasets/links, each of them gets separate access to their own subpage (e.g. sub3.pwmain.instance.net). Every sub-user will choose from the same data-pool and can create (autocomplete, create-new and so on), don't worry about the person, who would fix some possible typos here  ..

On the other hand:
I've tried to map the whole thing in just one database, looks pretty good, especially using the admin-restrict-branch module with its great options. But the thought of getting a separate view on the fronted for each user and their own entries is giving me a headache...

Help please, I'm totally stuck, ..

What do you think would be the better way?

Link to comment
Share on other sites

  • August changed the title to read/write data references between main- and subinstance databases in a pw multisite setup or his alternate for restricted Page/Data-view?

I'd suggest that there are very much easier ways to go about things than using multiple databases.

I can think of various possible approaches, but I might go about it something like this...

You might have a set up like this, with the user pages below the home page having the users' names (to keep things simple for this example):

home
|____user1
|    |____page1
|    |____page2
|
|____user2
     |____page1
     |____page2

To work with the pages for the current user, you could get the pages thus:

// Get the user name
$userName = $user->name; // e.g. 'user2'

// Get all pages belonging to the user
$userPages = $pages->find("has_parent=/$userName");

// Get page2 belonging to the user
$userPage2 = $userPages->get("name=page2")

An important thing to note is that in the above example $userPages is a PW PageArray (https://processwire.com/api/ref/page-array/), and you can work with this instead of with $pages (i.e. all pages).

To deal with a superuser, you might do something like this:

if($user->isSuperuser()) {
    $workingPages = $pages; // All pages
} else {
    $userName = $user->name;
    $workingPages = $pages->find("has_parent=/$userName"); // As in the previous example
}

I've kept things simple here to illustrate the idea, but I imagine your set-up would be a lot more complex. But I hope this helps as a starting point.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...

Hi BillH, 
what I need, is the possibility giving every logged user his own pages in the front-end, not the other ones.
In the Admin-Page I've setup Admin Restrict Branch and allowed a Path for the 1st user. When these user is beeing in the admin-area, he has its own Page-trunk and only the given content should be visible on the fronted. All other pages should be restricted too, using page-protector.

Within the templates I have to check for users role (a shared role to all users, except the superuser), but thats not enough. How should I check for the pages associated with the current logged user? Thats the reason, thinking about the initial multi-DB-Setup, where every user has its own Access to shared information.

home
|____users
|       |____user1
|       |       |____page1
|       |       |____page2
|       |
|       |____user2
|               |____page1
|               |____page2

              image.png.f0124979fb96bb2e6dc4b59d1a8714ba.png  image.png.80905e531fa6ef526e805bbc547301aa.png  

 

Link to comment
Share on other sites

Hi @August,

The way I limit pages to users is setting the $page->created_user_id to the $user->id. Then my selector to retrieve pages is based on the created user id matching the currently logged in user.

Hope this helps. Just thinkin' out loud.

Link to comment
Share on other sites

You have two issues to deal with:

  1. Giving users access to their pages, showing them the relevant links, menus choices, etc (and not any others).
  2. Preventing users from accessing pages if they happen to find out or guess the URL of those pages.

For the first of these, you don't need either of the modules you mention. You present only links to the correct pages (and no other links), and you could achieve this using something along the lines described in my previous post.

For the second, you could perhaps use one of the modules, but you could also write your own code at the top of each template, maybe something like this:

// Assuming the root page for each user has the template "user-root",
// it's below the home page, and is name with the user's name

if($page->parent("template=user-root")->name != $user->name) {
	if($user->name == "guest") {
		$session->redirect("/");
	} else {
		$session->redirect("/$user->name");
	}
}

Let me know if you need more explanation or examples.

  • Thanks 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...