Broken Link Checker 0.5 Available
The latest version of Broken Link Checker for WordPress is now available on WordPress.org. If you’re already using the plugin you should get an update notification within 24 hours. Below you’ll find a list of changes and a bit commentary about the update.
Around 20 people downloaded the beta version. I haven’t received any death threats related to that release, so I’m just going to go ahead and presume there are no critical bugs in the new code. But if you do find anything that looks like a glitch feel free to report it in the comment section or via my contact page.
What’s New
- Check links in bookmarks (AKA the blogroll).
- Check links in custom fields (optional). You need to list the custom fields you want to be checked in Settings -> Link Checker. At the moment the plugin is only able to parse fields that contain a complete URL and nothing more. Note that when you add a new field to the configuration, it will take a while before the plugin re-parses your posts and detects the field values.
- Manage all links from one page. You can view, edit or remove broken links, redirects and any other link in any post, custom field or the blogroll, from one page.
- An all-new dashboard widget that displays status info about broken links. To save dashboard space you can close the widget and configure it to automatically pop open if problematic links are detected (this is actually on by default).
- Improved database efficiency. For example, information about URLs and places where they are used is now stored separately. This is more elegant and enables some neat features.
- Check each URL only once per the user-configured period (except broken links that are still double-checked). Previously, the plugin would check links that are used in X different posts X times in a row.
- Link modifications are applied to all posts automatically. You can edit or delete a link via the plugin’s tab and all the posts, custom fields and bookmarks will be automatically updated to reflect the change.
- Posts are only re-parsed when they change. Previously the plugin would periodically re-check each post for new links which was wasteful and hurt performance.
- All received HTTP headers are now included in the detailed log (previously only the last one was shown).
- Generally more informative logs.
- You can quickly add URLs to the exclusion list by clicking the “Exclude” button.
- Added paging support to the link list.
- Everything runs on jQuery instead of Prototype now.
- Everything is way more object-oriented now.
- Everything uses AJAX the “proper” way now by calling
admin-ajax.phpinstead of a separate plugin file. - Significantly improved database performance. Some queries are still slow since it’s not practical to put an index on a DATETIME column, but overall the plugin uses the WordPress DB much more efficiently.
- Sorting features are gone, for now. I’ll probably add a number of sorting options in a later version.
- Improved UI that’s more in line with WP 2.7 style. For example, most action links in the “Broken Links” tab only show up when you hover over the corresponding row.
- Links in custom fields or the blogroll get an appropriate icon in the broken link list.
- The URL editing feature is more elegant and there’s finally a “Cancel” button.
- More intuitive AJAX behaviour. For example, when an AJAX call completes it will flash the appropriate row green or do something else to indicate that it was successful.
- No more hidden debug output in HTML comments. I’ve switched to the excellent FirePHP + FireBug debugging combo and it works great.
- Only one instance of the link checker can be active at one time. Previously it would just plough on, blissfully unaware of race conditions and other related nastiness. This behaviour was probably what caused the mysterious slowdowns and inexplicable bugs that a few users encoutered. Now the worker function uses file locking and will abort if there’s already another worker running.
- The minimum required WordPress version is now 2.7. If you’re using something older, upgrade or get an older version of the plugin from the wordpress.org archives. Progress marches on, humans.
To-Do
These are the features that will probably be implemented in the relatively near future (i.e. before the winter 
).
- Result sorting on the “Broken Links” page.
- Cron support.
- Some kind of pop-up tooltips for broken links in posts.
- More optimization, e.g. don’t load the entire plugin when it’s not required.
- An option to only check internal and/or external links.
- Localization support.
- Checking links in comments. Maybe. I’m still not convinced that would be all that useful.
1.0 ?
In conclusion, I’m quite pleased with how the update has turned out. I was really tempted to break away from the fractional versioning scheme I’ve used for this plugin since the beginning and label this the true and complete “1.0″ release, but the thought that there will almost certainly be a load of new bugs due to all the major changes made me reconsider. Maybe after all the to-do items are implemented…
By the time it gets to 1.0 this will probably the most powerful and robust plugin I’ve ever created. And then the robot uprising will happen.
Hiya,
Thank you for this new version : v0.5 is a great improvement over previous versions in terms of speed and usability.
Cheers !
Hi, got on error on adminscreen after updating:
“Table ‘dbxxx.ifolk_blc_instances’ doesn’t exist”
Any idea?
Best wishes and thanks a lot for the great plugin!
That’s a bug. I’ve uploaded a fixed version, 0.5.1.
worked
thx
I haven’t been able to get the new version to detect any links at all. Even if I tell it to recheck all pages, after a few seconds it switches from “Searching…” to “No links detected.”
Every post and blogroll entry shows up in (prefix)blc_synch, but the synched and last_synch columns are all 0 and 0000-00-00 00:00:00. The other two blc tables are empty.
I don’t see anything relevant in the JavaScript error console or the PHP error logs on the server.
This is with 0.5.1 on WP 2.7.1. Just to be sure, I tried disabling all my plugins except this one, and it still didn’t find any links in ~500 posts — most of which do have links in them. The previous version (0.4?) had been working for months, and most recently had found 4 broken links that I hadn’t decided how to handle.
Hmm, I can’t really imagine any possible execution path that could lead to this behaviour, unless… Yep, I’ve still got the table prefix hard-coded as “wp_” in one query.
I’ve just uploaded version 0.5.2 that should fix the problem.
Thanks, that did it! It’s in the process of checking 3200 URLs (yeah, I link to a lot of stuff)
Did any of the reports you recieved about previous versions mention about it causing phpfcgi / phpcgi to slowdown and in some cases crash? (possibly thos race conditions you mentioned).
If so, I’ve /literally/ just sent a request to me host to swap my site to a newer server because my site was performing soooo badly when logged in to WP! Oh well.
Just about to upgrade the plugin on another site of mine, so thank you for this useful broken link checker
The improvements for 0.5 are very positive indeed.
I got reports about slowdowns, but I never could think of anything that could be causing them (until recently that is). I’m still not sure if this version fixes that – I could never reproduce the problem. And this server did in fact run PHP in CGI mode until recently as well.
I am finding that BLC is now causing Firefox to crash instantly
It’s never crashed in this way before. It first happened when I activated the BLC plugin (although I activated a couple of others at the same time, so couldn’t narrow it down), though the plugins were activiated. Then it later crashed a couple of more times.
Finally, to confirm the problem is in BLC, it’s just crashed as I clicked to Unlink a broken link – the link did get unlinked, so it’s something after the query that Firefox doesn’t like.
Any clues, or can I provide you with more info?
What version of Firefox do you have? I tested the plugin extensively in FF 3.0.10 and didn’t encounter any problems.
I suspect a Firefox addon might be causing this. Any candidates?
FF 3.0.10 here as well.
As I said, I’ve not seen this type of crash before, but it is definitely related to BLC, even it’s a plugin it’s not liking, rather than FF itself.
My list of enabled addons:
Adblock Filterset.G Updater 0.3.1.3
Adblock Plus 1.0.2
Adobe DLM 1.5.2.29
Ancestry.com Advanced Image Viewer 1.0.0.1
British English Dictionary 1.19
ColorZilla 2.0.2
Console^2 0.3.10
Download Statusbar 0.9.6.5
Fire.fm 1.2.3
Firebug 1.3.3
Firecookie 0.8
FireRainbow 0.8
Google Gears 0.5.19.0
Sage 1.4.2
ShowIP 0.8.17
Web Developer 1.1.6
YSlow 2.0.0b3
The crash is intermittent – I tried Unlinking a non-broken link, and it worked fine. As such, disabling any/all plugins, or trying it in IE won’t be conclusive, unless it just happens at the right time.
Hmm, now that I think of it, it could be the plugin’s fault. The “Unlink” button fires off an AJAX requests and expects a JSON-encoded response. If there’s a bug in the PHP code somewhere, the response might be invalid JSON and cause a … JS exception? But still, that shouldn’t cause the entire browser to crash.
You could use a HTTP sniffer to see what data your browser receives (as a result of clicking “Unlink”) just before crashing.
I disabled and uninstalled some plugins, created a new post with a broken link, then Unlinked it from BLC, and it worked fine. All the HTTP stuff came back as 200 (although the Post was “action blc_work” according to Firebug, but sent to “?action=blc_unlink” according to Live HTTP Headers. In the former case, the Response content seemed to be empty?).
I’ll stop tinkering and see if it happens anymore. Thanks for your plugin and assistance
For one of the sites I was working on, it was absolutely invaluable.
http://w-shadow.com/blog/2007/08/05/broken-link-checker-for-wordpress/ needs the version numbers etc updating.
The plugin does periodic blc_work requests to run the actual link checking routine. These should have an empty response.
The unlink-button AJAX is separate. It sends action = blc_unlink, link_id = [id] (via POST) and should receive back a JSON-encoded response.
And I know the page needs updating, I’m just lazy
I tried the plugin against WP2.6.5. After pressing “Recheck All Pages” it shows “Network Error” message despite I haven’t noticed any network errors.
In the “Broken links” tab it shows only one link (which is valid).
How can it be resolved?
Thanks
This version is only compatible with WP 2.7 and up. You need an older version of the plugin if you want to use it with WP 2.6.5.
I’ve had to de-activate the plug-in as it detected every image link to flickr on my edu blog as being broken. All my post use flickr images, it’s kind of the point of the blog! It seems to detect the image source as being the blog domain url and then adds the flickr url on to that. (e.g. http://mydomain.com/www.flickr.com/photos/nameofperson/i234f67/) I’ve double checked the html of several posts and there’s nothing funny going on there. I also tried deleting the ‘broken link url’ via the plugin but they just reappeared. Eventually I added the word ‘mydomain’ to the exclusion list in settings – it then couldn’t detect any links at all.
Check if the image URLs (in the posts, not in the plugin’s list) include the protocol part, i.e. “http://”. The plugin can get confused if they don’t.
Thanks for the quick reply. That was the problem. something to do with the flickr blog this template. Sorted now and the plug-in is working fine. Thanks again.
Hi there:
I just downloaded the plug-in but when I went to activate got the following error message:
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 7680 bytes) in /home/nogimmie/public_html/wp-includes/kses.php(1006) : runtime-created function on line 1
I am totally new to this and know very little…is this something I have to fix on my end? If so, does anyone have any suggestions? I’m still on WP 2.7.1 as my hosting provider hasn’t upgraded yet if that matters. Thanks much!
Hmm, I can’t think of anything specific that could cause this. What PHP version does your server have?
I believe it is PHP version 5.2.4. (At least that is what comes up in their configuration section.)
Perhaps you could try activating it when no other plugins are active (to check if it’s not a plugin conflict issue)? This really seems like a rather mysterious problem.
I’ll have to try that suggestion…need to find a little time though. I have LOTS of plug-ins! LOL Thanks for the help!
[...] the feature list below are slightly out of date because a major update was been released recently (see details). I’ll get around to updating this page [...]
@White Shadow,
Just thought I’d confirm to say that BLC wasn’t wholly responsible for the Firefox crashes I was having. Uninstalling Google Gears completely (not just disabling within Firefox, but removing it via Control Panel -> Add/Remove Programs) seems to have stopped the crashes, and now seems to be a commonly reported problem.
I have the same problem with the latest version of the plugin as another commenter. After activating it the plugin does nothing. Clicking on the Re-check button will make it start looking for links for about 1 second and report back that no broken links were found. The blog I try it on has currently over 6000 posts so there surely are some broken links.
Any ideas on how to fix that?
So does it detect any links at all, broken or not? You should see something like “Detected X unique URLs in Y links.” in the Settings -> Link Checker page; X and Y should be above zero.
If it does detect some links, go to Tools -> Broken Links and click on “All”. There should be a listing of all links used on your blogs. You can click the “Details” link in the URL column to see more information about that link, when/whether it was checked and what the result was.
If it doesn’t detect any links… you might have a problem. The one thing I can suggest off-hand is making sure the /wp-content/plugins/broken-link-checker/ is writable (because the plugin needs to store it’s lockfile somewhere and it will use it’s own directory if it can’t find the system-wide temp. directory).
Hej,
the plugin is not detecting any links. The dir was not writeable but making it so did not change the behavior of the plugin at all. Any other ideas what might cause it? Maybe another plugin or server module that needs to be loaded?
No, it doesn’t need any additional modules or plugins (cURL is nice but not required).
Here’s an idea : Install the debug version of the plugin. It sends a lot of debugging information via the FirePHP protocol. You can use FireBug + FirePHP (FF addons) to view those messages and see if anything suspicious comes up.
Can’t wait for the Robot uprising!
It would be useful, I think, to be able to set a threshold number of failures before a link gets included in the broken list. I see quite a few links with a failure count of 1; they seem to fix themselves eventually. I’d just as soon not bother with them until they’re solidly failing.
Alternatively, show the broken count as part of the main display, rather than (or in addition to) in details.
Alright, I’ll add that in a future version.
[...] Developer Page Share this on del.icio.usDigg this!Share this on RedditBuzz up!Stumble upon something good? Share it on StumbleUponShare this on TechnoratiShare this on FacebookTweet This!Share this on FriendFeed [...]
Hi,
thanks for the plugin. I keep a german translation of my website, and when I use relative links to other posts or downloads on the same site in the english post and copy it verbatim to the german site, the links break. I expect to miss a link every now and then when I change them to absolute links. Your plugin will notify me of the ones I missed, and that’s great
One question: you don’t look at links in the code and pre tags. I wonder why, because I do have links (and in fact had a broken link
) in a pre block, but I don’t see why one wouldn’t look for links there. Am I missing something?
Thanks
It doesn’t look for links in pre tags because, in my personal experience, pre tags often contain source code of some kind. So any link tags tend to be either made-up examples that are not intended to work, or a part of some code that dynamically generates links (and thus they contain stuff like variable references and function calls, and can’t be properly handled by the plugin).
On the other hand, my views on this are probably biased because I’m a programmer. What do you use the pre tags for?
In this particular case on http://www.markusbe.com/2009/09/installing-flash-media-server-on-ubuntu-linux/ I have a have a wget command line in a pre tag. The wget URL is also clickable in the browser. Probably not a very common use case.
I didn’t understand though why you don’t look in pre tags. If I understood correctly, you refer to a situation where the pre tag contains code that should be shown to the website user and that generates links. The search pattern used to find links also looks for the a tag in angle brackets. If the code in pre tags should show the user an a tag in angle brackets, then in HTML they should appear as entities < and >. Consequently, the link search pattern shouldn’t match. Which of my assumptions is wrong?
…actually, that’s a good point. Turns out I was confused about how <pre> elements usually work as I have a code highlighter plugin installed that automatically converts angle brackets inside <pre> tags to their corresponding HTML entities
Some of my posts contain literal <’s and >’s as part of example code.
I’ll remove the pre-ignoring “feature” in the next release.
Great, thanks for that
Hi, I’m trying to activate your plugin but am getting an error:
Fatal error: Cannot redeclare maybe_create_table() (previously declared in E:\wwwroot\website.com\www\wp-content\plugins\postie\postie-functions.php:2023) in E:\wwwroot\website.com\www\wp-admin\includes\upgrade.php on line 1009
It looks like Postie and BLC are using the same function names?
No, they don’t use the same names. In this case, Postie is buggy and tries to define a function with the same name as one that’s already defined in the WordPress core files.
The reason it only shows up when BLC is activated is because BLC loads and uses that core file – “wp-admin/includes/upgrade.php” – as a part of it’s activation routine. This is the recommended approach for plugins that need to add/upgrade DB tables and not a bug.
So ask the Postie dev about this error
Thank you for your quick reply and insight into the problem! I’ll contact the Postie developer. Cheers!
Adam
I got the plugin activated… I re-wrote the Postie plugin to use the recommended approach. Thanks again for your help with that.
One more question/problem… I am unable to fix links that require a “mailto” URL. For example, when I attempt to correct them using “mailto:someone@domain.com” it throws an invalid URL error. I didn’t see a setting to change this so I’m guessing it’s either a bug or by design?
Same thing happens with “rtsp:” and “rtmp:”. I can fix them manually by editing the post but it sure would be nice to edit them right within the Broken Links page.
It’s a side-effect of the design – the plugin only supports HTTP(S) links. You’ll need to edit the post(s) directly to fix those URLs.
Gotcha.
BTW, this plugin rocks… I’m sending you some cash-ola. Thanks for your time and hard work on this plugin. I’m converting a very large site from DotNetNuke to WordPress and the plugin identified over 4,000 broken links. Ouch. I was, however, able to run some REPLACE queries against the db and got the count down to 39! Whew! I wouldn’t have known all the issues without your plugin. Thanks again!
Thank you for the donation
just a question:
I am using the redirection plugin to take care of changed URLs and automatically set up 301 redirect. Now your plugin is reporting 34 broken links (itnernal ones) because it doesn’t recognize that the redirection plugin is actually redirecting those…
what do you rekon is the best procedure? manually edit and change all 34 links or beg you to introduce some support for that plugin?
Or maybe your plugin can check if there is a 301 redirect happening and offer me to auto correct the links to the new location?
Can you direct me to the homepage of that redirection plugin?
The BLC does check for redirects. I’m guessing that in your case one of two things is happening : either the redirection plugin performs the redirects by dynamically modifying posts when they’re displayed (which wouldn’t be caught by the link checker because it works with the WP database directly), or there’s a bug in my redirect-checking code. Either way I’ll need to test the other plugin myself before I can figure this out.
I’d have included the link to the plugin but I feard my comment would get caught as spam: http://wordpress.org/extend/plugins/redirection
I appreciate your help with this matter.
I recently moved one of my websites to a new server, and upgraded to WordPress 2.8.4 and Broken Link Checker Version 0.5.13.
Broken Link Checker thinks that *all* of my links are broken. Each link has the following details:
Log : === First try : 0 (No response) ===
Link is broken. (Most likely the connection timed out or the domain doesn’t exist)
HTTP code : 0
Investigating the code in the plugin, it seems that the HTTP requests are made with cURL or Snoopy. The plugin will fail silently if neither of these are present.
Code in link-classes.php looks like this:
if ( function_exists(’curl_init’) ) {
// removed link checking code.
} elseif ( class_exists(’Snoopy’) ) {
// removed link checking code.
}
// no code to detect situation where both curl_init and Snoopy do not exist (and alert the WordPress admin).
This is a bug that should be fixed.
Cheers,
Stuart.
@ Stuart : There probably is a bug in there somewhere, but are you sure it’s that one? Snoopy is actually present in WP 2.8.4.
@ ovidiu : Hmm, the plugin seems to be detecting redirects created by Redirection (arrgh) properly when I try it on my own site. Maybe the problem is with redirects in general, not just those created by that plugin? Do any other redirects show up in the plugin’s “Redirects” list?
Also, when the next version of the link checker is out (should be within 12 hours), go to the settings page and click on the small “Show debug info” link near the “Status” field. This will display a short report about your server configuration and WP installation; see if it mentions anything about redirects.
new version works flawless, might have been a glitch….
[...] als auch externe Links gewesen. Auf dem rechten Screenshot seht ihr nochmals das Ergebnis der Broken-Links-Überprüfung von [...]
Does anyone know of a version of this I can download that will work on my install of 2.6.1? I would love to use this, even if it’s a slightly out of date version. I get “network error” when installing the newest one, so there must be an incompatability (as advertised).
You can view & download old versions here. Any of the 0.4.x releases should be compatible with WP 2.6.1.
Thank you soooo much! I didn’t really expect to get an answer, that’s so kind of you! Have a great day!
Hi there I love the idea of this plugin, however it is not detecting all my broken links. There is a site that I frequently link to that uses 201 error pages (I think…the broken links all end with 201) and it is imperative to the nature of my site that I am able to find these broken links and remove the posts when they are no longer valid links. Can you provide any help?
My first impulse is to say the site is doing it wrong – the 201 code is definitely not intended for reporting errors – and so there’s nothing for me to fix. However, I have plans for eventually adding a new filter (or something similar) that would let you sort links by response code, so that might help once it’s implemented.