Some suggestions:
1) Rather than creating another category (cluttering the directory structure, IMO), I would UPDATE the Status field to whatever status is found via LWP:UserAgent.
Then you could create a template that displays all "bad" links by their error message (403, 500, 302, etc.).
2) Set up a nightly email process that would email link owners whose link "status" is NOT 200 to let them know that the link is bad. Set up another column called "contacted" (SMALLINT, NOT Null, Default = 0). Then increment the "contacted" column by the number of times they've been contacted. Set up a global "counter" setting that will check against the number of contacts, and if the status is still NOT 200 and they have been contacted the number of times in the global "counter", then the link is automatically deleted.
3) Use LWP:UserAgent within the JUMP.CGI script and if the link is NOT 200, then set-up an email routine to email the administrator to let them know the LINKID, ERROR, and even the REMOTE ADDRESS of the user who has clicked on a bad link to avoid any SPAMMING.
Now, I think some of these features are already in the BAD LINK MOD that Pugdog wrote, but some are definitely not.
I, personally, use #3 as the least intensive option since the only thing that happens is that an error message appears if the link is bad on the web page and an email is sent to me. Not totally automated, but since I run links verification on a weekly basis, it really is not necessary for me to UPDATE the status column in the LINKS table, too much CPU, IMO. But for those with dedicated servers, a live UPDATE to LINKS status would not be very intensive.
========================================
Buh Bye!
Cheers,
Me
1) Rather than creating another category (cluttering the directory structure, IMO), I would UPDATE the Status field to whatever status is found via LWP:UserAgent.
Then you could create a template that displays all "bad" links by their error message (403, 500, 302, etc.).
2) Set up a nightly email process that would email link owners whose link "status" is NOT 200 to let them know that the link is bad. Set up another column called "contacted" (SMALLINT, NOT Null, Default = 0). Then increment the "contacted" column by the number of times they've been contacted. Set up a global "counter" setting that will check against the number of contacts, and if the status is still NOT 200 and they have been contacted the number of times in the global "counter", then the link is automatically deleted.
3) Use LWP:UserAgent within the JUMP.CGI script and if the link is NOT 200, then set-up an email routine to email the administrator to let them know the LINKID, ERROR, and even the REMOTE ADDRESS of the user who has clicked on a bad link to avoid any SPAMMING.
Now, I think some of these features are already in the BAD LINK MOD that Pugdog wrote, but some are definitely not.
I, personally, use #3 as the least intensive option since the only thing that happens is that an error message appears if the link is bad on the web page and an email is sent to me. Not totally automated, but since I run links verification on a weekly basis, it really is not necessary for me to UPDATE the status column in the LINKS table, too much CPU, IMO. But for those with dedicated servers, a live UPDATE to LINKS status would not be very intensive.
========================================
Buh Bye!
Cheers,
Me