Closed ginsterbusch closed 1 year ago
Hi, thanks for flagging. So ClassicPress does include the function register_block_type
but doesn't support blocks? Interesting but ok. I'll add the check.
Its using a compatiblity layer / polyfill which replaces the class (and thus functions, as WP is internally using OOP with wrapper functions because .. "we did it before so we do it now"), but which returns FALSE on any actual call.
Here's copy + paste from the class-wp-compat.php file (wp-includes/classicpress):
if ( ! function_exists( 'register_block_type' ) ) {
/**
* Polyfill for block functions.
*
* @since CP-2.0.0
*
* @return bool False.
*/
function register_block_type( ...$args ) {
WP_Compat::using_block_function();
return false;
}
}
hence the additional check, which relies on the testing of the existence of the function classicpress_version
found in wp-includes/version.php (where also $cp_version etc. resides).
For further reference, you can look it up yourself at https://github.com/ClassyBot/ClassicPress-v2-nightly/releases for the actual release file ... or in the source (happy digging) at https://github.com/ClassicPress/ClassicPress-v2
cu, w0lf.
Ok, thanks. I am not opposed to adding this workaround, to me register_block_type
is an indicator that the Gutenberg plugin is or WordPress > 5.0 is installed. Surely there are other reasons for ClassicPress to add the polyfill but to me this behavior appears a bit unintuitive.
The plugin, despite it is stated as also allowing "for Classic Editor", is broken in ClassicPress v2, because it assumes there IS a working block editor, when there isnt.
A quick workaround is to add a test a la
!function_exists( 'classicpress_version')
to the method register_hooks in includes/class-blocks.php, like this:Adding a similar test to the settings area, specifically for the "blocks_everywhere" part, should help avoiding confusion and potential other errors.
cu, w0lf.