Views integration for Broken Links report

It would be great if you could add your views module. I'm interested to get the functionality you are writing about into the module. There is also one request to implement link checker reports with user defined filtering...

Let's attach a zip with your module here first. We may integrate it completly into the linkchecker module. I see no reason why we should maintain this features in a seperate module.

Subscribing...
This sounds like a great idea. I've been making a number of my links a separate content type that I can display them in a view organized by taxonomy. But that's overkill in a number of cases and having a simple report that show's all the links on the site is great!
Vid

This sounds fantastic however perhaps I missed something in nkschaefer's instructions.

1. I put the original attachment in /modules/linkchecker/includes and renamed it linkchecker.views.inc

2. I added his original function linkchecker_views_api() to the bottom of linkchecker.module

If this is correct, where should I be seeing the linkchecker content in views?

nkschaefer,

Thanks for the clarification. I was hoping that your instructions at #1 were how to added the Views capability to the existing Linkchecker module without having to load another module.

That being said, your file at #4 works perfectly.

I did not allow permission for users to access own broken links report. Instead, I used the broken_links View to create a My Broken Links tab in the /user page. It allowed me to display the table of broken links as I see fit.

I wouldn't want to make Views a dependency for the Linkchecker module however this should be an addon.

Hey nkschaefer,

Great work, thanks for contributing this. Hope to see views support included in Link Checker based on your code.

.

I'm finding duplicates in both the standard broken_links view, and my own custom views cloned from this report. Selecting 'distinct' has incorrect results, the count is right but duplicates remain.

Any ideas on how to solve this? I'm by no a views filter guru, but have tried everything I could think of to fix - adding more filters, selecting distinct, looking at the code, etc...

Thanks,
.

@hass Any plans to include this, or should nkschaefer create a project for it?

Either way, @nkschaefer - perfect! Just what I need! =)

It's planed to get included sometimes...

Great! Setting to 'needs review', since the module is attached in #4. Would you someone to re-roll that as a patch to be applied to 6.x-2.x-dev to make it easier for you to apply once tested?

Yes, patch is required.

This patch for Drupal 7 is based on nkschaefer's work.

Marked #671086: list results for users in a block as duplicate.

There are several bugs in this patch (I have not reviewed the module if this is the same):

• Status code has missunderstood - it's not a status of broken or not
• Security issue: Everyone has access to the view - I hope you are not running this code with non-admins!
• Filters are not correct, last checked is not of type date or I'm at least cannot create a filter with a value of 0 to exclude unchecked links
• The report is for node links only, blocks and comments are missing
• Pager items is 10, should be 50
• We cannot sort by columns that have no index. Major performance issues will occur and on TEXT fields we are technically not able to add indexes
• We need to add some indexes, at least to status code, status and wherever it's possible...
• View should be disabled by default
• This is not an view that has been exported from D7!? How have you created the view?
• D7 Views 3.0 seems to support translation of string *yeah*
• I'm wondering that the base_table = 'node' and not linkchecker_link... not sure what this does

I have fixed a few of them, but still playing with the views GUI...

This patch adds indexes to linkchecker_link table, fixes some of above issues and adds some descriptions to make it more pretty.

OPEN:

• I'm wondering that the base_table = 'node' and not linkchecker_link... We don't need the node table at all. This seems to be wrong from the table joins I see in views.
• The report is for node links only, blocks and comments are missing
• last_checked is a unix timestamp and seems not supported by views, see #1266398: Creating filter for Unix Timestamp field. A workaround has been implemented with type numeric.
• If a link is used in more than one node the Operation links need to show all nodes with these broken link.
• Security: If link settings are shown, must depend on permissions.

Re-attach for testing bot.

+

git patch format

Committed the index changes to latest DEV as they are not only for views.

Ok, nkschaefer's module has small differences. There are at least a few interesting additions we should also implement.

I'd also planed to make the status code messages more user friendly. He already implemented something like this to show the standardized error messages. My idea was to change the way how the current _linkchecker_isvalid_response_code() function works. It should become reusable for other use cases like his. The main idea was to extend/change the $responses array by more information that also allows translation and can tell a user what they can/must do if they see a specific code.

  $responses = array(
    100 => array(
      'title' => t('Continue'),
      'help' => t('Please do foo, if you see this error code. The reasons for this message could be foo and bar and can be solved by doing foo.')
    ),
    ...

@nkschaefer: Do you like to work more on this views patch to get it in? Currently it really has some open to do's we must solve first. I would also love to see a views block as this was another request. After the 'page' view is ready this seems to be a 3 minutes job, we should just integrate.

Setting CNW for the todo's listed in #22.

#30: D7-Views_integration_for_broken_node_links_report_git.patch queued for re-testing.

Marked #726006: Filtering results in admin/reports/linkchecker by link content / status / node type / etc as duplicate. We can implement filters with views exposed filters.

A few steps closer to this feature. UNION support is not available in views per #1873796: UNION support. Implemented a workaround for both queries.

+      'filter' => array(
+        'handler' => 'views_handler_filter_in_operator',
+        'options callback' => 'linkchecker_views_get_ignore_response_codes',
+      ),
...
+  $handler->display->display_options['filters']['code']['value'] = array(
+    drupal_map_assoc(preg_split('/(\r\n?|\n)/', variable_get('linkchecker_ignore_response_codes', "200\n206\n302\n304\n401\n403")))
+  );

Requires it's own handler in linkchecker or we cannot use the existing linkchecker_ignore_response_codes variable.

• We also need to write our own permission handler. Just checking for 'access broken links report' is not ok.
• Empty result set text t('No broken links have been found.') need to be added
• +, +, +

Just posting latest code.

Wonderful functionality. Should we start testing it?

tried to apply this without success on the latest dev....I ended up manually applying it.

It seems to me the biggest piece missing is any reference to the node...the [nid] in the view does nothing because there's no node data in the view itself.

So, here is my attempt to finally have this issue fixed.

here is what I did:

• I changed the last_updated column to date field, so that it can be better displayed/customized
• I added an "operations" custom field that will display the list of operations like the build in report and replaced the "Custom text" field with this one
• Changed the default status to disabled and changed the URLs to the built-in URLs so you just have to enable it and alter the view definition to use views instead of the build in

Note: I had to almost clone some of the code from _linkchecker_report_page in order to regenerate links and maybe this could be refactored so to be written only once. Also in that "cloning" I lost the $account feature as I don't know what it is about... I think this $account stuff is the only missing stuff in order to views to perfecly replace the build in views.

Thanks for following up here. We should write up an issue summary. There are still some critical things to do and nobody should run this code without except you are site admin. The code should not used with any normal user with limited permissions (access bypass security issues exists).

Just from memory

• Custom access handler (cannot committed without)
• Split the one view with two displays into two independed views to cleanup the pre execute hook and allow more flexibility in custom displays
• Empty result set text
• + other things I may missed

So, let's focus on the blocker: "Custom access handler". Can you explain? (I don't know the linkchecker module and I just broadly know views api)

I see you may solved it a bit in _linkchecker_operations(), but I thought we need something different as every single link need to be checked if the user has access to it. In views UI the user is able to select a permission. This is not ok and need to work like the menu access callback. I'm not sure about the permission checks we have on the links shown in the reports table. It was really complex to implement this. Without a code review I cannot say for sure if your code works like current report page.

So, I think this is too hard for me, expecially considering I just need the last_checked column in the main report page and I don't use user's report pages.

I propose another solution: what about splitting this task in "views integration for main report" and "views integration for user's report" so that we can simply remove from my patch the user report stuff and try to have this code committed? I think this would be a good option for users while we wait for someone with better views/linkchecker knowledge to also support the user's report "tweaks".

If you agree I will submit a new patch removing the user/*/brokenlinks view.

This issue has 2.5 years, so I think it is better to narrow it down and make progresses instead of looking for the perfect world.

If it would be a real requirement for someone I guess it would have been done already. As I know implementing one or the other view is no difference in complexity.

Well, it is a real requirement for me. I need to show the last checked column. You closed my feature request pointing to this issue, but this issue is not solving my problem (as it had no working patches), so I tried to fix it to help it being committed.

I think the admin report is simpler because it doesn't need to check for user permissions, that is the missing / blocking brick for this issue.

I need a solution for the last_checked in the admin report and I would have liked to have it committed because I don't like to branch modules. That's all. You are free to reject feature requests or patches, but don't tell me that this is not a requirement for anyone ;-)

Above patch works, but has security issues. If you only run it as admin it's fine.

What I say is that the security/permission issue is mainly related tp the view for user/*/brokenlinks.
THe admin view is currently tied to a permission "Access broken links report" so it doesn't have security issues. Even if you assign this permission to anonymous at most you see links but don't see node, comments or blocks you don't have access to (only the links). I think this is an expected/lecit behaviour that doesn't raise security concerns.

Instead I agree that the user broken link page would need some more work to be reproduced with views and I agree this could be a blocker for the view to be committed, that's why I proposed to push the admin report part of the patch and then leave to someone else the user report part.

If you are willing to review and apply a patch involving only the admin report I will provide a clean patch for that.

"Access broken links report" is a security issue!

Can you elaborate? I don't understand the security issues with that permission and the content we display.

If we change it to "administer content" & "access broken link report" or to "role is administrator" would this fix your security concerns?

I just want to see some of this commited and then we can talk about enhancement: also more developers will be attracted once part of the feature they want is there.

Not sure as we kept this access bypass secret in past. Not sure if security team allows this. Only safe permission is administer site.

OK, so what do you think if I clean the patch to leave only the admin report view, disabled by default and with the "administer site" permission? This would work for me. If this is acceptable for a first commit then I'm happy to prepare and test the patch.

Not sure if your answer to my last question was yes or no... btw I removed the user report and changed the admin report to require "administer site" permission.

I do not commit broken code, feature regressions, feature reductions or unready code. Sorry.

It's hard to collaborate to this project :-(

I don't agree with you about this patch having broken code, feature regressions, feature reductions or unready code. I will simply go back to my simple one liner local change to enable the last_changed column.

My only criticism is that you wasn't clear in your messages about what is acceptable and what is not and so I wasted hours trying to produce a patch you liked.

Thank you anyway.

Not really.

I cannot commit any of these patches as it reduces features (admins cannot allow users to see the global broken link report) and the previously mentioned access handler is also missing (security issue, unready code). The patch may add the last_checked column and this is not what the most of the users need and we have very limited space in the already overloaded table. Such a column need to be removed and you can add it on your server manually. I also tried using last_checked with date format and this does not allow excluding "-1" values if I remember correctly (possibly broken patch). However I'm willingly to learn from your code; if you found a way to implement this as I failed to implement it myself.

The only patch that is acceptable is a 1:1 replacement of the current reports. I see the reasons why this feature is useful for some people to customize the output and that's why I accept this community effort. However the interest seems to be very limited as nobody really try to complete the outstanding todo's and I have personally no need to move all this stuff to views. If you need the views integration you can complete the outstanding work and I will review the complete patch for sure.

I accept your opinion. There's nothing I can do to convince you of my opinion as you are the owner of this project and it is your right to decide what to commit and what to not commit.

This does not remove a single feature from the module as the view is optional and if you don't enable it the code is unchanged. If you enable it you don't get any security issue because the view has "perm = administer site".

This is not a replacement as it doesn't remove the core reports. I would agree with you if this we removed the core code.

My needs do not worth the work you ask in order to be committed (I tried to provide a patch simply because I misunderstood your position and I thought we could have it committed with the changes I added): at most I will create a new project with the view integration code, so to share with other something useful.

Thank you for the great module!

For anyone interested in testing using some limited view integration I created an integration project: Link checker Views.

I hope we will be able to complete the requirements for this integration to be merged back to linkchecker project so to close that child project, but if this won't be the case the few users needing this integration have something to work with, without relying on patches.

Leaving this issue opened, closing it, moving it to linkchecker_views is up to you: as you feel it's better.

It would be a lot more useful for all not wasting time with duplicating efforts by working here on the issue.

I did not read the full discussion. However, I am very much interested in this feature. Right now the link checker report seems to include all nodes, published and unpublished. With views integration an admin could easily create a new report that only shows broken links on published nodes.

My use case: I have a huge archive of unpublished content (news etc.) that I need to keep, but which is inaccessible to the general website visitor. However, I need to keep the published nodes free of dead links. The current report is not helpful to me because I cannot easily identify the nodes that need my attention (= are still published)...

Right now the link checker report seems to include all nodes, published and unpublished.

This is incorrect. Links from unpublished nodes will be removed.

Thanks for the clarification. When is the update triggered because it does not seem to be instantly. I cleared caches etc. I think I have configured cron to only run linkchecker once at night so if it triggers on a cron run then I might just have to wait a little longer...

Immediatly after the node is unpublished it is no longer shown in the reports.

Unfortunately, that is not the case in my site. I just tested a variety of scenarios and links do not get removed from the report when nodes are unpublished. They do get removed however when the node is deleted. I tried nodes with only one revision, multiple revisions, nodes that only had one dead link on it and the same dead link was not included in any other nodes etc.

I took a look at /includes/linkchecker.pages.inc and the function linkchecker_admin_report_page does not distinguish in the sql query if a node is published or not. The table linkchecker_links has a status field in it, but all my entries have status 1. I do not see how that table should work though either because a dead link recorded in that table could appear on multiple pages that are recorded in linkchecker_nodes. So if a broken link is recorded in linkchecker_links, where do you determine if it appears in a node that is active/published?

Sorry if I am missing something obvious. I am normally just working on the frontend and not backend.

J.

The entries must be removed in hook_node_update(). There is a condition that matches unpublish state and removes all references. Are you using any revisioning modules? Workbench only works in the latest release.

Hmh, that might explain it. I am using Revisioning (6.x-3.15) and Workflow (6.x-1.5). I guess these modules are not supported then. Which brings me back to how great views integration would be ;-)

Please open a new request. Workbench Moderation module IS supported by linkchecker. Revisioning module has never been tested and may need to be added, too. This has nothing to do with this issue here.

Thanks hass. Opened under https://drupal.org/node/2067317. I hope that the description covers the issue we discovered here reasonably well...

Will this ever be added to D6?

Integration with views would be great, and I'd hope not to need a separate module

I've been looking and playing with this. I think the access problem can be solved by using node as the base table and adding a relationship to the linkchecker_link table. That way the node_access tag is added to the query.

This requires a hook_views_data_alter() of the node table to add the relationship to linkchecker_node, and linkchecker_link is joined to linkchecker_node in hook_views_data() from the linkchecker_views module.

Is there still interest in bringing this back in to linkchecker?

I think the access problem can be solved by using node as the base table and adding a relationship to the linkchecker_link table. That way the node_access tag is added to the query.

No, that is not possible. See my comments #21 and #22, please.

Is there still interest in bringing this back in to linkchecker?

Yes, highly interrested in getting this feature implemented before the D8 port starts.

The latest patch you should work on is #36. The later ones are invalid.

This is simply a reroll of #36 against the current dev.

Here is what I think can be done with the patch from #75 (originally #36).

If we add the 'node_access' tag in linkchecker_views_pre_execute() then for the user report, nodes will be filtered out by modules implementing hook_node_grants().

    $query->addTag('node_access');

The view itself would need to further control access to unpublished nodes, probably with the view own unpublished content permission, if needed.

The subquery there limits comments to those created by the current user, so I don't think there's anything to do with comments, and if the node is no longer accessible then the node_access control will prevent the comment owner from seeing the links on the comment.

The limitations of this approach are

• That the name of the view and display are hardcoded into the pre_execute hook, so you're forever limited to the one view and the two displays.
• From what I can tell, there is no field-level access control. So even if we could prevent access to restricted nodes, there may be available nodes that hide fields with the field permissions module or other means. These fields are still scanned and there's nothing in place to hide any links they contain. This is true in the current implementation of the module. I could create a node, and admin could add comments and links in a field I don't have access to, and then I could see the links in the user report even though I can't see the field. I'm not sure where this case would ever come up. You do have to trust the site admins to know what they are doing.
• Additionally, the union of the node, comment and block tables make it pretty hard to do much with the view for the admin report. The same goes for the user report with the node and comment tables.

The alternate approach suggested by @bago that uses the node, comment and block(?) tables as base tables has a larger but cleaner views integration, and makes the views much more flexible and extensible. It still has the field access limitations, and therefore like the current implementation and hass's approach has to limit access to only users trusted to view all fields on the content they have access to. Also, you'd probably need separate views to display node, comment and block links.

Personally I like bago's approach because it makes the node object available in the view.

Feedback?

I implement the patch of #75 but no group "broken links" appears for the field "show" in ".../views/add". How I can start with this great idea.
I cant see any error messages in recent logs or somewhere.
Please give me a hint.
(I have installed 7.x-1.2+2-dev of link checker)

The attached patch used the patch from #30 as a starting point. I've read through the entire thread and addressed all the issues that were raised along with many other issues that I identified while working on the issue. Here is a summary of all changes this patch makes to the module:

• Defined all views handlers and plugins in the .info file.
• Updated the admin and user report menu items to use a new _linkchecker_access() function for the access callback.
• Updated the linkchecker edit link settings menu item to use a new _linkchecker_access_edit_link_settings() function for the access callback.
• Renamed the _linkchecker_user_access_account_broken_links_report() function to _linkchecker_access().
  This was done to follow similar access related functions found in core (node_access, user_access, etc.)
• Updated the _linkchecker_access() function to grab a user object from the path if one exists.
  This was done in order to validate access for pages generated by views.
• Updated the _linkchecker_access() function to work for both admin and user reports.
  This was done so a single function could handle page level access for consistent permissions and ease of updating.
• Renamed the _linkchecker_user_access_edit_link_settings() function to _linkchecker_access_edit_link_settings().
  This was done for naming consistency among access related functions.
• Updated the _linkchecker_access_edit_link_settings() function allowing users with the 'access broken links report' permission.
  This was done for consistency since edit link settings links were displayed on the broken links admin report without any other checks. We could change this so that both the 'access broken links report' and 'edit link settings' permissions are required if desired.
• Implemented hook_views_api().
• Added a _linkchecker_response_codes() function that returns an associative array of HTTP status code messages keyed by the HTTP status code.
  This was done so that we could leverage this list of options within views filters.
• Updated the _linkchecker_isvalid_response_code() function to get the list of HTTP status codes from the _linkchecker_response_codes() function.
• Moved the _linkchecker_is_internal_url() function to the .module file.
  This was done so the function could be used by views without having to include another file.
• Added a views handler for an edit block link field.
  This was done so that the edit block link only appears for users with access.
• Added a views handler for an edit link settings link field.
  This was done so that the edit link settings link only appears for users with access.
• Added a views handler for an add redirect link field.
  This was done so that the add redirect link only appears for users with access.
• Added a views handler for the URL field to display a access denied message.
  This was done to simulate the entire row being replaced with an access denied message, but that is not easily accomplished in views. The best way to handle row level access is to create a linkchecker access system similar to how the node access system works. In drupal 8, I think it would be best to make links entity and utilize the entity access system. This would also make everything natively available in views reducing much of this code.
• Updated the views handler for the code filter adding a list of code options to filter on.
  It seemed silly to have a views filter pull filter values from a variable. Plus, that also limited all views to sharing the same filter and prevented doing exposed filters.
• Implemented hook_views_data().
  • I declared the linkchecker_link table as a base table.
    This was done so views can be created via the UI.
  • I've added relationships to nodes and comments.
    This was done so that nodes and comments can be fully leveraged.
• Implemented hook_views_plugins().
• Implemented hook_views_pre_render().
  This was done to add the status message related to the number of unchecked links that is seen on the current reports to views pages that have the linkchecker_link table as the base table.
• Implemented hook_views_default_views().
  This adds default page views similar to the current admin and user reports. I customized the views export adding conditions around components dependant on other modules such as comments and redirects. This prevents the view from showing the 'broken or missing handlers' error if one of the modules is not installed.
• Added a Linkchecker access plugin for deterining if the views can be accessed by the user.
  This essentially just calls the _linkchecker_access() function.

@todo
There are a few things that are done in the current reports that are difficult to replicate in views and that time didn't allow me to tackle.

• The user report is not currently filtered, so the user mostly sees access denied messages.
  Author contextual filters can be added to views and do work, but there isn't currently an OR opperator for contextual filters, so a link would have to belong to a node AND a comment to show up. There are a few issues in the Views issue queue for adding an OR opperator or somehow leveraging contextual filter values in normal views filters, but these solutions would require a patch or dependency on another module. I think the best option forward is to have three separate tables on the user report for node, comment and block links.
• Results are not currently grouped by URL.
  Grouping by URL can be done in Views and works, but it's not the same as the current report and other fields are not aggregated together. Views aggregation is another possible solution.
• Performance and row filtering.
  Performance doesn't seem to be an issue on my system, but a lot of access queries could be reduced by creating a linkchecker access system similar to how the node access system works. This would allow for row filtering at the database level.

I forgot to mention that there is a bug with the comment_access() function that causes comment edit links to appear when no comment exists. #2542798: Edit comment link causes PHP notices and is visible by unauthroized users if no comment exists and #2558435: comment_access() doesn't validate the $comment object both have patches that address this issue.

Thanks, I just did a quick test with the patch from #78 and it looks OK so far.

What would the test bots say...

per #78 there are todos.

@hass,

I'd love to hear your feedback on the three todo's and my suggestions for fixes. Note that adding a linker_access table would also solve both the first and third issues. I'd love to have an agreed way forward before putting in any more time.

@jantoine: thank you for your contribution! This made it possible to add a broken links block to the editor dashboard.

I did a quick review too, and ran into these notices:

Notice: Undefined variable: comment in linkchecker_views_default_views() (line 57 of /home/harold/.../modules/contrib/linkchecker/views/linkchecker.views_default.inc).
Notice: Undefined variable: comment in linkchecker_views_default_views() (line 118 of /home/harold/.../modules/contrib/linkchecker/views/linkchecker.views_default.inc).
Notice: Undefined variable: comment in linkchecker_views_default_views() (line 179 of /home/harold/.../modules/contrib/linkchecker/views/linkchecker.views_default.inc).
Notice: Undefined variable: comment in linkchecker_views_default_views() (line 228 of /home/harold/.../modules/contrib/linkchecker/views/linkchecker.views_default.inc).
Notice: Undefined variable: comment in linkchecker_views_default_views() (line 281 of /home/harold/.../modules/contrib/linkchecker/views/linkchecker.views_default.inc).
Notice: Undefined variable: comment in linkchecker_views_default_views() (line 380 of /home/harold/.../modules/contrib/linkchecker/views/linkchecker.views_default.inc).
Warning: Invalid argument supplied for foreach() in menu_unserialize() (line 400 of /home/harold/.../includes/menu.inc).

I guess this has to do with the comment module being disabled?

@MrHaroldA,

Glad everything worked for you. Yes, it appears you're suffering from the bugs I ran into with the comment module and views. The issues listed in #79 contain patches that should eliminate these messages.

I found another one today. Users with access to the view get a "Permission restrictions deny you access to this broken link." text instead of the URL. This can be "fixed" by granting the "Access broken links report" permission, but I don't want our editors to access the default broken links report page.

The (error) messages, HTTP codes and other information are available, it's just the URL which is blocked.

... but then again, even the root user gets the "Permission restrictions deny you access to this broken link." message in the broken links report?

@MrHaroldA,

This isn't that different than the default user report. The main difference is that it includes many links the user doesn't have access too, hence the message. One way I have cleaned this up was to add a filter on the URL field filtering out any records that begin with "Permission restrictions". This should help clean up the user report. What we really need to do here, I think, is implement and access table for links similar to node access and entity access. Waiting to hear back from Hass on this issue.

What we really need to do here, I think, is implement and access table for links similar to node access and entity access.

I'm not quite grasping this. Why are we checking access to a link? Shouldn't we check view permission for the page where the link is found instead?

The dependency on the "Access broken links report" permission should be removed too; this should only affect if you're able to visit admin/reports/linkchecker, not if you can see URLs in a view.

On a side note, I can't seem to be able to translate the messages.

Every link need to be checked. Otherwise field permissions may not verified and users may get access to urls they are not allowed to access.

I have re-rolled the patch in #78 against the latest dev release instead of against the 7.x-1.x. This is due to changes the patch makes to the linkchecker.info file that conflict with modifications Drupal's release process makes to the file.

I've also gotten approval to tackle the remaining @todo items mentioned in #78. It may be a bit before I actually get to them, but now would be a great time to get feedback before I start implementation.

This is also bugged:

-    'access arguments' => array('access broken links report'),
+    'access arguments' => '_linkchecker_access',

I'd guess the access callback should be '_linkchecker_access' and the arguments should be empty.

Here's a little rewrite of the #78 patch that fixes the issue in #90.

Here's another patched patch that fixes these undefined indexes:

+  $comment = module_exists('comment')) {
+    $comment = TRUE;
+  }
+  if (module_exists('block')) {
+    $block = TRUE;
+  }
+  if (module_exists('redirect')) {
+    $redirect = TRUE;
+  }

+  $comment = module_exists('comment');
+  $block = module_exists('block');
+  $redirect = module_exists('redirect');

Forgot to hack the line numbers too ;)

What version of the module is this patch created against because I'm finding it is unable to run against the dev and stable versions. Running the simplytest.me build fails to run also, reporting an error in patching the project.

It was against this commit:

commit 5918e55bc40964e516da06fc9a5a913750ec7f73
Author: hass <hass@85918.no-reply.drupal.org>
Date:   Sat Jan 17 01:48:27 2015 +0100

    Issue #2303177: "Back to Top" Page anchor being reported as a 404 error

Here's an updated version.

I've made a couple of minor adjustments to @hemlo's latest patch. I was getting errors around the comments edit button. I've also moved the default view to an "Advanced view" and added exposed filters. The patch is run on the 1.2 tag.

I made a minor update to the default view name. This patch still runs against 1.2 so it will fail automated testing.

Here's the same patch as above applied to commit 10ffeaf0bd8c8ba9102d10187e49f57acec2b4ad

Removed the redirect column from the report table. This is for the 1.2 tag.

Here's the patch against 10ffeaf0bd8c8ba9102d10187e49f57acec2b4ad

The patch #113 does not work on the latest dev

Patch #113 was missing hook_views_api() whilst patch #112 actually included other changes in the latest dev snapshot (when compared to 7.x-1.2). So here's an actual re-rolled patch made against latest dev, including the changes from #113 and hook_views_api() (which was in patch #112 and everything else before!).

Appreciate the great works you guys have done.

To whom it may be concerned how to add a new option for HTTP status code filter.

What you need to do is to add following code to the linkchecker.module file at line 2443.

new status code => 'Description about the code'

For example, I need to add the new status code of '-10061' to the filter options, below are codes I add into the line 2444.

-10061 => '(10061) - The target machine actively refused it.',

Other than an extra line in the .info file, the patch in #116 applied cleanly for me. Also, all the functionality worked as expected for me.

However, the users of the site I am adding this to will be wanting the capability of being able to filter based on the URL.

So, I am attaching an updated patch that adds the URL as an exposed filter for the views, and I also removed the extra line at the end of the .info file.

@oadaeh It would be very useful to have an interdiff file. :)

I made a quick and dirty interdiff by just diff'ing the patch files directly.

Thanks for the patch. I tested the views filters at /admin/reports/linkchecker_adv:

* URL
* HTTP status code
* Error message

and found that they all worked as expected. I reviewed the code (in the interdiff only) and didn't see anything wrong and it is following Drupal coding standards so marking RTBC.

This time I went through the entire patch instead of just the interdiff since no one explicitly RTBC'ed it before (though I imagine @oadaeh reviewed it before updating the patch). I noticed one thing:

+++ b/linkchecker.module
@@ -2456,60 +2471,68 @@ function _linkchecker_link_check_status_filter($url) {
+    -10053 => '(10053) - Connection timed out. Time to First Byte Timeout.',
+    -11001 => '(11001) - Host not found',

Juts noticed that the code for these is negative yet the value in the parentheses shown is positive.

I updated the patch to fix the display of those two codes. I also corrected a spelling error I spotted while correcting the other and removed the unnecessary files declaration for linkchecker.drush.inc in linkchecker.info while attempting to correct a patch reject error.
The updated patch and interdiffs (119 <-> 124 & 116 <-> 124) are attached.

Reviewed - working as expected and a great addition to the module.

I tested the patch in #124 with the same steps as #122 and it worked as expected. The code changes from #124 make sense. Marking RTBC.

+++ b/linkchecker.info
@@ -2,5 +2,10 @@ name = Link checker
-files[] = linkchecker.drush.inc

looks not related

I do not see where #88 has been implemented.

Wow, it's been a while since I did anything with this, but I'm going to try to finish this up in the next week or two.

Great, thanks for taking this up again @oadaeh!

Patch at #124 worked for me after having to manually edit the .info file (why is linkchecker.drush.inc removed?)

Eric

Adding a cleaned up patch from #124 - after reinstating the linkchecker.drush.inc file.

The earlier patch works when I apply it to the git clone version - but not when applied to the downloaded version.
this one works for the downloaded version.

Rewrite of the patch in #133 below - as that was not creating the correct directories.

Patch

Hello all.
When I was working on this last, I determined that the permissions/access control of the patches from #124 and before were not correct. I updated the code locally so that it is correct, but then I determined that the select query was also not correct, presenting duplicates of the chosen records. That was about the time my contract for this work ended, and I have not had spare personal time to work on this, so I never corrected that last problem.
If those two problems have not been corrected in the recent patches (I can't tell based on the terse comments), this issue is not RTBC and still needs work.

@oadaeh Can you please provide more details of the permissions and query issue.
If you could provide some steps to reproduce the bug, I can try and work to fix the possible bugs.
Thanks.

Interdiff between version #124 and #136.

+++ b/linkchecker.info
+++ b/linkchecker.info
--- ../linkchecker 3/linkchecker.info	2018-08-20 07:38:05.000000000 +1000

This line can be removed otherwise it will lead to a failed patching in Drupal CI and other environments.

https://www.drupal.org/pift-ci-job/1253391

Patch Failed to Apply - No results available yet.

fatal: git apply: bad git-diff - inconsistent old filename on line 5

Here's a version of patch 136 that does apply.

Here's a version of 142 that removes a PHP 8.x warning (requiring a reference to a function, when an object is being passed anyway)

Gah, sorry, ignore me, something else was amiss. Patch in #141 was fine!

D7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.

Everyone can apply the patch above (not tested by the maintainers, tested by the community) to their D7 projects.
If the issue remains relevant for D10+ versions, merge requests with proposed solutions for a new module version (D10+) are welcome in a new follow-up issue.

Thanks!