micro.blog’s theming confuses me: I have changed via the “plugin themes” to the Hyde theme. To customise the look a bit I added my own theme just for a config.json. So far so good.
Now I think of trying a “github theme” i.e. a theme for which there is a GitHub URL. Do I understand it correctly that I need for this a “blank theme” which I then overload with the “github theme”?
But how, in the first place, do I get rid of the Hyde theme? (No Remove button or similar in sight…)
This was true once, but not anymore.
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.
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.
Wait, why not hit the New Theme button and then enter the Github theme in the Clone URL field? That’s what I did for my custom theme.
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.
100% agree with Sven.
Interesting point! Super good to know!
And of course: Thanks heaps for the detailed info to begin with! 
Update: Browsing through the discussions, looks like this is a known “issue”: https://help.micro.blog/t/pushing-theme-updates/1067.
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:
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)?
Thanks!
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.
Wonderful! Thank you so much Manton!
