Multiple sites without multiple installs?

I'm investigating the use of Omeka both for exhibits by our Library's special collections staff and for faculty at my University to do DH-style work. I'd like to understand a bit better what our options are for using Omeka for multiple branded online presences.

For exhibits, I can see how one install could easily support multiple branded exhibits using themes. We'd simply point users to the exhibit URL and have a theme that doesn't obviously link to the Omeka collection and item pages. I see many of the sites featured on the Omeka page use this approach. However, for the most part we wouldn't be reusing objects between exhibits, so having items from all collections be available for use in an exhibit would introduce confusion and slow down exhibit creation. I don't see a way to restrict an exhibit to pulling items only from specified collections, though. Does this feature exist, or would it be easy to introduce?

However, for many of our uses we would also want searching, browsing, and individual item display with structured metadata to be restricted to and branded for a given collection or project, distinct from other collections. I don't see a way to do this with the current state of Omeka - is that correct? Are there any other options for gaining this functionality other than managing separate installs of the software?

Basically, I guess the core of what I'm asking is if it's possible with the current architecture to set up multiple "sites" with a single install. We'd like to avoid a separate Omeka install for each new project, partially because it seems like a lot of overhead, but more importantly for streamlining future migration, security patches, etc. I see the hosting signup page lists some options that come with multiple "sites" - are those separate installs, or is there something in the current Omeka software that already allows the kind of separation of content I'm hoping for?

How are other organizations that have widely divergent content in Omeka handling this?

Jenn Riley
Head, Carolina Digital Library and Archives
UNC-Chapel Hill sites are really more like separate installations, each has their own plugins, their own data, and their own users.

There aren't currently any features for restricting the scope of items for an Exhibit, but such a feature likely wouldn't be very difficult to add.

The scheme you describe, where an Omeka install would have separate, differently-branded areas to search and browse only the contents of specific collections, could be achieved with theme and plugin support, but not "out of the box."

This is extremely helpful, thank you.

Is there a mechanism for getting improvements like allowing exhibits to only draw from certain collections back into the core Omeka code base? (Or in this case, into the Exhibit plugin core code?)

I'd like to hear more about what you had in mind for how theme and plugin support could achieve targeted searches and browses for different collections. I've found mention in the forums of the possibility of adding PHP tests for collection name to determine which theme is displayed, which I hope to explore. I'm guessing that's part of what you were imagining. What general approach did you have in mind that would allow searches and browses to be scoped to specific collections?


If you're talking about code improvements or patches, a "pull request" to the Exhibit Builder's GitHub project would be the way to request that your changes get merged into the official Exhibit Builder code.

As for branded search with theme and plugin support, I had a few (broadly sketched) ideas. Certainly, the theme view for the "browse items" page could easily detect the "collection" URL parameter and modify the display of the page appropriately.

It's also possible, as you saw elsewhere on the forums, to write a plugin that will simply switch to another theme entirely based on some test (again, likely something in the URL).

The only catch is that, depending on your needs, it might end up being simpler to have separate, parallel Omeka installations. Since you'd already be managing separate datasets and separate themes, having multiple sites might not add too much overhead, maintenance-wise.

Thank you, this gives us some ideas to work with. Much appreciated.