Either direction works, although for my money, I’d rather be able to pull from Github my custom theme, not unlike how a plug in can pull from Github. Despite the great work done on previewing design changes, for some combination of what’s in my test blog and the kinds of changes I do, I think my preferred flow long run is locally developing using Hugo, pushing to Github, and then being able to pull that into my theme. There are some complications I haven’t fully run down with things that are MB specific and can cause a local Hugo build to fail, but I figure I will either solve those problems or eventually write plug ins for the MB parts so that I can avoid issues with my own theme.
That being said, if I could “push” versus sync on demand from Micro.blog to GH and create a PR it would be a huge joy.
Overall, my feeling is that for deep theme work, editing within the micro.blog interface is not the best option. The MB interface is great for small tweaks when you’re just customizing a bit, but not my favorite for full on theme development.
I’d add that in particular, my tweaking can often cause lots of builds and queuing (which is good) but the result is a pretty slow feedback loop. And I see a lot of people complaining about things not working where I think they’re just misreading or not reading logs and don’t realize their changes won’t take effect for 3-4 more minutes while two or three builds stacked up as they edited 2 templates + css.
I just realized that my statement here makes me realize I should probably bite the bullet and make my theme a plug-in, but I’m not sure I want to support it/clean it up/advertise it as “good to use” versus it just being where I put whatever I want. It would, however, let me have Github as the source.
Yeah, the advantage to making it a plug-in in the directory is that you can push to GitHub and then you get an “Upgrade” button in Micro.blog, which does mostly what you want for GitHub sync. I don’t think you should feel any pressure to support it. I can see how that might be tricky though if people do ask you questions.
One issue that came to my attention today is @Moondeer’s Bookshelves plug-in which uses data files that the user should edit. This will no longer work, because the “edits” are stored in the custom theme and then overridden by the plug-in. I considered changing the processing order but I think that creates more problems, such as not letting plug-ins override templates in a custom theme.
Another solution is to encourage plug-ins to always use config.json or the Settings button feature. Micro.blog can be smarter about merging multiple config files together without losing changes.
I copied the theme and called it Hitchens green, and that worked, except now it’s also overriding the settings (so my subtitle entry isn’t showing correctly).
There’s a lot of confusion about this so let me try to explain it better here. I just tested this with Hitchens and it worked well for me:
Install the Hitchens theme plug-in from the directory.
Create a new theme: Design → Edit Custom Themes → New Theme. Call it something meaningful like “Hitchens Colors”.
When creating the new theme, do not clone anything. Just give it a name.
Set your blog to use your custom theme.
Edit the theme and you should see the Hitchens templates appear in the list. Click on style.css to edit it.
When you save your changes, Micro.blog will create a new copy of style.css. Updating the plug-in later will not change that copy.
This essentially tells Micro.blog that there are 2 “bundles” of templates: 1 for the Hitchens plug-in (with all templates), and 1 for your custom theme (with just style.css).
Let me know if you have any questions or if anyone is seeing something unexpected.
And for people who love rabbit holes and want to learn more. Behind the scene, this is just how Hugo works with Bundles and Lookup Order. Right, @manton?
Actually (surprise!) nope. I built the way Micro.blog processes these before I knew about Hugo Bundles. Could be an opportunity to modernize the backend later.
@toddgrotenhuis But if the main theme has major updates, you may need to update the theme at some point. At least right now, @pimoore is rolling out excellent updates to Hitchens at a rapid clip. I would wait a while before creating your own Hitchens custom theme.
After that, you can work with Pete to update minor changes. Or see the differences on Github and update it yourself. Yes, I just volun-told Pete for theme support.
That seems necessarily true-- you can’t pull in changes to the underlying code that you have “unmerged” changes on top of and not expect any conflicts ever. The more you customize a theme away from what it was, the more you’ve built your own theme on top of another one that forks away.
I would assume that any theme customization that is not using the custom CSS or plug-ins is at risk at wiping away if you manually choose to update the underlying theme you started with.
As someone developing a theme meant to be released as a plug in right now, I will give literally 0 thought to a full refactor and change of how everything works, so long as plug-in includes and custom CSS includes work. That’s the only interface guarantee I can comfortably make.
I agree hence my recommendation to go with themes that are more or less finalized by the author. After a while, I completely understand if the original author may not want to help out.
Curious (but not curious enough to test myself) whether a plugin installed from the directory could be duplicated (and if not if we could add this as an option) to create a copy as expected but with the added benefit as being editable (seems like a good way to allow for opt-in editability).
When I began writing this reply I thought my biggest obstacle was trying to communicate the process of recreating the data/plugin_plugin_name/* structure inside a custom theme as data/plugin-plugin-name/* in order to provide plugin parameters (which persist for as long as the custom theme persists). Now I realize that the only way to view the data templates (in order to create custom copies) is by finding them in my READMEs.
Just the way you create a custom theme from a plugin theme, right? Yup. That would be great. Hence my preference is for having only one editable file per plugin that you could customize instead of several files per plugin.
Currently, even for the plugin themes, only the template you choose to edit shows up in the custom templates section so you know which one exactly you need to change in case of an update.
I wasn’t even thinking that, but that would totally work too. I was thinking how I open up my custom theme and hit duplicate to create a copy I can assign to the test blog and play with.
Update: I’m repeating myself, but what we are bumping up against is trying to label plugins as square blocks and themes as round blocks. In reality, both need to fit into the round hole.
Without limiting plugins to the provision of shortcodes, the distinction is arbitrary … and functionally limiting.
An example, with the Goldmark markdown parser, you can assign ids and classes within the markdown. This means that if I tossed a plugin at you that compiled the Bootstrap Sass library for you, you could totally use it from inside your Micro.blog posts. But, checkout that variables file that holds the default values meant for user customization, that sure as sh$t is not getting translated into the native plugin parameter interface.
Side note: I happen to use this library in my theme. I invoke the pieces I want as part of the Sass build, I’ve set my custom variable values, and my theme benefits greatly (even with my despising the class based styling and do not use a lick of it).
I built the way Micro.blog processes these before I knew about Hugo Bundles. Could be an opportunity to modernize the backend later.