Project

General

Profile

Actions

Feature #83847

closed

Epic #85006: Reduce falsely reported broken links

Linkvalidator should remove repaired links from report after editing record

Added by Sybille Peters about 6 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Should have
Category:
Linkvalidator
Target version:
-
Start date:
2018-02-11
Due date:
% Done:

100%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

This change will improve the workflow for editors, who fix broken links.

In the reports view you can click on the pencil to edit the record. If you edit and close, the backend will automatically jump back to the Report view. If the broken link was fixed, I would expect it to be removed from the list of broken links.

This is currently not the case. It makes fixing links very tedious in case you have several because you have to keep switching to the "Check links" tab and recheck. If you don't do that you can easily loose track in the long list of broken links (what was already fixed and what not?) Also, it is possible to deactivate the "Check Links" tab so not all editors can initiate unlimited crawling. In that case you are out of luck.

Reproduce

  1. Create 3 broken links in the body text of a content element (e.g. text & media)
  2. Info > Linkvalidator > Check links (current page, check all link types)
  3. Switch to "Report" tab. You should see 3 broken links in list
  4. click on pencil icon to edit the record.
  5. Remove one of the broken links
  6. click on save and close

Expected Result

You should now see only 2 broken links in list

Actual Result

There are still 3 broken links. You must go back to "Check links" tab and check again.

Possible solutions

When the editor edits, only a specific field of a record gets editied, e.g. tt_content.bodytext or pages.url.

Only one of the following solutions should be implemented:

  1. Recheck if the broken links in the field that the editor just edited are still in the field. If not, remove them from list.
  2. Recheck all links in record / field that was just edited. Update the list
  3. Change visual appearance of all broken links corresponding to edited record (e.g. dim it) to indicate that we are currently not sure if links are still broken. Display an icon to recheck broken links. This will default to behaviour 1 or 2.
  4. Try to determine a diff of what changed and only do a recheck for that

These are the pros and cons:

  1. Is very lightweight. No link checking on the fly is necessary. We just check if the links are still in the field. This has the disadvantage: If new broken links are introduced or a broken link is changed, the new broken links will not be added to the list. I think this is the best solution currently, but the biggest problem is having too many falsely reported broken links not removed from list. We optimize for reducing falsely reported broken links.
  2. for number 2 (recheck of all links in record): There may be a large number of links. External link checking may have delays. The timeout is currently set to 10. So if we have slow external webpages or there are problems, a recheck may take 30 seconds or more (as worst case). So, this is probably something we want to do asynchronously. But then we don't have the refreshing of the list.
    • for number 3 this could actually be easily done by using sys_history which can be checked for matching records that match recuid, tablename, userid, timestamp (range). This then contains previous field in history_data. The links can be extracted and compared. (this only makes sense for RTE)
      1. This is clunky and a little more helpful than previously but not very helpful.

Files

linkvalidator.png (80.2 KB) linkvalidator.png Sybille Peters, 2019-10-16 20:07
needsrecheck.png (70.5 KB) needsrecheck.png Sybille Peters, 2019-10-18 20:38
Actions

Also available in: Atom PDF