Hi @josklever
Thank you for response!
I think we got to the point when we know what’s happening and I’m extremely thankful for you that what started as a support ticket kind of turned out into an extensive troubleshooting cooperation.
This is a huge help for us in making plugin better and uncovered a very important issue.
At this point, however, we’ll need to take another turn I’m afraid.
The first thing is that we know now that somehow there’s Astra doing “something” that turns the global post variable from object to integer variable. I’m honestly not sure if this is intentional or not as even though I tried to briefly analyze their code, I didn’t find exact reason for this. Quite likely I just missed something but on the other hand it’s a huge complex code that I’m not familiar inside-out with. Yet, it doesn’t sound quite “right” to me to manipulate post variable that way. I mean – not the global one. It’s fine to do anything with local (or private – as in private class) variable but not global that is crucial part of WordPress core. Perhaps that’s actually the issue on theme end – that somehow what wasn’t meant to be global just “accidentally leaked” to be global. But that’s a guess.
One way or another, that’s something they should take care of as, as you already noticed, it may cause issues with other plugins too.
It’s reasonable for any plugin to expect that what is supposed to be a global variable containing certain type of data (post object in this case) will contain that kind of data.
But then the second thing comes to play which would be our code. You are right, we should be doing the type check at this point and, in this context, it is to some degree PHP 8 compatibility issue on our end. PHP 8 introduced way more strict error checking. While in BLC the fact that we get a number there instead of object simply causes those related posts on a given page not to be checked and that’s it. They’d still be checked as regular posts anyway. So functionally it doesn’t change much. The difference is that with PHP 8 issue would be reported because of that type difference of post variable. With previous PHP version it may not be reported with typical error reporting configuration in PHP.
However, this is very specific case and it’s as far as we can go with this. Current version of Broken Link Checker won’t really be further developed and is only kept at the minimum maintenance level.
Instead our developers are working an a completely new version of the plugin. I’m aware that this was mentioned here and there for quite a long time already but it was a really huge work and will change the way plugin works (technically speaking) completely. In fact, it will make this kind of compatibility issues completely irrelevant as the plugin will literally skan and analyze actual rendered front-end content of the site.
Thank you again for all the testing, feedback and cooperation with this. I’ll make sure that our developers are made aware of this case. As for the fix, we’ll need to wait for the new major release of Broken Link Checker (unless Astra fixes the issue on their end) as due to how it will work, it will sort this kind of compatibility issues automatically.
Kind regards,
Adam
