Add site wide configuration processing

[KevinBatdorf]

Want to list out some goals and thoughts on adding a global approach to converting and processing code blocks.

Here's what I want to solve for with a global approach to managing Code Block Pro (CBP) blocks

1. Easily convert to and from CBP blocks <-> core code blocks (unprocessed code). The raw code is stored with the processed code, so this is definitely possible
2. Be able to apply specific changes to either specific CBP blocks or all CBP blocks. Right now you must do them one by one
3. Save common configs. This is related in that these configs could apply to the above when doing conversions.

Challenges

The way the CBP works is it uses shiki, which uses the same webassembly engine that VS Code uses (oniguruma + textmate) to tokenize and colorize the code. This happens so fast that you don't notice it happening as you type. This is unlike other solutions that process the code on page load on the front end.

The tradeoff is that this pre-processed code is stored in the database. So when you want to someday change your color scheme, or you want to remove your data from your WordPress site all together, you have to go and manually convert every CBP block one by one. That's annoying.

Solutions

Create an admin page that will let users load in every page that has a CBP block (or non-CBP block if converting to one), and will:

1. Parse the block
2. Process the block
3. Persist back to the database

The main challenge here will be presenting the interface in a useful way, and ensuring any changes are recoverable. Here are some notes on that:

• Let users scope the query to whatever degree they need to. For example, by language, current theme, specific post type, pages, etc
• Show a preview (side by side?) of each block and the change before asking them to persist the change. Also let them preview the post in entirely.
• Process them in a clear way one by one, and let the user cancel. Make the expectations clear and allow them to visualize them both before and during the change
• Handle errors, for example from edit_lock, processing errors, maybe bad data, etc
• Monitor memory and prevent over usage (might require not using the WP Preview component, for example)
• Confirm the post content outside of the code block remained untouched. i.e. bail if something seems wrong with the post after

This is an important feature for the future of the plugin so I want to make sure I get it right. Here are some of the principles I will follow when developing and rolling this out:

• Expectations should be clear (It should feel safe to run)
• It should be recoverable (check/compare before and after just before persist)
• There should be zero lock in
• Minimize technical debt - don't lock in features too early

I may edit to this list over time. Also, this of course would be a free tool.

[worldsdream]

@KevinBatdorf You're the best. A dev that really cares about his product and the users. You don't see many people like you anymore in this world. Thanks.

[peignit]

Be able to apply specific changes to either specific CBP blocks or all CBP blocks
Save common configs

I believe this should be the absolute priority, as setting config for each and every code block is tiresome. I have a name suggestion "Profiles" just like how vscode has profile for managing different config/setup. maybe in future uses can import their vscode configs too.

For future or for the pro/premium version of the plugin you can store the code block content in custom table just like shared blocks which will make the sharing code between editors easier and also helps with listing all code blocks in one place for bulk updates on style changes/moderation.

I'm not good with good with react/js but i'll try to see if I can do a prototype for global configs/profiles.

p.s. thanks for such an amazing plugin

[technoogies]

global approach to managing Code Block Pro (CBP) blocks

Yep, I was just testing your plugin and I was looking for this. It'll be a big time saver.

1. Global CSS support.
2. Customized support for each code type.
   Font size, font type, and theme.
3. Customize the line number appearance and alignment
4. Line seperation, ruled lines or not.

Super cool what you have here.

~ Smaller thumbs for theme selection on the panel, or maybe a setting option for smaller or none.

[KevinBatdorf]

Global CSS support.

This can't really exist in a perfect form because the tokens are dependent on the theme+language. Every theme has specific tokens that define what colors go where. There's a basic "CSS Vars" theme included in the theme pack, but that is also limited as it just tries to make a generic theme (so it's likely to not look as good as pre-built ones). I wrote a bit about it here: #168

In the coming months I'm going to rewrite a big chunk of the plugin to better support css variables at the individual theme level, but it's going to have breaking changes and I'm unsure how to provide a graceful upgrade path. WordPress itself isn't designed to support complex breaking changes, or mass updates to static blocks. I may just have to include a new block and provide the option to disable the old one