Closed jtcchan closed 6 years ago
On second thought, what I had initially thought seems excessive.
I didn't realize Minimal Mistakes was quite well documented on how to approach customizing their theme. This means we don't need to reference the gem files directly, as per my earlier comment. Will likely take a stab via MM's instructions first.
@jtcchan - if you are proposing putting the assets directly into _site, I would prefer not to do that, so glad you found the MM instructions. We would prefer not to put _site into the repo at all (e.g. mark it in .gitignore), and have it generated from by the build - locally or by GitHub. I have found that from time to time I have to delete _site because not everything is regenerated in it even when the source changes. I'd hate to have assets in that folder that might get deleted by a confused developer.
Ah, not quite. I was referring to commiting the theme files to /docs/
not the actual build files that lives in /docs/_site
. So my initial comment was around whether if should copy some or all of the relevant theme files/folders to /docs/
—which is everything under /_sass
, /_layout
, /_includes
, and /assets
from their theme.
I ended up going with copying over just the /_sass/
folder and /assets/css/
since I think most of the changes will happen there and having these files locally makes it easier to reference during development. I'll add individual files to _layout
and _include
to overwrite the theme defaults as they come up.
Sorry for not making that clear earlier. Hope that clears it up!
Pheww...that makes more sense. You never know when you start working with someone new that they might do crazy things. :-) All good!
Wait—you mean I'm not supposed to commit a shell script that runs rm -rf ~
? 😂
This is now resolved in #76. Closing!
I took some time to review our customization options.
At first glance, it looks like the best approach is to install the theme assets directly in the Jekyll site since we'll be heavily customizing the theme with our own palette and visual styles.
The alternative would be to continue using this (or some other) gem-based theme and overwriting what we need. This lets us benefit from future updates to those gems, but doing so makes it a bit less predictable on how those changes would affect our customized site. Plus, it makes design and development a bit more cumbersome, as we'll need to reference the gem folder to see what we're overwriting.
Will continue updating this issue with further updates. Feel free to @ me if you have any questions.