Subdomain-based tenants in Omeka S (optional, env-flagged)

[tacman]

Hi Omeka S team — first, thank you for all the work you’ve put into this project. It rocks.

We’d like to simplify running multiple sites without having to deploy separate containers and are thinking about adding subdomain-based “tenants” to Omeka S and want to ask upfront if a PR in this direction is something you’d be open to reviewing/accepting.

Idea (high level):

• Tenants are based on subdomain (e.g. tenantCode.example.org).
• Tenants are distinct from Omeka “sites” (sites remain at /s/:site-slug inside a tenant).
• Single database (no per-tenant DBs).
• Local file storage scoped per tenant under /public/<tenantCode> (later, S3 bucket config).
• Tenant-specific settings would be minimal; currently we only need default locale per tenant.
• The feature is off by default and gated behind env/config flags to avoid impacting existing installs.

As I see it, files likely to touch:

• application/config/routes.config.php (Hostname route)
• application/src/Mvc/MvcListeners.php (tenant context + session cookie)
• application/src/Service/File/Store/LocalFactory.php (tenant base path/uri)
• config/local.config.php.dist (new config/env docs, likely to move to a tenant table later)
• likely a small tenant context class/service

Anything else you’d want us to look out for or any architectural guidance based on Omeka Classic’s tenant support?

If this is in-scope, we can share a more detailed implementation plan before coding.

Thanks again for the project and for your time!

PS I just released this: https://github.com/survos/omeka-bundle

[zerocrates]

So, I've been thinking about this a little bit myself, from a different angle. I've been thinking more of a system where a small piece of code, in PHP or whatever language, would be responsible for switching some settings and handing off to the regular Omeka S codebase. And that these changes could be accomplished with env-var settings (which also makes any env var features we add usable for other use cases that might want them, like container-based setups). We have env-var support for doing the database credentials, and for example my eye is on loading either alternative or extra config files or arrays, which would open the door to storing files in separate local directories, S3 buckets, etc..

I'm not sure we'd want to go as far as you're proposing in terms of plumbing this into the actual Omeka S codebase, vs. what I've described as providing places for such a "multi-tenant" system to affect and alter settings/config as needed.

As for general commentary on what you're looking at, I don't know that you'll be able to get away with avoiding having multiple databases to do what you're talking about.

[tacman]

Indeed, I have a project that does exactly that, upon request it flushes the current connection and switches the database connection. That might be the better approach here.

My fork now supports DBAL 4, Doctrine ORM 3.4, PHP 8.4 (so the Doctrine proxy classes aren't necessary anymore). It's replaced a few of the laminas dependencies, e.g. using monolog, drops doctrine annotations, etc. It also supports postgres and sqlite (for testing, not production)

I'll do a separate post on that. It's related because I did all that to prep for adding tenants.