short circuit "QTX_Admin_Gutenberg"

[picasso]

apply filter to short circuit the Admin handler for Gutenberg.
It is very necessary if you implement your processing for the Gutenberg Block Editor and the related REST API.
Otherwise, you have to remove each filter and the action separately and sometimes with hacks...

[herrvigg]

If you need to disable all the QTX functionalities for Gutenberg, there's a better way.
The instance should not be created so the filter call should be done in qtx_admin_gutenberg.php before requiring the file.

[picasso]

The instance should not be created so the filter call should be done in qtx_admin_gutenberg.php before requiring the file.

I wanted to do so. But who guarantees that at the time of creating an instance this filter will be already added? There is no guarantee that even a plugin that wants to do it is already loaded (QTX can be loaded before it). That is why I did it that way.

[herrvigg]

Right, I see. Currently the instance is created from qtranxf_init_language() that is triggered on plugins_loaded with a high priority (2). So at this point we normally know which plugin is loaded technically, but they may not have set their filters yet.

One solution could be to delay the creation of this object, because it's only dependent on rest_api_init and enqueue_block_editor_assets which are fired much later, after init and even after wp_loaded. But that could compromise future evolutions if we'd need to setup new hooks earlier.

Another way could be to have a user option to disable the whole Gutenberg functionality. But I'm not sure it's better.

[herrvigg]

A third possibility would be to give the possibility to delete the object later instead of keeping it alive but having to check an external state in every function. Perhaps that would be a cleaner way to remove all filters. The cleanup would be done in the destructor.

[picasso]

Another way could be to have a user option to disable the whole Gutenberg functionality. But I'm not sure it's better.

yes, but hardly users will disable it. It is necessary to developers and third-party plugins. Therefore, my option is simple and will work with any future evolutions. Although not so elegant.

[herrvigg]

Why do you need to disable these filters? Is it related to #1097 and https://github.com/picasso/zu-translate?

[picasso]

Why do you need to disable these filters? Is it related to #1097

yes, I need to re-implement the support for Gutenberg and the current implementation interferes to me.

[picasso]

A third possibility would be to give the possibility to delete the object later

The object is so small that it makes no sense to optimize this process too much. Let it stay in memory, this is a small loss (IMHO)

[herrvigg]

The idea of the object was to facilitate the deactivation of the filters (in the destructor), but this doesn't matter much.
I'm still thinking how to avoid the filter, but it looks like the most reliable solution. "Gutenberg" was more of a code name for the Block editor project. We could rename the filter qtranslate_block_editor. I can send a patch.

[picasso]

We could rename the filter qtranslate_block_editor. I can send a patch.

Wait a bit. I began to make changes to my plugin because I have to return the functionality of the previous QTranslate to work with WooCommerce, as they do not support the "Gutenberg". And therefore it is necessary that part of the pages under the post.php worked as before. Therefore, we definitely cannot delete the object completely and can disable it or enable at the moment when it becomes known post_type ... and this happens quite late.
I will finish my tests and write more.

[picasso]

My research has shown that post_type is only available after the current_screen action. In addition, there are situations when we need to disable script loading, but leave REST processing (for example, rest_request_after_callbacks). Therefore, it is possible to divide the "Gutenberg" support into two blocks:

• script enqueue and rest_prepare
• REST modifications (rest_request_before_callbacks and rest_request_after_callbacks)

But in the current situation, I managed with one filter. You can add 2 filters for the future, or you can make one filter and wait for the situation when someone needs 2 filters.

I suggest calling the filter qtranslate_sl_block_editor (Single Language edit mode)

[herrvigg]

I've renamed to qtranslate_admin_block_editor to match the current need.
I've inverted the boolean to signify "let QTX administrate the block editor". Therefore it becomes true by default and you should set it to false in your case.
Does it sound good?

[picasso]

Does it sound good?

Yes, it is quite suitable. I will change my logic from true to false