Aristocles

Done. I added a new option to pause the front-end scanning (top of the settings in version 1.1.4.1), even though that’s the point of the plugin. Lol. I’m not sure how it could be considered intrusive? We’re not collecting any information from the users, and it’s running in the background after the page loads, so they don’t even know it’s there.

I should clarify that the 301 code only shows when it turns to good if it was previously flagged as a warning. 301 codes are considered good, so they won’t show up flagged at all. I will add options to change the types (warning, broken or good) for all status codes.

Could be that their server is blocking requests with a firewall or is just slow to respond. Maybe outdated cURL or some kind of conflict with their website. If you know it’s working, I would just omit it at this point.

Please update to version 1.1.4.

I added the field for user agent, as well as an option for marking the status code 0 as broken instead of a warning. This way you don’t have to hook into them. Hope that helps.

Even though there is a valid certificate, there are issues with it. You can see see them when running an SSL scan here: https://www.ssllabs.com/ssltest/analyze.html?d=www.saint-vincent-de-durfort.fr

Timeouts, even if they last forever, will always just time out and return an error code 0 when it gives up. If you want code 0 to return as broken rather than a warning, you can hook into the blnotifier_bad_status_codes filter and add 0 to it, and the blnotifier_warning_status_codes filter to remove 0 from it. Let me know if you need help implementing those.

And yes I can add a user agent field for you. ??

That’s because multiple redirects do not return a status code between the first and last one. If you increase the number of max redirects to 3 or above, you’ll see that your link shows 200 because that is the final status code. It actually redirects 3 times. So you’ll see a 301 on the first check (with max redirects at 0) and 200 on the last one (with max redirects at 3 or above), and 0 on all of the redirects in between. Does that make sense?

If it’s good, it will not show up on the results or will be removed if it’s on there from a previous check.

Yes, the HEAD method is the culprit and I cannot detect if it is a redirect if the site is returning a 404 status code.

As for the GET method, if you change the max redirects to 0, it will show the first status code (30x) instead of the end result (which is usually 200 or 404). Just know that if the page it is redirecting to doesn’t work, you won’t know since you are only capturing the first status code. Unfortunately I can’t show both unless I do two separate requests, which isn’t good for performance.

Note that I realized that the minimum max redirect value was set to 1 in version 1.1.3.7, so I updated that just now and pushed another update. You can update to 1.1.3.8 and then change the max redirects option in settings thereafter.

Here’s the thing. The HEAD method is similar to the GET method but does not retrieve the body of the response—only the headers are returned. Servers may treat HEAD requests differently, especially when redirecting. Some sites might not send a 302 (or other redirect status) for HEAD requests but may send a redirect for GET requests. In particular, not all servers may support HEAD requests the same way as GET requests, and this can lead to different status codes or behavior. The reason we are using the HEAD method by default is because it is faster and more efficient. Using GET loads the content body, thus providing more accurate status codes. If it’s too slow to use the GET method, you could alternatively omit the redirected links so they don’t keep returning false for you.

I’ll look into that and let you know. ??

Did you enable the “Allow Redirects” option in settings?

@ravanh I see the issue now and tested your link and also got a 404 error. Thank you for clarifying and providing an example. It wasn’t allowing redirects previously. I went ahead and added settings for allowing redirect and changing the max redirects if you want. I tested the link again and it’s returning a 200 status now. I left the max redirects set to 5.

Please update to version 1.1.3.6.

Basically it’s just changing the method from HEAD to GET, so essentially you could have used the hook I gave you in our other thread to do that, though we were looking at using it for a different purpose. I figured this is probably a common issue, so I made it easy an added a setting for it instead of having to hook into it.

Hope that helps! Let me know if you need anything else. Would love a review if you have a moment, too. ??

@ravanh That is correct.

// The request args
$http_request_args = apply_filters( 'blnotifier_http_request_args', [
? ? 'method' ? ? ?=> 'HEAD',
? ? 'timeout' ? ? => $timeout, // How long the connection should stay open in seconds. Default 5.
? ? 'redirection' => 5, // Number of allowed redirects. Not supported by all transports. Default 5.
? ? 'httpversion' => '1.1', // Version of the HTTP protocol to use. Accepts '1.0' and '1.1'. Default '1.1'.
? ? 'sslverify' ? => get_option( 'blnotifier_ssl_verify', true )
], $url );

timeout and sslverify can both be changed in the options. The reset is Hope that helps.

// Add a custom hook to modify the HTTP request arguments
add_filter( 'blnotifier_http_request_args', 'custom_blnotifier_http_request_args', 10, 2 );

/**
?* Custom function to modify HTTP request arguments.
?*
?* @param array ?$args The original HTTP request arguments.
?* @param string $url ?The URL being requested.
?* @return array Modified HTTP request arguments.
?*/

function custom_blnotifier_http_request_args( $args, $url ) {
? ? // Reduce the number of allowed redirects to 3
? ? $args[ 'redirection' ] = 3;

? ? // Update the HTTP version
? ? $args[ 'httpversion' ] = '1.0';

? ? // Update the User-Agent
? ? $args[ 'user-agent' ] = 'MyCustomUserAgent/1.0; https://example.com';

? ? return $args;
} // End custom_blnotifier_http_request_args()

See https://developer.www.ads-software.com/reference/classes/WP_Http/request/ for more info. There is an argument for user agent explained.

I’m not clear on your issue, though. Perhaps this isn’t the best fix for it. If you can elaborate a little, perhaps I can help. It would also be best if you meet me on Discord so we can just chat about it rather than waiting so long for a response here. Up to you, though.
https://discord.gg/3HnzNEJVnR

• This reply was modified 2 months, 2 weeks ago by Aristocles. Reason: Added additional helpful info

@ravanh The default User-Agent string will look something like this:

WordPress/6.x.x; https://yourdomain.com

This identifies the request as originating from WordPress and includes the site’s home URL. There is a hook that you can use to change this, which is why I say “default”.

@ravanh , The sites requested through the followed links might collect the server’s IP address and metadata typically transmitted in HTTP requests. This includes the request method (HEAD), headers such as User-Agent, Host, and Accept, and the requested URL itself. Our implementation does not send any user-specific data (e.g., cookies or session information). Additionally, we have configured the requests to minimize data sharing, and all interactions with third-party services are conducted server-to-server to protect user privacy. Does that answer your question?

@ravanh , Yes, it is fully compliant with European privacy and cookie laws. The plugin does not collect any personal data, use cookies, or store any user information. It simply checks the status of links on your website to determine if they are broken or not, without tracking or interacting with any external services. ??