Broken page / Broken link reports do not work with elemental content area

[maxime-rainville]

Description

The "broken link" and "page with broken file" report do not include pages with elemental area containing broken links.

Steps to reproduce

• Create a new elemental page
• Add content block.
• Add a link to a new file in the content block
• Add a link to a new page in the content block
• Publish the elemental page
• Archived the new page and delete the new file.
• Go look at the reports

Expected behavior: The elemental page should appear in the broken link report and the page with broken files report

Actual behaviour: It doesn't.

Originally created at silverstripe/silverstripe-cms#2453

ACs

• This looks through every block with a HTML field (including custom blocks)
• Content is being surfaced for the two reports outlined in the replication steps
• Create a new issue to create a build task to retrospectively find broken links within existing blocks (assuming that only future links will be picked up after this fix)
• Investigate and ensure this will not result in a regression to the dependant pages feature (see note)

Notes

• A SPIKE was has been completed for this issue, see: https://github.com/silverstripeltd/product-issues/issues/224
• We're probably going to see a similar problem with 'dependant pages' - where block pages aren't being included. It's likely that this issue would make this functionality worse, so we'll need to have a good look at this too.
• A similar issue has been raised for the external links report, see: Include broken links from content blocks silverstripe-externallinks#68

Related

• https://github.com/silverstripeltd/product-issues/issues/443
• Include broken links from content blocks silverstripe-externallinks#68

PRs

• NEW Track broken links and files within ElementContent #822

[ScopeyNZ]

Haha I know @chillu just told you to move this, but any fix here is going to be an annoying kludge. Content is not just on the $Content field which CMS often assumes. I'll attempt to start some discussion on this in the CMS repo later today.

[maxime-rainville]

My guess is whatever fix we come up with will probably have an impact on both CMS and Elemental.

I guess it depends on whether we choose to look at this as an Elemental problem first or a CMS problem first.

[michalkleiner]

My 2c would be to not save a new version of each page where a broken link is found when the report is run, if possible.

[ScopeyNZ]

My 2c would be to not save a new version of each page where a broken link is found when the report is run, if possible.

This just means using ->writeWithoutVersion when updating the content (as it rewrites the anchor to show invalid links). I wonder if this should be configurable UX experience? I guess it's weighing up whether a content author cares more about what caused their links to go red in their editor or why there's an extra version listed on the page. (cc @silverstripeux)

[michalkleiner]

One of our client's editor's behaviour was "ah, something/someone created modified versions of some pages (yellow dot in the site tree), let's bulk publish them just to be sure" — effect of running broken links report. Then they had bulk published couple pages every week and half a year later it was impossible to determine which versions/updates where legit and which were only a consequence of a weird UX of the report.
I would totally vote for an option to be able to turn "highlight broken links in red" feature. Just keep the list of them in the report.

[robbieaverill]

We've got an issue to track the missing feature required to fix this here: silverstripe/silverstripe-cms#2454

[brynwhyman]

This issue was parked for the discussion on RFC: Introduce a consistent content API to begin. However, we haven't been able to get any traction, nor dedicate time to that RFC likely given it's broad scope.

If this bug isn't impact/critical, it's very close as the reports arerendered useless if content blocks are the main source of content for a site. I'm starting to think an Elemental-specific fix could be the initial way forward here?

[clarkepaul]

Or remove the report if blocks are installed perhaps.

[emteknetnz]

Seems like that RFC would need to be a Silverstripe 5 thing, I cannot see anyway we could get something like that into 4 without either:
a) breaking everything, or
b) ending up with two ways to do something, which to me is worse then just having one

In any case it's a lot of work, agree with @brynwhyman that we should do an Elemental-specific fix here

[brynwhyman]

Or remove the report if blocks are installed perhaps.

These reports are part of the core recipe (with the external broken links report also provided to CWP sites). I feel like if we can get elemental to workaround this issue and keep the functionality, it seems like something worth doing for now. There will be a lot of sites with both these reports and elemental installed

[emteknetnz]

Fixed in #822

Note: only fixes internal links / files, not external links which is done in the externallinks module

[brynwhyman]

I've raised a separate issue to track the external-links module concern, see: silverstripe/silverstripe-externallinks#68

I've updated the ACs to remove this report as a concern for this issue.