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).
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.