-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Case: Sharing content across multisites #1135
Comments
@bondjimbond So I just had a long conversation with @Favenzio about this in the context of our own multi-site needs within the state of Florida; our 7.x usage is that each participating college/university gets their own site, namespace and storage quota, and they are in charge of uploading & managing their own content. These sites stand alone and only have access to their own namespace (and the islandora namespace) so that they can't access other sites' materials. Aside from the college/university specific sites, we also have a "meta-site" that has access to ALL the individual sites, so it basically acts as an aggregation layer where you can search for and see anything in the Florida Islandora system. To do this in Drupal 8, @Favenzio and I decided that the best way might be to do standard Drupal 8 multi-sites where each site owns their own content, but each site indexes their content into a site-specific Solr core AS WELL AS a "meta core" that all the sites index to. An individual site can only search their own core, but the "meta core" has the content of ALL the multi-sites indexed in it. This way, you could create a meta-site that has no content of its own, and is basically a search interface to the meta core, and whenever you find a search result you want to see in the meta site's search results, you could configure it so that when you click on a result it links to you to the multi-site that owns it. This all assumes that you don't have legitimate reasons for actually needing content to live in two (or more) Drupals simultaneously, which may be the case. I can't think of any reasons why this may need to happen off the top of my head, and simply pointing to a node on another site when relevant instead of recreating it avoids all sorts of syncing issues that would rear their ugly head. Another idea, though one I like less, is building some sort of pseudo template that can pull the info from another site's node and display it using the host site's branding. |
Exactly our setup as well.
This could work, although we lose the not-insignificant value of having a window onto that content from the parent site, with a particular look and feel and theming that might include, for example, certain badges that a given child site doesn't enable.
Maybe some combination of both of the above? I'm reluctant to give up the idea of a "parent site" that not only searches all content, but also displays it in a uniform way. And would such a templating scheme be able to make use of Islandora modules in the same way as a "true" Islandora site... |
Suggested solution from the last tech call: https://www.drupal.org/project/domain |
Writing this out now because I don't think this use case has been fully articulated as an issue here yet.
A critical feature for Arca (representing 23 different sites and even more organizations) is the ability to not only have multiple sites connecting to a single Fedora repository - but for them to be able to share Islandora objects between them.
In 7.x, we are able to have one "parent" site (arcabc.ca), which can see and work with all objects, and any number of "child" sites (dc.arcabc.ca, unbc.arcabc.ca, doh.arcabc.ca, etc.) that are scoped to a particular subset of that content. This is due to the fact that Islandora 7 bypasses Drupal's content management for Islandora objects, and instead uses Fedora as its source.
In 8.x, we need a way to replicate this functionality, as a rather large proportion of the Islandora community works this way (perhaps a smallish number of consortia, but a largeish number of organizations that belong to them).
The text was updated successfully, but these errors were encountered: