An option to create and save a Code Block "Template"

[Shepdesign]

It would be nice to be able to create saved templates for code blocks. For example, to be able to add all the main settings we want like size, spacing, theme color, etc. then save that template and have it apply to every code block that gets placed in Gutenberg.

Maybe they can also have an option to import/export templates as well.

[KevinBatdorf]

Great feedback! Thank you. I was going to work on something like that this weekend, actually, so it's a good signal someone else felt the same.

I have two questions though:

1. Would you expect the language to be in there? Maybe only optionally? I'm thinking of not including it since you might be using multiple languages with a similar configuration. OR I might include the language since it's common you actually want your Python and PHP code to de distinct (and if not you can just have two similar profiles anyway)
2. I was going to label them as "theme profiles", so maybe I'm thinking of something different. When you think about exporting, what specifically do you expect to do there? Import it later to another site? It would really only be about 10 configuration options so do you think that might not be super useful? Or do you have another idea?

[Shepdesign]

Awesome!

1. I was thinking of having the languages as optional to save or not. The templating would be more of saving the actual styles and settings of the code block. So basically every time I hop in Gutenberg to make a post, I can choose my main code block template that I've been using for every post, then throw in the specific language and code. Some blocks on the same post might have HTML while others have CSS, but the "skins" of the block would be the same. The design characteristics of the blocks - colors, font, spacing, etc. If that makes more sense.
2. With the export I was thinking to other sites. But now that I'm thinking about it, nobody probably needs that. I could possibly use it maybe like once going from one client to another, but it honestly probably wouldn't be utilized that often. We can keep that one out haha.

[KevinBatdorf]

So basically every time I hop in Gutenberg to make a post, I can choose my main code block template that I've been using for every post

Well you could do this today actually.

1. Create the config you want then save as a reusable pattern

2. Name it something

3. Type it in here:

--

Instead I'll probably make something in a dropdown that will let you quickly swap around after the fact. Similar to how you select a theme today.

[Shepdesign]

Sweet! I didn't know that. That is essentially what I was requesting. That is perfect. Thanks!

[antrys]

But does that not update the code block contents across all posts? I've had to convert to regular block before editing, and learned the hard way when I erased my code blocks in other posts because I forgot to convert.

[KevinBatdorf]

That's correct. Each block would need to be updated one by one. The reason is it uses the VS Code engine to pre-process the tokens in the code in the browser's webassembly runtime (it happens in real time as you type). It can't process them outside of the browser, so updating a setting in one place wouldn't be able to process every other block on the page. It's just not possible.

The trade off here is the blocks are pre-rendered as you type, that's in contrast to other plugins that render on the server or frontend right when the user requests the page. Speed/performance vs not having a global setting.

I'm working on a solution to let people re-render them in a more efficient way through an admin page that loads everything in and processes them, but it's not ready yet, and I need to be careful how it operates.

[sandmmakers]

Having the ability to set defaults for 1) theme, 2) header type, 3) footer type, 4) copy button icon, 5) font styling, 6) max height, 7) disable padding, 8) tab settings, 9) line numbers, and 10) additional CSS classes would make this plugin significantly more practical to use for a code snippet heavy website. The rest of the settings could reasonably be expected to change per instance, so defaults make less sense.

If there was a batch reprocessing feature, the ability to "override a default" would be needed, since some settings might need to be occasionally overridden (like the header, I generally have 50% with a title and 50% without).