Overriding CSS on Github Pages Using Slate Theme

Overriding CSS on github pages using slate theme?

rename assets/css/style.css to style.scss
and change your scss code to :

---
---
@import "{{ site.theme }}";
#footer_wrap {display: none;}
#forkme_banner {display: none;}
#downloads {display: none;}
#whocares {haha: hehe;}

How do I change the fonts used in a github pages theme?

I solved it using:

---
---

@import "{{ site.theme }}";
.markdown-body {
  font-family: 'Times New Roman', Times, serif;
}

How do you remove header on Github Pages?

I found you can customize your site CSS to hide the header by creating the file:

/assets/css/style.scss

---
---

@import "{{ site.theme }}";

header {
  display: none;
}

This is a closed issue on Github.

---

That said, you may want to override the HTML layout, so your site doesn't unexpectedly break.

Switch theme in an existing Jekyll installation

While you could migrate to an existing installation by forking a new theme and then manually copy and pasting over resources like CSS, JS, HTML in the _includes, _layouts and other files you may need, this probably isn't a great idea as you end up having a mash up of old and new resources, which may not be of the same name, but in the scenario that they are (for example you didn't overwrite an old stylesheet that your post references), it will cause mixed up CSS styles that you'll have to debug and slowly fix.

Since I'm assuming you have a Jekyll install with Git (if you don't you really should), you could create a branch called new-theme and switch to that branch from the master as the working branch. (A simpleton way of having something like this is to just copy your entire Jekyll install and paste it elsewhere as old-Jekyll-install if you don't want to deal with Git branches (but really, you should. Here's a tutorial that helped me learn)

1. Pull down the files for the new theme.
2. Manually copy over _posts and your customized changes.
3. Port over your _config.yml by manually comparing them and moving over what is necessary.
4. Build the site and see what you're missing, what might be messed up (for example in the past you might have added a few <br \> tags for spacing and you don't want that in the new theme).
5. Merge with master (or push it to production)

That being said all this is fairly manual and a pain, but at least you won't have to deal with conflicts in resources. The downside of doing this though is that your repository won't be synced with the theme repo. So you won't get upstream updates. I would still suggest that you fork the theme repo, port over your personal customizations for your Jekyll site, and then rename that repo for production. (this would of course no longer be using the 'existing' Jekyll installation)

Shopify - Best Practices to have the Theme Git repository and Live Shopify Site files in sync

There are several well written articles on Shopify website that defines different ways to organize your workflows. 2 main tools provided by Shopify are

1. ThemeKit
2. Slate

Slate is in low maintenance mode for now.

ThemeKit works pretty well and you can read about that at Setting up ThemeKit

A detailed guide about using Git to simplifying Shopify development Workflow

For automatic deployments from git to your Shopify store , you can use Deploybot. Few details about setting up Deploybot with Shopify

Regarding data Shopify stores compiled liquid files and images on its own cdn while the theme customizer data is stored inside config folder in file named settings_data.json so do not push that file into git.

For multiple developers working on the same site, you can use different themes configured with ThemeKit and make use of Theme Preview feature to see changes on frontend.

It is never easy to track 2 way changes. So it is better to use your git repository as signle source of truth and do not modify code on Shopify website.

You may also have a look at Motifmate Toolbox that is a 3rd party solution for theme development.

Why is the 'post' layout missing from so many themes?

Jekyll does not have a standard way of naming layouts, this has the benefit of flexibility but it can cause confusion sometimes.

Every theme can create their own layouts, so you will find that changing themes, doesn't work the way you expected, in fact, most don't because generally you will find default, page, and post layouts, but when you try another theme, their layouts would probably be called differently.

Take for example the minimal-mmistakes theme, one of the most popular themes out there, it has all these layouts:

_layouts/
  ├── archive.html
  ├── archive-taxonomy.html
  ├── categories.html
  ├── category.html
  ├── collection.html
  ├── compress.html
  ├── default.html
  ├── home.html
  ├── posts.html
  ├── search.html
  ├── single.html
  ├── splash.html
  ├── tag.html
  └── tags.html

if you just change your theme name in config, I bet it won't use all of those layouts.

This is why you need to customize your site following each theme requirements.

Note

You don't need to specify theme layout in each post, it is generally simpler to set it as a front matter default in config, and in this case, every post would use that:

defaults:
  -
    scope:
      path: ""
      type: "posts"
    values:
      layout: "post"

---

Related Topics