I was trying to edit two recent posts, but the edit page was blank. I asked my host to investigate and they replied:
"Hello Mike,
Thanks for getting in touch.
I have disabled the following plugin:
Plugin: toolset-blocks
On checking the error logs, this was generating over 100 PHP errors, I installed the query monitor plugin to assist with this, this is the main error:
Return type of OTGS\Toolset\Common\Utils\RecursiveDotFilterIterator::accept() should either be compatible with FilterIterator::accept(): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
If this plugin is required you would need to reach out to the plugin developers to assist with the error noted above, just now this is disabled and the posts can now be edited.
Kind regards,
Steven"
I have reactivated the Toolset plugin, because otherwise none of the content I have been working on (see here hidden link can be seen).
Further to the above, I have had to deactivate the blocks plugin because it was creating error messages on a live post that was published yesterday. I then also had to put the last two posts AND a page containing content I have been working on for weeks, into draft mode because anything relying on Toolset either was not available or simply appeared as meaningless code.
I am not happy and look forward to hearing from you.
I note that you have upgraded to WordPress 6.5; did the problems only began after that update?
We are aware of a couple of issues relating to this and should have a fix for those soon, but your issues sound different.
I think the most expeditious way to investigate the issue and identify the cause would be to take a copy of your site to work on locally for testing. Would that be possible?
Let me mark your next reply as private so that we can get log-in credentials from you—you may want to create a temporary admin user for us to use that you can later delete. And be sure to have a current backup of your site.
Can you also confirm the urls where you are experiencing problems?
(In the meantime it might make sense to downgrade WordPress to 6.4.4 using the WP Downgrade plugin so that you can have the content on your site available as normal, assuming that the issue did arise when upgrading to 6.5.)
Without access to your site there isn't a great deal I can do.
Ordinarily I would request you run through some basic debugging steps on your staging server, but given that the problem is affecting your production site I'm guessing you don't have one, or at least didn't test updates on a staging server before pushing to production.
If you don't want to make a copy of your site available I can wait for you to prepare a staging server and I can give you steps to follow there to help isolate the problem.
I'm offering to take a copy of your site to make the process faster. And that would involve me logging in to the back end of your site, installing a plugin to make the copy, then removing the plugin. I wouldn't be making any other changes to your site.
Let me know how you'd prefer to proceed.
I'll set another private reply in case you want to share credentials to log in to your site.
Hi Nigel
You did not see or read my reply? I said:
Reverting to the previous version did occur to me, but I don't know how to do it. You say there is a plugin for it?
I'm happy to provide access to the site for you, but have never done this before. Can you tell me exactly what you need?
I have no idea what a staging site is.
I have actually been hanging around all morning so that this issue can be resolved as soon as possible. Please let me know by return EXACTLY what you need me to do. I will wait for 30 minutes then I need to go out for about half an hour.
Regards
Mike
When I set a private reply it has sections for you to provide the username and password for an administrator user so that I can log in to the back end of your site.
I just need you to provide those and then I'll take a copy of the site, nothing else.
The template also asks for FTP details, but I don't need those, you can put some dummy text in those fields.
Sorry Mike, but I don't have anything very helpful to share.
On the local copy of your site I'm not experiencing problems editing the posts and page you referred to.
And there are none of the errors reported by the other support which you detailed in your original post.
Which suggests that the problems may be linked to your server environment.
So I will need a staging server after all.
If you are not familiar with creating one, you can ask your host to do that for you. (It is very rare for hosting plans not to include a staging server nowadays. It is a copy of your production site, but at a different, temporary URL, and can be used for testing plugin and WordPress upgrades amongst other things to check if they are safe to run on the production server.)
We can then confirm the particular circumstances that are required to produce the problems when editing those pages.
A staging server will have a different URL, so let me set a private reply again to get the details
Thanks Nigel
I will contact Krystal and get back to you ASAP. As you know, I am away tomorrow. Meanwhile, I have reactivated the Toolset plugin and this page:
hidden link
and these posts
hidden link
hidden link
seem to be fine so far.
However, the Query Monitor plugin, which Krystal installed yesterday, is showing these errors:
Return type of OTGS\Toolset\Common\Utils\RecursiveDotFilterIterator::accept() should either be compatible with FilterIterator::accept(): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
wp-content/plugins/toolset-blocks/vendor/toolset/toolset-common/inc/autoloaded/utils/PhpIteratorFactory.php:45
Warning Attempt to read property "post_type" on int
wp-content/plugins/toolset-blocks/application/controllers/compatibility/wpa-block-editor/wpa-block-editor.php:220
4 Plugin: toolset-blocks
Warning Attempt to read property "ID" on int
wp-content/plugins/toolset-blocks/vendor/toolset/toolset-theme-settings/compatibility-modules/controllers/toolset-theme-integration-settings-front-end-controller.php:64
81 Plugin: toolset-blocks
Deprecated Return type of OTGS\Toolset\Common\Utils\RecursiveDotFilterIterator::accept() should either be compatible with FilterIterator::accept(): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
Yes, but they don't show on my local copy of your site.
That's why I need a staging server to be able to investigate in the same environment as your production server. (I don't want to run tests on your production server.)
PHP deprecation notices have no effect on the site functionality (they indicate something could break in the future). PHP Warnings may point to a problem, but they are not errors.
I'll know more when I can check the staging server.
I'll set the private reply again so you have the option in your next reply to share its credentials.
Nigel, currently, Krystal have declined to help. All they have done is sent me a link to a document about creating a staging site, which I don't begin to understand - and I am due to go away this morning. I have asked them again.
Meanwhile, I was getting multiple error messages similar to this:
Warning: Attempt to read property "ID" on int in /home/bitabout/public_html/wp-content/plugins/toolset-blocks/vendor/toolset/toolset-theme-settings/compatibility-modules/controllers/toolset-theme-integration-settings-front-end-controller.php on line 64
class="ast-related-post post-25724 post type-post status-publish format-standard has-post-thumbnail hentry category-british-stuff category-history tag-curious tag-events tag-history tag-stuff">
at the bottom of every post on the website. I have deactivated the Toolset blocks plugin, which seems to be causing the problem, and have also had to switch two recent posts linked to Toolset AND a page showcasing custom posts created with Toolset, until the problem is sorted.
I have again asked Krystal for help. As you know, I am due to go away today and, frankly, am tearing my hair out.
If those warnings appear on your site that is because WordPress debugging is turned on and set to output errors and warnings to the screen (rather than to a text file on the server that you can review).
I took the liberty of logging back in to your site to edit the wp-config.php file to disable this debug mode to prevent such messages being displayed on the site. (For your information, the file was last edited on April 16. Perhaps Krystal support edited it and turned on debugging? As well as adding and leaving active the Query Monitor plugin. I would expect support to clean up after themselves.)
While there I noticed you seem to have installed all Toolset plugins by default, including a couple that you are certainly not using, nor are likely to. I deleted those, and also disabled the Toolset Forms plugin, which you are not currently using, but perhaps might.
I have left Toolset Blocks inactive.
As mentioned before, I suspect that reverting to WP 6.4.4 would prevent the problems from occurring, though I don't know for sure.
If you are not comfortable doing that and would like me to do it for you let me know. I understand that you have nightly backups if something goes wrong.
Dear Nigel
Thank you.
To date, Krystal support have been really good. I'm disappointed with their reaction to my request for help, as well as the point you raise, above, and will take that up with them once full functionality has been restored.
If the error codes are no longer appearing on the website, is it safe to restore Toolset blocks and the content I have switched to draft mode?
I looked at reverting to an earlier version of WP and the warning signs put me off doing it. If you can do it without crashing the site, please go for it.
However, the core issue seems to be incompatibility between Toolset and WP. Any news when that will be resolved?
I will get back to you if/when I hear from Krystal. I have delayed my departure for an hour or so - my wife is being very patient!
Regarding the incompatibility between Toolset Blocks and WordPress, I don't know exactly what the problem is, because I don't see the issue on my local copy of the site, which is why I requested a staging server.
If you tell me that you have a current backup and you know how to restore it if something goes wrong, then why don't I revert to WP 6.4.4 right now to see if that helps, and you have time before you leave to re-active and publish content as needed, or—worst case—restore the backup.
