Main and additional sites

[Daniel-KM]

Hi,

Currently, Omeka S allows to define a main page, but not a main site. This may be useful in many cases where there is only one digital library for an institution, in particular the smaller ones, and when there are a main site and additional specific collections.

The main issue is that it implies to remove the s/:siteslug, that is useless with a single or a main site, and to keep it only for additional sites.

So I was wondering if such a feature is planned, or if it is possible to pull requests for it, or if it is preferable to create a module that adds some routes and override some other ones (but because it is a core feature, I don't know if a module can do it).

Sincerely,

Daniel Berthereau
Infodoc & Knowledge management

[zerocrates]

My main concern with having an option that kills the initial "s/:site" part of the URL is the implications for the rest of the routes. For just /, the homepage itself, it's fine, but the problem is that users have pretty much free rein over slug choices within the site, so things that wouldn't normally be a problem could become one without that initial part (a page named "admin," or a page named "s", or with a slug that happens to correspond with what should be another site, for example). The static /s/ route allows us to skip worrying about any of that since nothing other than actual sites will match that route.

As for the general feature of a "main site," we do technically have that in the Settings. I assume by "main page" you mean how that feature is effectively a redirect that only affects the homepage?

[Daniel-KM]

The setting for the main page (the home page) is fine and I'm not afraid about some forbidden slugs for pages and there are not a lot (admin, api, and user related).

My main concern is about resources and i prefer short urls without useless parts. In Omeka S, their urls contain the slug of the site, but a site can (and will) change. I tried to modify the main routes in config, but an empty slug is no allowed.

[o1da]

I agree with Daniel-KM, it would be definitely a nice feature. Our customer simply complaints about ugly URLs - he has only one site and wants to use it as his main web presentation and I understand to him - from a user point of view it is "unnecessary complication".
I think it can be a common use-case.
I understand that it is much cleaner from a development side. It seems that I will have to prepare some rewrites to .htaccess and it would be quite "hacky". I would prefer easier approach :)

[zerocrates]

Swapping in a route for a particular site at the base probably wouldn't be a huge problem... though something would have to be worked out in terms of order so things like admin, login, etc. would be guaranteed to continue to work. Having just /s/ represent one main site might also work.

The easiest variation of this would probably be a single-site "mode" you have to turn on that just replaces the "s/[slug]/" route with "s" or "/", and then we don't have to worry about interaction with other named sites.

[Daniel-KM]

On this subject, for people comming from Omeka Classic, they want to keep exhibits, this is an important feature of Omeka. In this logic, there should be a main site and the other "s/" sites are exhibits.

So, if an option is added to allow to set one main site (or a simple htaccess config), it should not preclude the creation of exhibits/additional sites.

[o1da]

Can I ask you if this feature is something which can be added into next release or is it something from more distant future?

[hxsllc]

I would also like to request this feature. I am trying to implement it now (at first, through changing core - eek!) for two projects, including one with over 100,000 items. On that project, there would be sub-sites used as well, similar to "Exhibits" as Daniel comments above. Some might be student projects, others might be official sub-collection presentations. On the second project with under 1000 items, it would simply be single-site mode.

I also agree with Daniel that it is not a big deal (in real world practice) to avoid forbidden paths or path collisions. In theory it is nice to have a perfect system, but real world use cases are varied and reasoning on URL structure can be SEO driven, marketing, political, or other human aspects.

• Ben

[saracarl]

This request is also relevant for IIIF use cases. It's important to provide a "seeAlso" in a IIIF manifest that links back to the original item page, so that when the manifest is used "elsewhere" (i.e. for comparing one of "my" items to an item that resides elsewhere or in a Linked Open Data context that refers to my media) the viewer can find their way back to my site. We can't do this without some default site for an item (or the omeka-s installation as a whole).

[hxsllc]

From July 25, 2018, @zerocrates mentioned:
"The "front page/site" issue is definitely high on our list of priorities and will likely be addressed in 1.3."

But it didn't make it to 1.3 release on 11/29/18. @zerocrates any idea if it will be addressed in 1.4 and when that release date might be? This will impact my implementation plans for Edison Papers if it's coming soon.

[zerocrates]

1.3 contained improvements to the default "pick a site" homepage, and functionality for letting users create styled versions of that view within a site (with the idea that they'd set that site as default, thereby replacing our default).

1.4 is largely feature complete at this point, so there won't be movement on this issue in that version.

[Daniel-KM]

There are still some fixes for some routes of some modules, but the modules DomainManager, SiteSlugAsSubdomain, and CleanUrl fix separately this big issue.

[zerocrates]

I think we're still at the same place: basically what I'd support is the /s/ -only slug in a "single site" mode, where it's the only publicly accessible site. I really don't want to go down the road of having conflicts with the modules that live in the toplevel routing namespace, nor with having a "main" site at / or /s whose pages, etc. could conflict with also-available /s/:slug sites.

What I don't have as much of a handle on is if people feel that that more limited implementation is useful enough to bother with at all. We welcome continued commentary by those still looking for this feature, particularly if directed to whether or not the more limited form I've suggested is desirable.

Obviously as Daniel has written, there are some outside-developed modules that provide some of this functionality for those who want it, and that may be a better path if we can't come to agreement here.