Is there a way to configure Omeka S not to insert ‘/s/’ into the public URLs for sites? I’d like the pattern to be:
https://<hostname>/<site_slug>/…
not
https://<hostname>/s/<site_slug>/…
(And for clarity, I have Omeka S installed directly in DocumentRoot.)
I don’t see a setting for this; though pretty sur I can accomplish with .htaccess on my server. (Only hesitancy is that’s I haven’t actually done it so don’t know if Omeka S will be unhappy for some reason…)
As I look to more adoption of Omeka S (which is going to be really useful for me!!), it would be great to be able to avoid inserting this non-semantic character when creating clean public URLs.
I asked this question several months ago in a separate post.
If you look in root/application/config/routes.config.php, you will see an array containing structure route > site > child_routes.
You can see ‘route’ => ‘/s/:site-slug’
I believe one of the reasons this was done for the multi-site system is to protect collisions with page names for non-site routes like /api, /install, /migrate, /maintenance, /login, etc. Probably also some reasons relating to plugin compatibility and stuff like that.
Omeka-S is not designed to be a single site system, this is what I have found after experimenting with it for the past 9 months. I am currently in the middle of building out our final production beta to replace our Omeka Classic, and we will live with the /s in the URL.
It would be clearer (but longer) to just have the route be /site rather than /s. You CAN set the default site, so if you load base URL of Omeka-S, it doesn’t have to go to index page, it can go to site_id = 1 (or any site you choose).
Agreed that it’s a strength that Omeka S supports multiple sites. I am using that in my work. Each site with different ‘site_slug’. That makes total sense.
Also have seen that a default is settable. But that redirects to the ‘/s/’ URLs (right?), as opposed to proxying.
So… In a non-flame / gentle feature request kind of way… It would be great to reject certain values for the the first part of the path element of URLs rather than force the insertion of ‘/s/’.
But being somewhat new to the community (lurking for a while, now moving to production), I’ll pause to understand more before opening an issue on GitHub.
