Request page template in theme, without Tools side menu

[StevenCannon-USDA]

it would be nice to have another page template in the theme (as an option) that doesn't have the Tools side menu. I am pretty sure there will be some pages or I-frame'd apps for which we'll want to maximize real estate.

In fact, I am ambivalent/undecided about the side menu on the site in general. I could see it being used only on the home page, for example (where it provides convenient access to tools AND advertises of their existence).

[StevenCannon-USDA]

With SoyBase likely joining in the Jekyll game, this request has increased importance. It looks like quite a few applications will be pulled in via iframe (at least initially), and the left-side real estate will be needed. https://github.com/soybase/jekyll-soybase @alancleary

[adf-ncgr]

I'm going to provisionally punt this one over to @sammyjava for consideration, partially because he's the jekyll-boss but mostly because @alancleary is trying to stay focused on his own funded research for the next week or so. Not sure of the actual urgency (ie when it will be a blocker for soybase folks)?

[StevenCannon-USDA]

Actual urgency isn't high, since we're still mostly kicking the tires with the technology. I did want to highlight the issue again though, since it is a topic of discussion for the SoyBase group - because of the visual collision in the iframe condition. We may also be able to figure it out ourselves and do the pull request. Adding @maxglycine to watch.

[adf-ncgr]

Great, thanks for clarifying and for getting all the kittens herded in a similar direction- hopefully you are not lining them up for a slaughter ;)

[alancleary]

I'd be glad to take care of it after next week. If you want it sooner or if someone feels like tackling it before then, I recommend setting the default behavior of whether or not the tool menu is automatically shown on each page via a variable in the _config.yml file but allowing it to be overridden in a page's front matter.

[sammyjava]

Added @alancleary back in since he's glad to do it next week. I'm happy to do it if that doesn't happen.

[alancleary]

Added @alancleary back in since he's glad to do it next week. I'm happy to do it if that doesn't happen.

The week after next week!

[adf-ncgr]

Is this the week? I'll note that @ctcncgr mentioned some vaguely similar customizations that he found himself wanting to make when reusing the templates in the context of the medicago-centric site, but I think if you set the model for how to approach such configuration he will probably be happy to follow your lead.

[sammyjava]

I'll note that this issue should be moved to https://github.com/legumeinfo/jekyll-theme-legumeinfo, which will be soon be renamed to not indicate legumeinfo specificity, since it's a theme update. As for me, I've kept my hands fairly free of of the theme, working mainly with the site repo jekyll-legumeinfo, although I do have some changes in the shokin branch of the theme repo, some of which may work their way up to the main branch.

Sorta on this topic: I don't think it's appropriate to branch jekyll-legumeinfo for non-LIS sites: the theme is already standalone, so it makes sense to fork (not branch) jekyll-legumeinfo over to a new repo like jekyll-soybase or jekyll-medicago. I'll continue to add plenty of LIS-specific stuff in jekyll-legumeinfo (like scripts) which probably do not apply to any other site in the world. You can always merge code across forks if you desire to (I do this all the time with InterMine since I don't have perms to work on a branch there).

I've probably said this in an LIS call but here is my official Github missive. It's like tweeting, but way cooler.

[adf-ncgr]

I don't know if this changes anything (especially not with respect to the coolness of your chosen message-medium), but at least for medicago the idea we've been pursuing is that it will no longer be a non-LIS site; it will be medicago.legumeinfo.org and is meant to seem like LIS, only with more medicago flavor. Whether branching or forking is necessary for this model (like legumeinfo only cooler-season) is unclear to me at this point.

[sammyjava]

Presumably the assets and data and a lot of other content will be different, even if the layouts are similar. I think of branches being things that are planned to be merged into the production branch, the one you see by default if you look at the repo. So in that sense I think a fork makes more sense for a separate site. It doesn't matter what its hostname happens to be, the point is it has different content, and Jekyll includes content. In terms of code management, there isn't much difference between merging between branches of the same repo and merging between forks.

I'll probably put on my Jekyll boss hat and insist on separate repos for separate sites unless someone comes up with a really convincing reason for using branches under jekyll-legumeinfo for other sites.

[adf-ncgr]

I'll just note that at this point github does not appear to support taking a repo in an organization and forking it into the same organization, although this functionality seems to be on their development roadmap: https://github.com/github/roadmap/issues/330

But whatever people doing development think makes sense is fine with me. I just hope you don't have to bring out the jekyll-boss comfy chair...

[sammyjava]

Hrm, I didn't know that. Good point, and you can only fork a repo once into another organization. Which I guess is sorta the same, you can't have two forks of a repo in the same organization.

[alancleary]

Is this the week?

It is! And thanks for the reminder. I completely forgot!

Regarding forks vs branches, I agree with Sam; other sites should be forks, not branches. I won't die on this hill, though.

[alancleary]

I created a branch in the theme repo that uses the front matter approach I previously described in this thread to make the vertical tools menu and the news/announcements cards toggleable via a page's front matter and/or the _config.yml file. Have a look at the Configuration via Front Matter section in the branch's readme and if it looks like a workable solution then I'll merge with main.

[sammyjava]

Love it! I think front matter directives are the way to go. Jekyllicious.

[StevenCannon-USDA]

I like it too! Thanks for the addition, Alan.

[alancleary]

Done in commit legumeinfo/jekyll-theme-legumeinfo@c9c6d15c92239372c502e86f61e174504f1caf13 and c454e747820babf2c470ded52475ace11ee55fe1.