Found in dblog after cron:
Notice: Undefined offset: 1 in Drupal\linkchecker\LinkCheckerService->statusHandling() (line 209 of /var/www/html/drupal/web/modules/contrib/linkchecker/src/LinkCheckerService.php)
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | 3065045-test-only.patch | 1.29 KB | eiriksm |
| #20 | 3065045.patch | 3.14 KB | eiriksm |
| #16 | 3065045-16.png | 63.67 KB | baluertl |
| #13 | undefined-offset-error-3065045-13.patch | 1.83 KB | ohorbatiuk |
Comments
Comment #2
waverate commentedLooks like it is coming from /src/LinkCheckerService.php:
Comment #3
hass commentedCan you try to figure out what exactly is causing the issue or provide a repro case, please?
Comment #4
hass commentedComment #5
waverate commentedHmm. Not going to be easy to come up with specific steps as these errors are generated during cron and currently cron is checking 20 links for status.
However:
a. The error is not occurring 20 times per cron so I feel there are some links that are fine.
b. Because this is failing in LinkCheckerService, am I correct in assuming it it is only occurring while checking External links?
c. I can't tell if the error occurring on a 200 status code or in another status code.
I may need to set up a simpletest.me and try a couple of combination of links to see what type of status code generates this error.
Comment #6
hass commentedI guess it is one link and this can be caused by remote servers. In D7 I have implemented a lot of fallbacks, but we need to find out what bugs Guzzle may has here. With the 20 links where one is causing this we may find the issue by checking one by one link.
Comment #7
waverate commentedOkay. This took a while to find. It looks like it is occurring for external links with 200 error code response. Here are an example of a couple of a couple of links and their response from curl.
1. https://queenmobs.com/2018/11/marianne-micros-interview/
2. https://arboretumpress.com/
Comment #8
waverate commentedFurther to #7, node looks like it is added to linkchecker_index correctly and without error; and links look like they are added o linkchecker_link correctly and without error.
The IS error occurs during cron.
Comment #9
hass commentedMissing code has been removed from function
check()and therefore the incorrect variable$response->getHeader('Link')[1])causes the notice. This is for sure incorrect code. We must not rely on the response object here. The$response->uriwas added incheck()to provide the fragment to thestatusHandling()function and nothing else as we cannot get the values otherwise.Missing:
Wrong:
Correct was:
Comment #10
waverate commentedOf interest:
a. the error does not occur when cron is run from drush
drush cron, andb. the error occurs twice per link if cron is run from https://example.com/cron/[token].
Comment #11
eric.guerin@ucsf.edu commentedI am getting similar offset error, during the CRON job.
Comment #12
shubhangi1995Comment #13
ohorbatiukComment #15
joel_osc commentedPatch in #13 seems to be working fine, errors are gone. Thank-you @chmez.
Comment #16
baluertlNow tested on our project and hereby I confirm that the patch shared in comment #13 does resolve the issue of displaying the unreal number on progress bar via /admin/config/content/linkchecker page:

Comment #17
c-logemannThe patch won't apply anymore. Needs to be re-rolled or better solved in an issue-fork.
Comment #18
eiriksmAlso definitely needs tests for:
- Cases where the link part of the header is an array with one value (which causes this error)
- Cases where the link part refers to a fragment that is actually on the page
- Cases where the link part refers to a fragment that is not on the page
Comment #19
joseph.olstad@C_Logemann, the patch does not need a reroll, patch 13 still rolls against the HEAD of 8.x-1.x
Comment #20
eiriksmHere is an updated patch with the tests I feel we need. Including a test-only patch that should fail with the notice from the issue summary.
Also fixed the test failures in #13. That patch got rid of the notice, but the actual functionality for fragments was effectively removed. So that's not ideal :)
Comment #22
eiriksmThat test fail was expected. Back to NR
Comment #23
ex dj commented#13 eliminates the error. However, "Date Checked" in the report is now 12/31/1969.
Comment #24
banoodle commentedPatch #20 works well for me (thanks!). Also confirming Last Checked dates are accurate (doesn't have problem mentioned about patch #13 in comment #23).
Comment #26
eiriksmThanks everyone!