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.
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.
The “style.css” template can sometimes have a different name, depending on the theme. For example, in Primrose it’s called “global.css”, or at least that’s the only “.css” template in the plug-in.
(A note for the note: I hope one day Micro.blog themes will no longer have these types of discrepancies; it can be discouraging for non-developers.)
There’s an exception for your own plug-ins, because it can be useful to edit them while developing. But other people shouldn’t have the option to edit them without creating a custom theme.
It’s possible this still needs to be refined, so let me know if anything looks wrong.
I built the way Micro.blog processes these before I knew about Hugo Bundles. Could be an opportunity to modernize the backend later.