If no, I created a clean installation of WordPress, Toolset and GiveWP. I'd appreciate it if you replicate the issue there and give us the steps to check ourselves:
- Access your website files via FTP.
- Go to this file: wp-content/plugins/toolset-blocks/backend/Services/ViewParsingService.php
- Change the function scan_for_view_before_deletion on line 213.
- Change this:
- Access your website files via FTP.
- Go to this file: wp-content/plugins/toolset-blocks/backend/Services/ViewParsingService.php
- Change the function scan_for_view_before_deletion on line 213.
- Change this:
Yes, that does fix the issue on the test site. I need this fix on several client sites so I'll wait for the official toolset blocks update for the live sites.
Thanks. As there is no set date at the moment for the future release we suggest that you follow the workaround for now to avoid interruption on your current workflow.
I wanted to share some feedback with you from the developers. They have marked the ticket as won't fix, as the issue arises in the GiveWP codebase, whereby they use a core WordPress filter to modify the behaviour of the core get_post_meta function such that it returns an empty string rather than false, as documented by WordPress itself.
Our developers decided not to modify our code to catch possible scenarios where other plugins break core WordPress behaviour.
We reported our findings to GiveWP authors who will look into it as part of their work on PHP 8 compatibility (with prior PHP versions it would have produced nothing more than a warning), but I don't know when that will translate into an update.
You can keep using the workaround shared above in the meantime, but bear in mind that if you update Blocks it will overwrite the changes.
Thanks Nigel. Hopefully GiveWP will fix this before Toolset Blocks needs an update. I have a good relationship with the team at GiveWP so I'll contact them and see if I can get some priority on this issue.