I'm using Linkchecker a lot to keep my site's interal links pointed in the right direction. So often, linkchecker reports a broken link where in fact the link is right and the destination should exist, but doesn't (because I've forgotten to set the right path alias). After fixing this (in effect, creating the link destination), I don't want to wait a few weeks until linkchecker checks this link again but trigger an immediate retest to see that it works, and clean up my broken links report.

The attached patch adds a "Recheck link" button on the edit link page, if you press it the link's last_checked is set to 0 which causes a retest during the next cron run.

Comments

hass’s picture

If you change the request method the link check is normally done on next cron run... not after weeks. Hm... not sure if it makes much sense to add this button to the edit links settings from usability side. Not sure if users would ever look there for this...

wimh’s picture

If you change the request method the link check is normally done on next cron run... not after weeks.

True, but I don't want to change the request method. Also, changing it once and then changing it back is cumbersome, especially since the link disappears from the report once the method was changed the first time so there's no easy way to find it back to revert the change.

Hm... not sure if it makes much sense to add this button to the edit links settings from usability side. Not sure if users would ever look there for this...

The first alternative that comes to mind is to put a dedicated action in the broken links report. But there you already have at least two actions per link (edit link and one or more edit node/block/comment), so that would become too crowded. And actually, "edit link settings" was the first place I looked when searching for an existing feature that does this ;-)

hass’s picture

Status: Active » Postponed (maintainer needs more info)

I'd like to understand what you are doing there... Normally link references are updated if you save a node/block/comment. So if you have used a wrong URL somewhere and this one has been fixed it's immediately added (as it may be new) to the linkchecker table. There is no re-check required at all.

Maybe you are using path_redirect? Or are you using node/1 and have a content filter that show all this links with aliases? Sounds strange... I'm only guessing...

wimh’s picture

Hi hass,

I'll be a bit more verbose in the description of my use-case, I agree it might sound a bit strange.

- I create a page About on my site, it's saved as http://mysite.com/node/25
- I put a link to About on say node/100, and have it point to http://mysite.com/about
- Since /about does not exist, Linkchecker will flag node 100 and tell me /about does not exist

Normally, at this point, one would edit node 100, change the About link's target to node/25, and all is well.
But actually, I wanted to use the /about alias, I just forgot to set it in step 1.

- So I now go back to node 25, edit it, and set the path alias correctly to /about
- Now I want Linkchecker to know about what I did (cause I like a clean Broken Links report)

I could open and re-save node 100, without making changes (the About link, pointing to /about, is fine for me). Linkchecker will re-analyzethe links on node/100, find /about, see that it was last checked less than 2 weeks ago (and failed once), and I guess therefore do nothing?
So at this point, I'd like to tell Linkchecker that an URL it already knows, /about, might no longer be broken and needs to be rechecked.

I hope this makes sense?

hass’s picture

Status: Postponed (maintainer needs more info) » Needs review

You must have *much* time :-). Have you ever thought about using the following modules?

1. http://drupal.org/project/pathologic
2. http://drupal.org/project/Pathfilter

Than you always use "node/x" or "internal:node/x" in the content and all path's are correct. This also works well if your testsystem is in a subdirectory and so on. If you change an alias it's immediately changed in all content where it's used... very great! I cannot understand how others cannot use such a module... :-)

hass’s picture

Status: Needs review » Needs work

I've spend some time with this patch, but I'm not happy with the way it works from usability side. The main reason is - if someone changes a setting and press the "Recheck link" button - all the changed settings are lost. My experience is that this hurts back in a new case soon...

We should also fix the code style bugs in the button arrays ) ); to )); and always make a line break after a curly else(if) quotes and write "else if" as "elseif" (new D7 rule, too), please.

Is there any form in core that works similar?

wimh’s picture

Is there any form in core that works similar?

The Clear Cache buttons (both in core and Linkchecker itself) are a bit similar. These buttonsmy are positioned differently though, inside the content area rather than next to Submit. What if I placed my Recheck button in its own fieldset, separate from Settings?

hass’s picture

Sounds better... or we use a single checkbox that can be ticked for a forced re-check. Where have I see this.... ahh - taxonomy menu... But at least it's a good idea to have an extra fieldset... we could also allow some extra stuff later - like - reset stats or not and so on... later if it makes sense.

I'm not yet sure what a full content check for broken anchors may bring us... maybe a cache clear and such things, but the KISS mode is best over all... :-)

wimh’s picture

StatusFileSize
new2.11 KB

New patch attached: the Recheck link button is now in its own fieldset.

hass’s picture

Status: Needs work » Needs review
hass’s picture

Status: Needs review » Needs work

If I simply press save the re-check is forced and the pages doesn't redirect to the overview as in past. This is wrong behaviour.

hass’s picture

Version: 6.x-2.3 » 6.x-2.x-dev
Status: Needs work » Needs review
StatusFileSize
new2.33 KB

How about this? I'm not sure about the fieldset title...

hass’s picture

Status: Needs review » Fixed

I've renamed the fieldset to "Maintenance" and committed the code.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.