Hey thanks for the report. They may have added a new method I need to account for. I’ll investigate later and see if I can write a test to make sure I can catch that scenario early if it change something again.
Did you end up trying this plugin? Would love to hear what your thoughts are and if there’s anything you feel is missing.
Hey Kevin,
Pardon me jumping in here.. I saw this:
“Compatibility: Disable Prismatic. They use an encoding function on all code indiscriminately, breaking this plugin.”
That implies there is some way to “discriminately” encode snippets. In which way should code be differentiated in order to work with your plugin?
I want to make Prismatic as widely compatible as possible.
Thank you.
Hey Jeff,
Thanks for chiming in. As you know, Prismatic filters every block of <code> encountered regardless of the content source. In the world of Gutenberg, a more idiomatic approach would be to filter the core code block directly with a custom attribute you can check for later when transforming. Or add a “Prismatic block” that extends the core block.
Since you want to support non-Gutenberg pages, you would then need to approach your filter method with something like “transform all code blocks that are not within Gutenberg, unless the Gutenberg code blocks have our attribute identifier.”
Another option would be for Prismatic to look for something to ignore filtering, like whether a <code> block contains the class “prismatic-ignore” and skip those entirely. I could then detect the presence of Prismatic and apply the class for those users who want to keep both options, (even better if you let developers filter the classname so I could just add my own custom one).
add_filter('prismatic_ignore_class', fn () => 'my-code-block');
The way I’ve handled it now though is to just override your class methods so that if the user wants to try out this plugin, nothing will break and everything will go back to normal if they choose to not use it. This works, but just requires me to monitor for method updates you might add. I’ve set up an automated test for that though so that’s a non issue after today. However, the user would see unformatted code blocks during that evaluation period, and if they did end up wanting to use both plugins, they wouldn’t be able to.
Here’s where I’m handling the override and I added some context there: https://plugins.trac.ww.wp.xz.cn/browser/code-block-pro/trunk/php/compatibility.php
@worldsdream I just pushed an update that should resolve this if you want to give it another shot. I really appreciate the feedback! Thanks again.
Kevin, thanks for the information. I like the idea of the filterable class and will take a closer look for the next plugin update. Hopefully can improve compatibility and make your life a little easier as well.
Thanks Jeff, I appreciate it.
@kbat82 I updated the plugin to v1.9.2.
There is no error anymore.
But, the prismatic plugin is not completely deactivated because it shows as “activated” in the plugin section.
Shouldn’t it be disabled over there?
I can confirm that the prismatic blocks are disabled in the back-end editor and front-end.
Back-end shows:
Your site doesn’t include support for the Prismatic block. You can try installing the block, convert it to a Custom HTML block, or remove it entirely.
Now just like you said, it’s best if we can enable the Code Block Pro plugin and still have prismatic plugin working.
That way, we can test out both plugins.
Did you end up trying this plugin? Would love to hear what your thoughts are and if there’s anything you feel is missing.
You mean the prismatic plugin?
I meant whether you were albe to evaluate my plugin. Just curious if you have any feedback.
I actually didn’t realize there was a prismatic block. I’ll look into that. Currently I’m just disabling functionality and not the prismatic plugin itself. That way you can evaluate mine and decide. I agree having both work would be ideal. That should be possible soon-ish.
Jeff mentioned above adding a solution That would allow developers to disable a specific feature of Prismatic that conflicts. That should allow both to work. I’ll update this plugin then, but can’t say when specifically.
Your plugin is excellent.
The only thing that I am afraid of is that there is not a default setting where you can adjust it for every code block.
Let’s say you have 100 code blocks on 100 pages and you want to change them in the future.
You need to go through them all.
If you can configure it with a couple of clicks and it changes everywhere, is easier.
Just figuring out what will work best..
Yeah, that’s a downside with pre-rendering. Changing an editor theme globally would require updating every page. Do you change your code theme that often?
Let’s say you have 100 code blocks on 100 pages and you want to change them in the future.
You need to go through them all.
This is good feedback, thanks. I could include a UI to update them all. It would need to load in every page from the database and parse each one. I’ll add that to the TODO list. Would be fun to make.
