Use bootstrap3 as base theme?

[jprine]

While I like have the "custom" theme, the addition of the Authors: metadata tag leaves me to believe that future enhancements to pelican, enabled by the addition of code to themes, will be difficult to incorporate into the site because of the custom theme. I think we need to be able to track the upstream enhancements in an easier way, maybe through a cloned repo of bootstrap3 or something else?

I mention the use of bootstrap3 because it seems to support ipython notebooks, bootswatch styles for the theme, and the addition of custom.css definitions which means it should be easy to use for our purposes.

[earlew]

How difficult would it be to switch over to bootstrap3?

[jprine]

Here's my thought on order of operations:

1. Create a patch file or diff file that lists all our changes to our current theme from the original bootstrap. This requires some git-fu, but I think is easily do-able.
2. Find a bootswatch / bootstrap3 theme close enough to our current theme.
3. Add another submodule (ugh...) that is a repo based on the theme - that way we can keep our new commits, but also get old ones?
4. Change to the new theme & incorporate the diffs from 1, making any other changes.
5. Profit! ( = p )

Bootstrap3 includes ipython notebooks via liquidtags, so we may be able to simplify things a bit after the switch. I wish I could find a better way to do 3 so that we could just overlay versioned custom changes on top of a versioned base-theme, but I'm not sure how.

Oh, and as you can see by aec415b, this is not required to get the multiple authors feature working. It's just that, as new features are added in the future, we'll probably have to make changes to the style files and I don't want to maintain them by hand. Be able to update changes from a base theme would be useful. When I first started the site I didn't think it would be all that important, but there's some inter-twining between the style and content and being able to automatically include those changes would be useful.

[earlew]

Cool. I will let you take the lead on that one. This kinda project sounds like it could easily take a few days to get right. I was thinking that we could create a new branch (website_beta) that runs on bootstrap 3 and test out the changes there. When we are satisfied with the new theme, we could then copy the current site to a new branch (say website_old) then merge the website_beta branch to the current website branch.

I would be also be fine using the bootstrap3 theme as is and just make minor adjustments as necessary.

-Earle

On Oct 24, 2014, at 12:06 AM, J.Paul Rinehimer wrote:

Here's my thought on order of operations:

Create a patch file or diff file that lists all our changes to our current theme from the original bootstrap. This requires some git-fu, but I think is easily do-able.
Find a bootswatch / bootstrap3 theme close enough to our current theme.
Add another submodule (ugh...) that is a repo based on the theme - that way we can keep our new commits, but also get old ones?
Change to the new theme & incorporate the diffs from 1, making any other changes.
Profit! ( = p )
Bootstrap3 includes ipython notebooks via liquidtags, so we may be able to simplify things a bit after the switch. I wish I could find a better way to do 3 so that we could just overlay versioned custom changes on top of a versioned base-theme, but I'm not sure how.

—
Reply to this email directly or view it on GitHub.

[jprine]

This kinda project sounds like it could easily take a few days to get right.

Yeah - the biggest issue is just figuring out the right way to do it that'll make new merges easier in the future. I think it'll mostly be researching and testing, maybe even in an alternate repo.

I was thinking that we could create a new branch (website_beta) that runs on bootstrap 3 and test out the changes there.

Yup, that's the way to do it - I've already started a new branch, though I may change it's name.

When we are satisfied with the new theme, we could then copy the current site to a new branch (say website_old) then merge the website_beta branch to the current website branch.

No need to do this - you just merge website_beta back into website. We can tag the version change, if needed, to find it in the future.