Do we have the capacity for a theme?

[Rosie Le Faive]

I've been hearing a lot of crap about the Islandora Starter Site and how it looks really ugly out of the box.

Yeah. I know.

One thing: it's hard to have it look like anything if there's no content. We're working on that (meaning Kirsta, Nat, Kyle and I are making an improved set of content based on UTSC's demo content). (Also, if you're using ISLE-DC then the `make demo_content` command has some install-profile-specific stuff in it and doesn't work with the starter site. We know. It would be nice to make it work. If you know about this and want to help, PRs always welcome. chat with us in #starter-dev.)

Content aside.

A theme is a particularly finicky component. It's not just css these days, it's node frameworks and sass compilers and other plugins and tools. Every one of which can pose a security threat if not carefully maintained. And using them requires a special skillset. And a theme is one of the key things that can make a drupal site look like "your" site - exactly the way you want it. For some of us, this is a big draw of a Drupal-based framework. 

But if you have this theme development skillset, you're probably spending your time making custom themes for your employer. So unless a handful of talented theme developers jump out of the woodwork and decide to maintain something that "we can all use" in terms of a theme, it hasn't happened and seems unlikely to (unless you want to make a working group and make this happen!?)

Aside from that, the whole point of Islandora is, to me, that it's tools that you can use. The more portable and maintainable the tools are, the more likelihood we have of more people using them. The more we bundle an entire site together in one single package, and say that islandora uses one specific theme, one specific install profile, one specific way of setting up your content, etc... the more we're pushing away the institutions where they have resources and folks who can meet their specific needs. Which means the developers who know what they're doing no longer share our codebase, or have a business case for working on it. 

This is why I'm aiming for:

* using Drupal's default theme with the starter site.

* putting little bits of CSS in modules where needed, but with a goal of maintaining our components' portability to any theme.

* encouraging people to share what themes they've had success with using/developing.

* putting all the logic you need in things that aren't the theme. 

I'm not against folks developing their own Islandora themes, that would be great. But look at the current code base. look at the current developers/committers. Look at the current state of the Foundation. Look at the existing theme and how successful development has been there. How do you see the paltry "us" working together to do a theme?

[Josh]

I'm pretty new to Islandora 2.0, but coming from Islandora 7, I think your 4 points sound good. Other Drupal modules don't have a specific theme, so there's no reason Islandora should. And if we make parts of Islandora depend on (or have the assumption of) a specific theme, we may turn people away from Islandora who want a custom theme.

I don't really see a benefit to there being an "Islandora theme" since anything we created would have to be pretty generic, and Drupal already has plenty of generic themes to choose from. And like you said, many of us will want a custom theme anyway, and different institutions are going to want to do that differently. Some might already have a Drupal theme, and some (like me) want to find something that's close and make the minimum amount of tweaks necessary. That being said, offering suggestions for themes that look good with Islandora would be nice. I plan to create a subtheme for my institution and customize the CSS to better align with our other web properties, so some suggestions for themes that can be used as a base for subthemes would also be appreciated.

In my opinion, each module should contain the minimum CSS it needs to function (and look OK, be accessible, etc.), with the assumption that it should work on any theme and hopefully is easy to customize. If there are any other requirements, such as blocks, that are needed for some module to work, they should be added to the module. For example, to display breadcrumbs or advanced search or things like that.

All that aside, if people are unhappy with the way the starter site looks out of the box, maybe we can come up with a different approach to help with this. Something like an optional set of configurations and modules that can help people get started on styling their sites. For example, adding a background image (or slideshow) and a search box to your home page and tweaking the colors a bit can make a big difference while still using the default theme.

[Don Richards]

Just so the information discussed from today's tech call is mentioned. Bootstrap barrio gives the user a subtheme directory. Copy that directory to your theme directory. Change the file names and the references to match whatever you wish, and you get a ready-made barrio subtheme. Bootstrap barrio included the full instructions here. This is an example in progress of what a customized subtheme would look like. To add it correctly to the composer.json file, you would need to specify it like the following with a "require" of the parent theme. This way, when you run `composer require jhu-idc/idc_ui_theme_boots`, it will install the theme and the parent theme at the same time. You can name it whatever you want, and the 'reference' is the git branch to use.


The file structure of the subtheme looks like this. It's really basic and appears to be as minimal as possible to maintain.