[Resolved] Object of class WP_Block_Editor_Context could not be converted to string

[Author]

Posts

[johnM-37]

When a translator tries to edit a post they get the error message:

Fatal error: Uncaught Error: Object of class WP_Block_Editor_Context could not be converted to string in /home/sacredspace/admin.sacredspace.com/wp-content/plugins/types-access/application/models/wpml_settings.php:152 Stack trace: #0 /home/sacredspace/admin.sacredspace.com/wp-content/plugins/types-access/application/models/wpml_settings.php(560): OTGS\Toolset\Access\Models\WPMLSettings->get_language_by_post_id(Object(WP_Block_Editor_Context)) #1 /home/sacredspace/admin.sacredspace.com/wp-content/plugins/types-access/application/controllers/permissions_post_types.php(439): OTGS\Toolset\Access\Models\WPMLSettings->set_post_type_permissions_wpml(Array, Array, Array, Object(WP_User), Array, Array, Array) #2 /home/sacredspace/admin.sacredspace.com/wp-content/plugins/types-access/application/models/capabilities.php(644): OTGS\Toolset\Access\Controllers\PermissionsPostTypes->get_post_type_caps(Array, Array, Array, Object(WP_User), 'edit') #3 /home/sacredspace/admin.sacredspace.com/wp-content/plugins/types-access/application/controllers/filters/backend_filters.php(537): OTGS\Toolset\Access\Models\Capabilities->get_capabilities_by_user_permissions(Array, Array, Array, Object(WP_User)) #4 /home/sacredspace/admin.sacredspace.com/wp-includes/class-wp-hook.php(324): OTGS\Toolset\Access\Controllers\Filters\BackendFilters->toolset_access_has_cap_filter(Array, Array, Array, Object(WP_User)) #5 /home/sacredspace/admin.sacredspace.com/wp-includes/plugin.php(205): WP_Hook->apply_filters(Array, Array) #6 /home/sacredspace/admin.sacredspace.com/wp-includes/class-wp-user.php(813): apply_filters('user_has_cap', Array, Array, Array, Object(WP_User)) #7 /home/sacredspace/admin.sacredspace.com/wp-includes/capabilities.php(1018): WP_User->has_cap('edit_block_bind...', Object(WP_Block_Editor_Context)) #8 /home/sacredspace/admin.sacredspace.com/wp-includes/capabilities.php(911): user_can(Object(WP_User), 'edit_block_bind...', Object(WP_Block_Editor_Context)) #9 /home/sacredspace/admin.sacredspace.com/wp-includes/block-editor.php(652): current_user_can('edit_block_bind...', Object(WP_Block_Editor_Context)) #10 /home/sacredspace/admin.sacredspace.com/wp-admin/edit-form-blocks.php(314): get_block_editor_settings(Array, Object(WP_Block_Editor_Context)) #11 /home/sacredspace/admin.sacredspace.com/wp-admin/post.php(187): require('/home/sacredspa...') #12 {main} thrown in /home/sacredspace/admin.sacredspace.com/wp-content/plugins/types-access/application/models/wpml_settings.php on line 152

This happened after our site automatically updated to WordPress version 6.7 (I have since turned off automatic updates). Toolset and WPML are using the latest plugin versions.

If I try to edit the post as an administrator, it works and there is NO error message and I can translated without issue.

As a translator, if we view a post and then click the "Translate" button, it opens the WPML Advanced editor and works correctly.

So this kind of link [Edit link on posts view] "hidden link" causes the issue but this kind [Translate link on frontend view] "hidden link" does not cause an issue.

At the moment I cannot give access to the site or setup a staging site.

[Christopher Amirian]

Hi,

I wonder if you create a separate group for the translator in Toolset Access. If so, we have an issue that if the user is not administrator it is not possible to see the preview of the page.

Would you please test by deactivating Toolset Access and test? If it works, can you change the translator user to Administrator and see if it works?

Thanks.

[johnM-37]

Hi Christopher,

I did what you suggested and deactivated Toolset Access. I'm now getting a WordPress message "Sorry, you are not allowed to edit this item." instead of the error message. The message makes sense as the translators are just Subscribers. We cannot give them Admin level access.

We add translators as "Subscribers" and set their language in WPML. Then using Toolset Access we add the users WPML Groups for specific language/post type groups. We do this so that specific translators have the ability to access all the posts for their language so they can edit them etc.

We cannot have these translators with Admin access and that's why we are using Toolset Access. Is this no longer possible? Is there an alternative way to get the same setup?

Many thanks,
John

[Christopher Amirian]

Hi John,

I see what you mean, but unfortunately, WPML needs the Editor default WordPress user role as a minimum even if you use Toolset Access to add some roles.

Would you please test with the Editor role?

Thanks.

[johnM-37]

Hi Christopher,

Our issue is that our translators are all volunteers. I did as you asked and tested the Editor role. This gives volunteer translators the ability to edit the original English posts. We can't allow that level of access as most of them are not that tech savy and are highly lightly to edit the original English and replace it with translated text (this actually happened more than once during our initial testing).

We set up our volunteer translators as subscribers. This gave them the basic ability to translate WPML translation baskets. Our problem was that multiple different volunteers were translating for each language and there were issue like some would claim all posts in the translation basket and then not translate them while translators of that language couldn't translate anything.

Our solution was to use Toolset Access. This allowed us to add Subscribers to specific language/post type groups in Toolset Access. This gave the translators the ability to navigate to posts and translate those posts without being able to edit the original posts. This was working perfectly until WordPress 6.7. Is there any way around this? Why was it working before and now it's not working in WordPress 6.7+?

Many thanks,
John

[Christopher Amirian]

Hi John,

Thank you for the information.

I created a WordPress installation with WPML and Toolset. You can access here:

hidden link

I also created a user:

Username: test
Password: test

It is a Subscriber, also I added a WPML Group in Toolset access and assigned the user to it for Gemran language.

But I do not know what should i do to see the error so I can investigate. WOuld you please help?

I made sure the installation of WordPress is version 6.7

Thanks.

[johnM-37]

Hi Christopher,

This is very helpful. I made a few changes to the setup as the admin user to replicate our use case.

The goal is to have a "German" translator who can translate all German content, including view/edit German content already translated by other German translators. However, they should not be able to edit English or any other non-German content. That's what we were successfully using Toolset for up until WP 6.7.

I modified the Toolset > Access Control > WPML Groups > and added permissions for Publish, Delete and Edit (see screenshot).

I sent the "Hello World" post for translation to German and translated it as the "test" user. I then went to the "Posts" section as the test user, changed the language to "German" and clicked "Edit" and it worked!!! Using your site I can give a subscriber the ability to edit existing translations in their language without having the ability edit other languages.

So, there's something different in our setup than yours! I cannot see any difference in our WPML setup so I'll now go through all the Toolset settings you used. If I don't see anything there, I'll try setup a clone of our site as a staging site, try reinstall Toolset and then start disabling our plugins to try to find what's causing the issue.

Can you please leave the "mellow-drum" site live as a reference for me and I'll get back to you in a few days.

Many thanks,
John

[Christopher Amirian]

Hi John,

The sandbox website will be deleted automatically upon no activity for seven days.

So by simply logging in to the website using the link I provided in the previous reply, you will keep that website alive for 7 more days after the last log in.

Thanks.

[johnM-37]

Hi Christopher,

I've already found the issue. On the 21st of November Toolset released an update to the Toolset Access plugin (2.9.2). When I reported the issue (14th Nov) the latest version was 2.9.1. I noticed the difference in version numbers and after updating my site to 2.9.2 everything is working correctly again.

So no further action is required. Thank you for all your help finding that cause of this issue.

Many thanks,
John

[Christopher Amirian]

I'm glad that you managed to fix the issue John.