I currently don’t see a way to access/manipulate structure field data stored with one site, on another site. Meaning that you could provide the structure field data source to another structure field.
I was wondering what options you would suggest. I personally have come up with the following options:
- Implementing a plugin/field type that has a sort of query option for which you can specify a page and field name. Something similar already exists for select fields. This however seems like quite a bit of work and knowledge of the inner workings of the panel/fields/structure.
- Let each site have their own structure data and using page hooks to copy/merge/sync the lists when saving the page. It’s a bit hacky and can cause issues when multiple people edit stuff, but at least it kind of seems like straight forward.
- Have custom sync buttons in the panel with which lists can be synced. The hooks are IMHO a better option here.
- Write forms on the front-end to manage stuff. While it’s quite a clean option, it’s bot really where I want to have this stuff.
Let me know if you have any other ideas? 
Could you not do it via JSON? I guess you could use a hook to write the json to yaml in the text file.
Not quite sure what you mean with “via JSON”.
For example I have a page A with structure field Y and page B which is a child page of A and now I want to access page A’s structure field Y’s data in the panel. How does that work via JSON?
In my experience it’s not doable to manage the same content in 2 locations. If you really need to propagate content across sites, it’s better to setup 1 “Master” (with a panel) to manage the content and draw in that content in a controller on another site (e.g. via JSON as @jimbobrjames suggests).
If you don’t do that, you’ll not only have to setup a plethora of hooks and custom code, but you’ll also have to account for race conditions and their unexpected behaviour for editors.
Are we talking about the same site - but different pages - or are we talking about different sites?
What is your use case? It might help if we have some more context.
Sorry for causing confusion here, in German “page” and “site” are interchangeable, but it can easily have a different meaning in English. 
I meant to say “page” in all cases, so it’s all on the same site.
The goal is to have a list of people and have sub-pages to manage sub-sets of people, like only manage members or only manage sponsors, etc.
I guess some alternate solution would be to have filter buttons and have everything on one page. 
AFAIK this is not possible out of the box.
But it might be possible in Kirby 3. 
1 Like
If you add your list of people to the parent page, you can still have subpages in your frontend that only display a filtered list of people without having to manage these people in two places. Of course, you can also do this in one page and use filter buttons, but you don’t have to.
Yes, with front-end pages, everything is possible, but also requires more effort to implement.
The goal is to able to manage from 2+ different locations.
I was mostly just wondering if I overlooked an existing option, but it seems like there’s no easy solution.
For now, I’ll just go with one list and implement everything required around it and see what I can do in a second step.
Thanks for all the help! 
What is your use case for managing content in different locations? Is it because of permissions?
Maybe a plugin like Kirby-sortable can help, it would at least allow you to have edit links to the subpages where the data is kept.
For one, if you have say 50 entries in one list, it’s hard to navigate and find the entries you need. Plus if you group them, you have to either decide to sort by group or sort by name to be able to find stuff more easily.
Being able to split the different groups into subpages, makes it a lot easier to handle. So mostly UX reasons.
Kirby Sortable might work, if I manage the content via pages instead of structure fields. Still leaves the issue with elements being part of multiple groups.
It starts to feel, that maybe I need to first flesh it out more, to really see, if the use-case is required.