You can uninstall the Hyde theme plug-in after you’ve installed the theme available on GitHub. And I agree with you that themes and plug-ins are a bit confusing. I think the UI and naming of things need to be tweaked some by @manton.
Here’s a quick guide. I assume your current enabled theme is Hyde.
Navigate to Design > Edit Custom Themes.
The next step is confusing, so read it closely.
Hit the New Plug-in button. (Yeah, I know, weird.)
Give the GitHub theme a Title and provide the Clone URL. Also, make sure you choose the correct Site in the dropdown if you have more than one blog hosted on Micro.blog.
Tap the Add plug-in button.
Now, navigate to Plug-ins and hit the Uninstall button next to the Hyde theme.
There are no more steps; your GitHub theme should be installed and enabled now.
Great overview, thanks @sod. Any suggestion for how we can improve this? The transition from the built-in themes to plug-ins hasn’t been totally smooth, admittedly, although I think the foundation is much better if we can get the UI right.
If you’re the author of the theme hosted on GitHub, your approach also works okay.
But if you’re installing a theme hosted by someone else on GitHub, you will run into trouble if you want to make customizations as @halloleo did to config.json. Should the original theme author release a new version, you will have to manually merge that with your changes.
If you install the GitHub-hosted theme like a plug-in instead, you can have all your modifications in a separate custom theme. That will be much easier to maintain. Migrating to another theme in the future (and keeping your customizations) will also be more manageable.
This is just my gut speaking. But I think that even though themes and plug-ins are technically the same, they are pretty different from a user’s perspective. Especially if they have experience with other blogging platforms.
So if it were up to me, I would hide the implementation details from the user and just let themes be themes and plug-ins be plug-ins. Keeping everything that has to do with themes bundled together, like browsing available themes, installing, and making overrides. And the same for plug-ins.
Would be great if micro.blog would pick up the changes automatically from GitHub, but refresh/reload button would work just as fine too. Maybe at some point!
Chiming in for this topic too
I got confused about the difference of themes vs. plug-ins today too.
The process I had in mind:
Make a fork of existing theme (Marfa)
Clone that repo to my local machine
Enable this forked theme via Design → Edit custom themes
Make changes to the theme repo on my local machine and push changes
See how my micro.blog theme picks up those changes…
That’s how I pictured the process, but I don’t think it goes like that, does it? I think micro.blog doesn’t pick up those repo changes automatically? Or did I miss something?
I guess what I’m asking: What is the ideal process of forking an existing micro.blog theme, making it mine and keeping it up to date in micro.blog (preferably via making changes to the theme via in a GitHub repo)?
I just added a new reload button when viewing the list of templates for a theme or plug-in. This will start downloading templates from GitHub again. It will update any existing templates or add new ones. (It does not delete templates that are missing from GitHub, so it still may be necessary to delete the theme or plug-in in some cases to force a full re-sync.)
The reload button will only show up if there is a GitHub URL set for the theme or plug-in.