Posts

Showing posts with the label p11

How Do You Modularize a Jekyll Theme After Cloning It?

Cloned Your Jekyll Theme? Now It’s Time to Make It Modular

Most Jekyll themes — especially free or starter ones — come with tightly coupled layout files. They're meant to work fast, not scale. Once you've cloned the theme and detached from upstream, it’s the perfect time to restructure everything into reusable modules.

This guide shows you how to break apart your cloned Jekyll theme into flexible, maintainable components.

Why Modularization Matters

  • Improves reusability across different layout types (pages, posts, docs)
  • Makes maintenance easier: update a header once, apply it everywhere
  • Supports multilingual structure and conditional logic
  • Prepares the site for dynamic plugin-powered layouts

Step 1: Audit Your Layout Structure

Open the _layouts/ directory. You’ll likely find a small number of files like:

  • default.html
  • post.html
  • page.html

Inside each, you'll often see big blocks of raw HTML — headers, footers, menus, footnotes, etc. These should be moved to includes.

Step 2: Create Modular Includes

Common Includes to Extract

  • _includes/head.html — meta tags, SEO, favicon
  • _includes/header.html — logo, nav menu, site title
  • _includes/footer.html — copyright, scripts, closing tags
  • _includes/sidebar.html — optional for blog/doc layouts
  • _includes/post-card.html — reusable snippet for listing posts

How to Use Them

Edit your layout file (e.g. default.html):

{% raw %}
<!DOCTYPE html>
<html lang="en">
  <head>
    {% include head.html %}
  </head>
  <body>
    {% include header.html %}

    <main>
      {{ content }}
    </main>

    {% include footer.html %}
  </body>
</html>
{% endraw %}

Step 3: Break Large Sections into Slots

Jekyll supports nested includes and even parameter passing. You can split components into “slots” — reusable templates with flexible content.

Example: Section Include with Parameters

{% raw %}
{% include section.html 
  title="Why Modular Jekyll Wins" 
  body="Reusable includes save you hours of duplication." %}
{% endraw %}

And in _includes/section.html:

{% raw %}
<section class="info-block">
  <h2>{{ include.title }}</h2>
  <p>{{ include.body }}</p>
</section>
{% endraw %}

This makes your templates highly composable — a major upgrade from hardcoded blocks.

Step 4: Restructure Posts, Pages, and Data

Use Custom Collections

Instead of cramming everything into _posts, create logical groups using _collections:

collections:
  tutorials:
    output: true
  docs:
    output: true

Use YAML Data Files

Move global config, menus, team bios, or testimonials into _data files:

_data/team.yml
_data/navigation.yml

Then use them with:

{% raw %}
{% for person in site.data.team %}
  <p>{{ person.name }} — {{ person.role }}</p>
{% endfor %}
{% endraw %}

Step 5: Add Conditional Logic for Flexibility

Customize how includes behave based on page types or front matter flags:

{% raw %}
{% if page.sidebar %}
  {% include sidebar.html %}
{% endif %}
{% endraw %}

This enables layout reuse across blogs, landing pages, and documentation.

Step 6: Modularize CSS and Assets

Move your styles into SCSS partials under _sass/. Then use:

@import "base";
@import "layout";
@import "components/buttons";

This also lets you inject custom styles per layout or section.

Step 7: Maintain a Style Guide or Component Preview Page

It helps to maintain a hidden page with previews of all your components:

_pages/styleguide.html

Use it to test includes like cards, sections, buttons, banners, etc. It’s like having your own mini design system.

Conclusion: Fork, Clone, Then Modularize

Forking is the fast start. Cloning gives you freedom. Modularization is the next step in making your Jekyll site truly scalable.

Whether you’re building a blog, documentation hub, or full marketing site — modular Jekyll themes reduce repetition, improve maintainability, and make it easier for teams to contribute.

Once you've modularized your cloned theme, you're no longer just customizing — you're architecting.

How Do You Convert a Forked Jekyll Repository into a Fully Independent Clone?

Forked Your Jekyll Theme but Now Want Full Control?

Forking a Jekyll theme from GitHub is a great way to start quickly. But over time, many developers realize that being tied to an upstream repository limits their ability to customize, scale, or move platforms.

Thankfully, it’s possible to safely convert your forked repo into a clean, standalone clone — without losing any code, posts, or history.

Why Convert a Forked Repo Into a Clone?

Here are some common reasons:

  • You want to use unsupported plugins, layouts, or build tools
  • You plan to migrate to Netlify, Cloudflare Pages, or self-hosting
  • You're tired of upstream merge conflicts when the theme updates
  • You want to build a private or commercial product from the base theme

Step-by-Step: Detach and Convert Fork to Clone

Step 1: Clone Your Forked Repository Locally

Start by cloning your forked project to your local machine:

git clone https://github.com/yourusername/your-forked-repo.git
cd your-forked-repo

This gives you a working directory with the full commit history.

Step 2: Remove GitHub's Fork Relationship

GitHub doesn’t let you remove a fork status manually. So you’ll need to push your local code into a brand-new, non-forked repository.

  1. Create a new repo on GitHub (don’t fork — click "New Repository")
  2. Note the remote URL (e.g. https://github.com/yourusername/my-independent-site.git)

Step 3: Remove the Existing Remote and Add the New One

git remote remove origin
git remote add origin https://github.com/yourusername/my-independent-site.git

This detaches your project from the forked repo and prepares it for the new target.

Step 4: Push Everything to the New Repo

git push -u origin main

Or if your default branch is master:

git push -u origin master

Now your entire history, branches, and commits live in a clean repo — no longer tied to the upstream theme.

Step 5: Optional — Delete the Old Fork

If you want to avoid confusion or accidental edits, go to your forked GitHub repository and delete it (or archive it).

Bonus: Clean Up Upstream References

Check if You Still Have the Upstream Remote:

git remote -v

If Needed, Remove It:

git remote remove upstream

Now What? Own and Rebuild with Freedom

You’re now free to:

  • Add any plugins — including custom or unofficial ones
  • Refactor layouts without worrying about theme updates breaking your work
  • Integrate GitHub Actions or Netlify build pipelines
  • Convert into a modular Jekyll structure with collections and reusable includes
  • Prepare for custom domains, SEO tools, multilingual architecture, and more

Advanced: Rename Git History (If Needed)

If you want to scrub all evidence of the original fork in your history (e.g., for white-labeling), consider using:

  • git rebase -i to edit commits manually
  • git filter-repo (for advanced full-history rewrite)

This step is optional and often unnecessary unless you're reselling the theme.

Final Tips for Going Fully Independent

  • Set up a Gemfile and manage plugins with Bundler
  • Break out your layout into components under _includes
  • Use _config.dev.yml and _config.prod.yml for multiple environments
  • Document your new architecture in a README.md for future collaborators

Conclusion: Don’t Let the Fork Define You

Starting with a fork was a great shortcut. But now, it’s time to take full ownership of your Jekyll site. Converting to a standalone clone gives you the flexibility to grow, innovate, and deploy however you want — no upstream strings attached.

It’s not just about changing Git remotes. It’s about changing your mindset: from inheriting code to owning your platform.