I can't edit scientific products belonging to some categories. For example, products in the following category hidden link
For example, the following product hidden link
WPML support told me that there is a fatal error on your site while editing the custom CPT from Toolset Blocks.
[22-Jan-2023 14:53:11 UTC] PHP Fatal error: Uncaught InvalidArgumentException: Wrong value provided for the translation language. in /var/www/vhosts/targetanalysis.gr/staging1.targetanalysis.gr/wp-content/plugins/toolset-blocks/vendor/toolset/toolset-common/inc/m2m/DatabaseLayer/Version2/AssociationQuery/ElementSelector/AllLanguagesSelector.php:70
Stack trace:
#0 /var/www/vhosts/targetanalysis.gr/staging1.targetanalysis.gr/wp-content/plugins/toolset-blocks/vendor/toolset/toolset-common/inc/m2m/DatabaseLayer/Version2/AssociationQuery/ElementSelector/ElementSelectorProvider.php(193): OTGS\Toolset\Common\Relationships\DatabaseLayer\Version2\AssociationQuery\ElementSelector\AllLanguagesSelector->__construct(Object(OTGS\Toolset\Common\Relationships\DatabaseLayer\UniqueTableAlias), Object(OTGS\Toolset\Common\Relationships\DatabaseLayer\Version2\AssociationQuery\TableJoinManager), Object(wpdb), Object(OTGS\Toolset\Common\WPML\WpmlService), Object(OTGS\Toolset\Common\Relationships\DatabaseLayer\Version2\TableNames), Array, false, NULL, false, Array, Array)
#1 in /var/www/vhosts/targetanalysis.gr/staging1.targetanalysis.gr/wp-content/plugins/toolset-blocks/vendor/toolset/toolset-common/inc/m2m/DatabaseLayer/Version2/AssociationQuery/ElementSelector/AllLanguagesSelector.php on line 70
WPML support told me that the editing screen works correctly when deactivating Toolset Blocks and suggest to open a ticket for Toolset support to check it?
As the issue involves provoking fatal errors I took a copy of your site to work on locally where I can debug such errors more easily.
My local copy is a minimal install, meaning I only have the key plugins installed (Toolset and WPML), but in that case there are no errors, the edit screen loads normally.
So it looks like this may need some 3rd party code to reproduce the error.
Is it okay to work on the staging site, deactivating plugins and reactivating as required to try and narrow down what else is required? (It would be easier to keep track of that if I was able to delete the inactive plugins left over on your site.)
As you can see from the screenshot, the problem doesn't exist on the website hidden link. On this website, the WPML plugin isn't activated. Moreover, WPML support deactivated the Toolset and the problem was solved. So without WPML works and without Toolset works. However, you can do whatever you want on the staging1 website. I don't know if you could align with the WPML support as they have also access to it for some other problems.
I've identified the problem, it occurs with Toolset Blocks and WPML when the plugin Download Monitor is also active. Disable that plugin and the error doesn't occur, even when both Blocks and WPML are active.
I've confirmed the same happens on my local copy of your site, where I can look into this further to try and identify why.
Before I do that, though, can you just confirm that you do actually need all 3 plugins active on your site, and that the downloads plugin isn't just a relic of trying something out which you no longer need?
OK, I spent a good few hours on this, and have now had to pass it to the developers for them to investigate further.
I did identify what specifically triggers the issue. In case it is anything you can do something about, I don't think it relates to the category of Science Product posts that is the trigger for the problem, rather it is posts (such as amaZon speed) that include the download shortcode in the "Downloads" WYSIWYG custom field value.
That download shortcode gets parsed when the value of the WYSIWYG field is prepared, and—this is as far as I got—that somehow messes with the language setting for the page and ultimately triggers the error.
I'll let you know when I get some feedback from the developers.
I don't know exactly which posts have the problem and which not, but a key element is including the download shortcode in the Types wysiwyg field. If there is something else at play, too, that should be uncovered when the developer completes the debug work.
I'm pleased to say our developer has identified the problem, which arises because the Downloads Monitor plugin uses the WPML API incorrectly, and the issue you see with Types is a side effect of that.
We have submitted suggested changes to the Downloads Monitor plugin authors that will fix the problem.
In the meantime you can get a patched file from here: hidden link
Unzip that file and replace the file of the same name at plugins/downloads-monitor/src/Download/WordPressDownloadRepository.php
