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.
Related posts :
Subscribe via RSS
Get Updates by Email
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 ๐