fiasco
commented
8 years ago Hey @DJMyles,
The ask here sounds pretty valuable and I agree that it would be valuable to have in the distribution.
Those patches are 3 years old! If they still apply, thats great, but the reason they may not be in the Link Checker module today is that that issue has not been reviewed by the community. Well.... it says it hasn't, but if you're using them in production, then apparently they have!
My point being, if you were to update the ticket, advise those patches work as prescribed and set the issue to reviewed & tested by the community, then those patches may get into the link checker module.
In which case, govCMS wouldn't need to track patches and this would be the most prefered approach.
So lets see what happens if you update that issue and set it to RTBC. We don't want govCMS to become a way to circumvent contribution to the Drupal project. It somewhat defeats the purpose of inheriting from Drupal in the first place.
If the patches don't get accepted, then we can revisit their fit for use in govCMS.
Beans and linkchecker modules are both bundled into GovCMS. It would make sense that we extend linkchecker support to cover the bean entity as would imagine many GovCMS adopters use them in a similar way we do for large content repositories. There is even more reason to add this support with the new views integration for linkchecker in 2.4 to customise those reports.
We have successfully implemented the capability locally here and confirmed it works, with bean field URL's outputting to /admin/reports/linkchecker. We used the two patches outlined here.
Happy to do a pull request if there is some traction on this simple enhancement.