Foundation S: alpha release seeking feedback

We’re releasing an alpha for the Foundation S theme, an Omeka S theme built using the ZURB Foundation front-end framework. This theme was built with fast prototyping in mind, and has already served as the starting point for multiple projects at RRCHNM. The goal is to support as many features of Foundation for Sites as possible to provide theme users with more customization options using existing markup and style patterns.

Foundation S comes with 4 stylesheets: “Default” is the prototyping theme, while “Revolution”, “Sea Foam”, and “Inkwell” are themes with individual aesthetics built on top of “Default”. You can use these themes out of the box or as references for building your own.

Foundation S is another Omeka S theme that supports Sass for managing variables and patterns within their CSS, and makes use of ZURB Foundation’s extensive library of mixin components. Much of the theme’s customizability lives in the Sass, though we would like to provide more configuration options within the Omeka S interface for users who prefer not to write their own CSS.

Some features of the theme include:

  • Choice between vertical and horizontal navigation
  • Layout options for resource browse views (grid, list, or both using toggles)
  • Layout options for resources show views (stacked or inline properties)

For further information, please refer to the theme’s documentation. You can download the alpha release here. There is an equivalent theme in development for Omeka Classic.

We’re interested in initial impressions, feature requests, and of course bug reports. This is part of a bigger effort to expand theme offerings, and we’d love to hear how we can better serve theme designers and developers.


Very excited about this theme!

The first question from my Omeka group at my work was who will have access to this, and I don’t think I’m seeing it explicitly in the manual. Does it fall under the common permissions, where only Site and Global admins will have access to altering the CSS using this module? (Where the user manual reads “Site administrators can interact with active modules where appropriate,” I’m not always sure whether what I consider appropriate is the same as what code authors consider appropriate.)

@triplingual Yes, only site and global administrators can edit theme configuration and the CSS Editor module.

1 Like

Thank you for the quick response!

1 Like

I just had a look at this, and it looks great! Fantastic to have some flexibility without editing the theme files directly. And I particularly like the option to have the navigation on the side (“full height column”) and the possibility to toggle between grid and list in the search pages.

Some issues I have encountered:

  • both list and grid in searches do not truncate item description, so if there is a very lengthy description, the result is not visually satisfying… keeping the first 300 characters or something and then truncate would probably work best.
  • when “full height column” is enabled, then in some visualisations such as “advanced search” or the search via map from the mapping module the menu takes full width, and the search appears only below
  • perhaps minor, but still worth mentioning: if you have fields in multiple languages, then there is nothing separating the name of the language from the actual string (the default theme, for example, has a little grey background on the name of the language)
  • the relevant module may be to blame, or probably it can be fixed with some css, but when enabling UniversalViewer with the revolution stylesheet, the usually black background inherits the tint of the page background and looks just odd

Moving on to feature requests and daydreaming:

If at all possible, an option to be able to toggle the image full screen or zoom (e.g. via OpenSeadragon) would be nice, if not on the item page, then at least in the media page.

In reference to the media page, as I have pointed out elsewhere in the forum, I feel that there should be a link from the media page back to the item page; as things stands, if someone ends up on the media page they wouldn’t be able to tell to which item the media refers to (and given that many media have scant own information, I feel this may often be confusing).

Finally, a broader issue (that may be more a feature request for Omeka 3 than for this theme specifically) is to have a better way to list sites: the current list feature is visually unappealing, and even just a grid would be much better (but that, I suppose, would require each site to have a featured image to be used in such occasions).

Again, fantastic work, and just fixing the first two issues I mentioned would make this perfectly usable. Do you expect to relase it any time soon? (or, more broadly, is it more like “a couple of months”, or more like “maybe next year”?). I’d be happy to test a beta when the time comes.


Thank you for all your comments! I’m filing them as issues in the github repository and hope to address them in the next few days.

when “full height column” is enabled, then in some visualisations such as “advanced search” or the search via map from the mapping module the menu takes full width, and the search appears only below

For clarity, would you mind providing screenshots of the problem? I think I see it but I want to make sure we’re on the same page.

With regard to the release time, I’d like to get the theme fully released by the end of the year, with a beta in the next couple months. I’ll make sure to keep this thread updated as releases come.

Thanks for your reply and the update.

As for the issue I mentioned, having a closer look, I see it is related to the responsiveness, but I feel it is still a bug. If I have more than ~1400 horizontal pixels, then everything looks fine. But I originally checked this on an old laptop, so I was below it. I understand that most modern computers have higher resolution, but still, I feel the full width should kick in at much lower resolution (say, under 1024px), similarly to what happens in other pages, and even then, move to the menu style for mobile devices, again as happens in other site pages.

Anyway, for reference here are the screenshots (intentionally blurred on text):

Here is a random item, with “full height column”, menu on the left, all as expected, and as I see it on most pages (site pages, items, collections, etc.)

Here is an example of what I meant, on the /map-browse/ page. The navigation is on the top-left, but the div with the navigation goes full width:

Same with advanced search:

1 Like

An additional thought: given the fact that media are shown laterally, this makes it less problematic to have media metadata under each media embed directly in the item page.

This can easily be accomplished by adding the following just below echo $media->render();? , in foundation/view/omeka/site/item/show.phtml

   <?php echo $media->displayValues();?>

To reduce ambiguities, labels should ideally be adapted to highlight that they refer to the media via item templates used in the media themselves.

Reducing the font size of such additional information also contributes to show that these are separate from the main item metadata. Adding this to the CSS worked for me:

.media-embeds {

.media-embeds dl {
  margin-bottom: 0.1rem;

I think that adding something like this in the settings would be great, as it would solve an issue that I found in all main Omeka S themes: either the media metadata are unimportant, and the media page is never shown, or the media metatata are important, and the media is shown on the item page only as a tiny preview, basically forcing users to click through to the media page. I feel that with the Foundation theme we can have the best of both worlds.

A final custom solution that makes this perfect for my use case (where some items have meaningful metadata, while others don’t) is to make it conditional. I’ll leave this here, even if I’m not sure this is easy to explain in settings, so probably should be left to customisers.

In my case, I want media metadata to be shown only if more than one media metadata field has ben filled OR if there is more than one media associated to the same item. If it’s just one media for one item, and only the title field has been set, my assumption would be that the media title is the same as the item title, and adding it there would just be a distraction.

This is how I set this up in the show.phtml page:

<div class="media-embeds">
<?php foreach ($itemMedia as $media):

   echo $media->render();
   if (sizeof($media->values())>1 || sizeof($itemMedia)>1):
     echo $media->displayValues();


When different items and media have different levels of details such as in our case, this really solves the difficult question of wether or not to show the media metadata, when they are often unimportant, but sometimes they are.

1 Like

This topic was automatically closed 250 days after the last reply. New replies are no longer allowed.