Website Rob

I look to forward to that time. I can then continue my testing with a Theme that has the potential for so much to offer.

My apologies for confusion as I forget to mention that I use the Query Monitor plugin (https://www.ads-software.com/plugins/query-monitor/). I find it so very handy for quick troubleshooting.

Query Monitor gives this Notice.
A non well formed numeric value encountered
wp-content/themes/responsive/functions.php:203
responsive_free_setup()
wp-includes/class-wp-hook.php:308
do_action('after_setup_theme')
wp-settings.php:595

By using it and logged into the Admin, not only does Query Monitor give me msgs., if I use Browser Dev Tools -> Console, I see “PHP Errors in Ajax response” msg. The number of msgs. vary according to which page I’m on, in the Admin area. Site Health gives the most at 7 msgs.

The Browser Dev Tools msgs. are not within my understanding and too much information to detail here. I would suggest you install Query Monitor to the msgs. for yourself.

As I don’t normally get these type msgs., that it why they stick out to me. I have learned to trust what Query Monitor tells me. I have found if it tells me a problem and I remove whatever is causing the problem, I have less problems in the future.

It was late, I was out of coffee and eyes were a little blurred. ??

After some sleep and thinking back on what I was doing, moving fast and breaking things, it all makes perfect sense now. A bit of commenting to myself in wp-config.php will make things easier to remember.

It’s actually a good way of preventing those who shouldn’t, from changing what ought to be.

Good fortunes to this plugin.

Looking at it in the light of day, I understand more thoroughly the logic and functionality of the option. Nice touch.

Problem was resolved using a Server level IP Tables rule. I have also seen where the Rest API plugin does show other Status then just 200.

So all is good. Although the plugin did not help with my particular problem, and not sure if it could have, some troubleshooting methods require a higher server level investigation.

All the best.

Further investigation showed the problem was created by some function not properly using allocated IP addresses. At what level is undetermined. Could have created by BLC, some other plugin, or even at a higher server level.

Problem was resolved using a Server level iptables rule.

So all is good now. I still recommend and continue to use the Broken Link Checker plugin.

Followed your instructions. Upon installing and activating, but no scanning with BLC, these errors were found.

HTTP Requests – upon installing
https://downloads.www.ads-software.com/plugin/broken-link-checker.1.11.21.zip.sig 404
https://downloads.www.ads-software.com/plugin/broken-link-checker.1.11.21.zip 200

Database – upon activation
error Illegal mix of collations for query UPDATE
error Illegal mix of collations for query INSERT INTO

Both had to do with (utf8mb4_unicode_520_ci,IMPLICIT) and (utf8mb4_unicode_ci,IMPLICIT) the ‘blc_synch’ table with ‘posts’ table.

The database errors were much, much longer and I shortened them to the most relevant info.

Still seeing this as well.

"cookies": [
{
"name": "broken-link-css-wrap",
"value": "0",
"expires": null,
"path": "/",
"domain": null,
"port": null,
"host_only": true
},

I agree this problem is a stumper and appreciate your help in trying to solve it. If this is where our troubleshooting ends then so be it. The Cookie will expire after a year and that will take BLC out of the picture, even if the problem remains.

The new errors, although they have no effect on the site, you might want to look into.

Using the dashboard, the plugin was deactivated then removed.

broken-link-css-wrap – cookie-cat is where I learned about the cookie and unless you say otherwise, I will take their information as being correct. The pluginarchive.com site had some posts about this exact issue but the site will not resolve.

Note that I tested similar setups with 2 other sites and could not duplicate this problem. During and after the BLC plugin being active, there was no call to broken-link-css-wrap. Why this is used on just the one site could be due to installing the plugin sometime during 2020. Don’t know what version it was then but it was being updated when new versions came out. Granting access to /wp-json/ dir. by IP address was instituted just recently which is when I became aware of this problem.

Please re-read the original post. The website does have access, it is the strange IP address that does not.

The blocked IP only shows when I use Site Health. As that is called by WordPress and from within the Domain name | allowed IP address – it is not being blocked. Every other call made by Site Health operates and records correctly as a 200 Status.

Another plugin I’m using, Log HTTP Requests, and when I use Site Health, it does record the call as a 403 Status but does not give me enough information. I was hoping the Rest API Log would record the Site Health call and provide more information but it is not.

I took the easy route of using another plugin, which is not causing the notices. Although it is possible the errors were caused by another plugin or hacker code inserted into the form, I just don’t have time to spend on solving the problem. Sorry.

• This reply was modified 1 year, 10 months ago by Website Rob.

Although your code would probably work, I have no idea what file to edit.

I was hoping that if it was possible, the next or future update of DWS would include the ability to manually insert a Log Location, such as the DWS Error log does.

I guess you did answer the question though.

Thanks

And that takes use back to the original post.

If Debug is enabled in wp-config.php then Site Health will say there is a problem – even if ‘debug.log’ is protected by other means or stored somewhere else. So then, as outlined in original post, is it possible to recode DWS Debug to use a custom path, similar to the same option as the DWS Error Log?

Create /wp-content/debug.log and enable Debug in in DWS.

DWS reports no problem nor does Site Health but is Debug actually working? I don’t know. Will debug within DWS work without having to enable it in wp-config.php?

WP Docs say debug must be enabled in wp-config.php it order to work and once that is done Site Health says: The value, WP_DEBUG_LOG, has been added to this website’s configuration file. This means any errors on the site will be written to a file which is potentially available to all users.

My apologies or good job on your part – not sure which. ??

I’ve just been doing some testing with the new Responsive v4.7.9 and between the new Theme version and my testing, I do believe I’ve narrowed the problem down to one Plugin.

I’m using Meow Gallery 4.3.0 (https://www.ads-software.com/plugins/meow-gallery/). It seems that whenever I create a Meow Gallery on a page, the above two errors first mentioned, will be triggered on the back-end (when Gallery first created or edited) and the front-end (every time the page is viewed). If I use the Gutenberg built-in|default Gallery, no problem on either side.

I will mark this resolved as there is definitely a conflict between the two and I have yet to try Responsive Theme with another Gallery plugin. If I run into the same problem with another Gallery plugin, then we’ll have something further to talk about.

Be well and keep up the good work.

The steps I took were to install the Theme and test it out by loading pages. No screenshots necessary.

As I monitor my error logs on a daily basis, the notices kept showing up and it just got to a point where it was easier to remove the Theme then to keep cleaning the error log.

It’s possible there is a conflict with other things I’ve installed. The notices stopped showing up though when the Theme was removed and other Themes do not give the above notices nor do anything else I’ve installed.

I wonder if your testing showed any notices repeating in your error log?