I have a question about a feature we are hoping to implement in our theme, and whether this might be possible / advisable.
The feature is a format switcher for item browse pages, to allow users to choose whether items are rendered in a list format, grid format, or potentially other formats. In looking over other themes, it feels like there are two aspects of this feature:
Something to allow site builders to define how browse pages are rendered, as a blank setting. This much has been easy enough to implement with the help of the theme developers’ guide.
The more complex aspect is a user-facing control, to allow individual users to select for themselves how the browse page is rendered. I’ve seen themes like Foundation and Freedom do this, but only within the context of a single page load via javascript. Users must re-specify their choice after loading the next page of the browse interface - which feels awkward to me.
In poking around the Omeka codebase, I noticed that the pagination links are already persisting some parameters like sort_by and sort_order - so my instinct is to either copy or extend whatever is doing that already using a parameter like format=grid, format=list, etc.
Given all this, my questions are:
Am I correct in thinking that this is properly in the scope of a theme’s responsibility? I don’t want to mis-use the theme layer of Omeka when something is more properly done via a module, but this feels much more theme-like than module-like.
Assuming this is a theme concern, is there a piece of documentation that I should be looking at for guidance? I’m assuming right now that this would be a helper of some form, probably starting with the SortSelector helper as a template - but I’m still getting use to how Omeka operates, and I may have missed resources that would help me.
Many thanks for any perspective that anyone can share!
You could do it with JS and still not require re-picking if you use a cookie or localStorage or something similar to save the user’s preference.
Using a query string parameter is also a fine option. I believe the default paginator will already just retain any query string parameters used on the current page when it makes the links, so that may work fine on its own and only really require you to have link(s) that include the query parameter you want.
Oh, interesting - thanks for the info about the pagination elements potentially keeping the querystring intact already. That would make handling this on the server side a little easier, definitely. I’ve been poking around with helpers and have made some progress here, but not enough for us to launch with yet.
The javascript route is interesting, in part because it might allow us to support the user preference across their engagement with the site, and not just within the context of a single use of the browse UI. If I understand the relevant laws, though, this is the sort of thing that we’d need to get consent from the user for when storing that value in their browser? That is doable, obviously, and loads of sites have that sort of consent mechanism already - we’d just need to do the same with our theme.
For now, I think we’re going to leave this feature on our future roadmap rather than try and finish it now. Thanks for the pointers, though - looking forward to working on this when it comes around again.
I believe @gsoules has already solved the issue with his Avant plugin series, although for Omeka Classic; still, you could use that solution to inspire yours.
Hope this helps.