False positives of this kind (i.e. all internal links being flagged as broken) are usually caused by server configuration problems. For example, maybe loopback connections are not configured correctly. Try asking your hosting provider if scripts running on the server are allowed/able to connect back to the same server.
Thanks for your quick answer !
This website in on the same saver than another one who works well. Could it be a problem with htaccess ?
Possibly. Do you have any custom rules in your .htaccess?
Hello
Here is my htaccess. Do you see something in there ?
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^http\:\/\/lapalys.ca [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
RewriteCond %{HTTP_HOST} ^hfda\.lapalys\.ca
RewriteRule ^/?$ “http\:\/\/www\.lapalys\.ca\/wiki\/index\.php\?title\=Accueil_HFDA” [R=301,L]
No, I’m afraid not. The .htaccess looks fine. None of those rewrite rules look like they would interfere with BLC.
Lets try a different angle: in the “details” panel, does the plugin show the right “final URL”?
Hmm, I see.
Well, try the development version of the plugin. In addition to response headers, it will also display the HTML content it received from the server. Maybe the contents of the error page(s) will provide some clues.
Same problem. Here is the error for a picture :
Journal: === Code HTTP: 404 ===
Response headers
================
HTTP/1.1 404 Not Found
Date: Sun, 15 Feb 2015 15:57:49 GMT
Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/1.0.0-fips mod_bwlimited/1.4 mod_fcgid/2.3.6
Accept-Ranges: bytes
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
Request headers
================
GET /wp-content/uploads/2014/07/4-Infos.png HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: http://www.lapalys.ca
Accept: */*
Referer: http://www.lapalys.ca
Connection: close
Range: bytes=0-2048
Response HTML
================
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html>
<head>
<title>404 Not Found</title>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
<style type=”text/css”>
body {
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 12px;
background-color:#367E8E;
scrollbar-base-color: #005B70;
scrollbar-arrow-color: #F3960B;
scrollbar-DarkShadow-Color: #000000;
color: #FFFFFF;
margin:0;
}
a { color:#021f25; text-decoration:none}
h1 {
font-size: 18px;
color: #FB9802;
padding-bottom: 10px;
background-image: url(sys_cpanel/images/bottombody.jpg);
background-repeat: repeat-x;
padding:5px 0 10px 15px;
margin:0;
}
#body-content p {
padding-left: 25px;
padding-right: 25px;
line-height: 18px;
padding-top: 5px;
padding-bottom: 5px;
}
h2 {
font-size: 14px;
font-weight: bold;
color: #FF9900;
padding-left: 15px;
}
</style>
</head>
<body>
<div id=”body-content”>
<!– start content–>
<!–
instead of REQUEST_URI, we could show absolute URL via:
http://HTTP_HOST/REQUEST_URI
but what if its https:// or other protocol?
SERVER_PORT_SECURE doesn’t seem to be used
SERVER_PORT logic would break if they use alternate ports
–>
<h1>404 Not Found</h1>
<p>The server can not find the requested page:</p>
http://www.lapalys.ca/wp-content/uploads/2014/07/4-Infos.png (port 80)
<p>
Please forward this error screen to http://www.lapalys.ca’s
WebMaster.
</p>
<hr />
<address>Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/1.0.0-fips mod_bwlimited/1.4 mod_fcgid/2.3.6 Server at http://www.lapalys.ca Port 80</address>
<!– end content –>
</div>
</body>
</html>
Le lien est cassé.
That’s very strange. There really is an error page, and it even contains the correct URL. So why doesn’t the server handle the request correctly?
A curious point: that error page was not generated by WordPress. If you intentionally go to an non-existent page (e.g. http://www.lapalys.ca/invalid), you’ll get a “Not Found” page that’s very different from the above HTML. Somehow, when BLC sends a request to your server, WordPress is getting bypassed. This still suggests there’s some kind of a server configuration problem – internal requests are handled differently than external ones.
