Implement a trigger mechanism to call actions based on link checker test results

Please provide a patch.

I will take a look to your patch. I'm not a friend of using hook_init(), but in general it should be much better to use triggers as the issue #249701: Email notification for node authors may also become obsolete by this change.

We should not forget to remove the current 301, 404 settings and all outdated variables + we need to update from the old settings to the new triggers via an update hook. Plus we should write some text to the old settings fieldset where the new settings have been moved too :-).

Patch needs work, 404 also contains the call to _linkchecker_unpublish_nodes(). As more I'm thinking about _linkchecker_unpublish_nodes() - it looks per unformant to me. I need to think about going abroad the node_load API call and update the node table directly... should be much quicker if we think about 1000+ nodes having the same link in the content. But not using the API is also a no-go...

The patch is missing the "actions" the module have currently implemented.

I've renamed a few variables, the filenames and folders and added a help text.

This still needs actions to be implemented.

Yes, I thought you'd like to do the same... better integration with D6 core functionality would be great and solve many other possible feature requests (like notifications), too. And save the module from duplicating others efforts... :-)

We only need to define actions depending on a number of check fails (for e.g. unpublish after 3 fails)... not sure if we are able to reuse the node_unpublish_action. We need to be able to unpublish more than one node per execution, but _linkchecker_unpublish_nodes may be adapted.

We should also implement triggers that:

1. Allow to change method HEAD to GET automatically if it HEAD fails.
2. Disable link checking if GET also fails (maybe)

May be required to add dependency with Rules module. It provides configurable conditions http://drupal.org/node/298534 what we may need for the "unpublish after N fails"

@ducdebreme: I've fixed nearly all remaining issues in the queue... if we are able to get a working patch - this could go in before the next release, planed within the next day(s). I may only add the feature #517174: Auto-update could prefix urls and integrate with other modules and then create a new release if you are not able to work on this feature... the module is nearly feature complete and I'm not aware about any remaining features or bugs except cURL support that is difficult to solve. Therefore it may be a release for a very long time and may postpone this trigger stuff to far future.

subscribed

Marked #712438: Providing a hook for checking some links against custom conditions as a duplicate

What's the status on this? Did it make it into dev?

Nobody is working on it and the case is short before getting closed for inactivity reasons.

I further worked on patch #6 which is now included in this patch (you only need this patch to get it working).

Apart from the trigger there's now an action which changes the HTTP request method from HEAD to GET and conducts the request. If successfull the link in linkchecker_link is updated. This is needed for Youtube links as Youtube doesn't support HEAD requests yet.

I also changed the trigger providing a link object and the node object as context.

Testing:
1. Just go to your trigger interface, i. e. admin/build/trigger/linkchecker
2. On "Trigger: Content contains links with HTTP status code 404" assign the action "Process HTTP GET method if HEAD request fails"
3. Run cron

To boost a spefic data row just provide a lower timestamp in last_checked column of linkchecker_links table, as cron only runs over a subset of links (the oldest ones).

#17: linkchecker-trigger-change-http-get-action.patch queued for re-testing.

Hi, I'm really interested in seeing this feature included to link checker!

subscribe

Subscribing

I'm especially interested that there would be a trigger when a node is unpublished on file not found error (after the chosen number of time it occur, so just as it unpublishes). When I remember I have that option enabled, it work up my nerves as I wonder how long a node has been unpublished (without my knowledge) ; assigning an action to that trigger would reassure me.

Actions/rules integration would be absolutely fantastic for this module and would open up so many possibilities. I just posted in the feeds module about options to use linkchecker:
http://drupal.org/node/1240366
If you automatically import content with feeds from external sources, this module could be superb in making sure that these external resources have not been removed.

Linkchecker seems to have 3 components:
- scanning the selected nodes for links (internal / external)
- checking the links (triggered through cron)
- error handling

It seems to me that error handling could be better handled completely by rules, i.e. removing it from the global settings. That would allow us to be way more granular. Right now, I can only set "unpublishing nodes" for all nodes and fields at the same time. With rules, I might be able to say:
- if any link on node type y returns 404, send an email to token
- if specific link in CCK field returns 404, unpublish the parent node (e.g. for my feed import example

Would it be possible to:
- create a trigger/event "Broken link is detected"
- add condition how often the link has to be recorded as broken
- add conditions for the http response headers (404, 301 etc.)
- add condition in what element the broken link was detected (e.g. body field, block, specific CCK field etc.)
- there should already be plenty of actions to handle any responses to finding broken links
I am not able to write/extend the patch myself, but would be happy to test this!

Rules integration will an excellent feature.

Would be great if it can be added to D6 as well.

Task was updated more than 9 years ago. 🏰
Marking as outdated.
Please update description and info if it is still valid.

D7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.

If the issue remains relevant for D10+ versions, merge requests with proposed solutions for a new module version (D10+) are welcome in a new follow-up issue.

Thanks!