Problem/Motivation

LinkCleanUp::doCleanupQueues() queries the {queue} table when a linkcheckerlink entity is deleted.

Core does not create this table until the first queue item is added. On a new site where nothing has been queued yet, deleting a link therefore causes:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'queue' doesn't exist

This can happen during normal content editing when a link is removed or content is deleted.

The existing kernel test hides the problem by creating the queue table manually in setUp().

Steps to reproduce

  1. Install Link checker and configure a field for link extraction.
  2. Do not run cron.
  3. Create content containing a link.
  4. Edit the content and remove the link, or delete the content.
  5. Check the logs for the missing queue table exception.

Proposed resolution

Before querying {queue}, check whether the table exists. If it does not, there cannot be any queue items to clean up.

Apply the same guard to linkchecker_post_update_remove_orphaned_queue_data().

Update the kernel test so it covers deleting links when the queue table has not yet been created.

Issue fork linkchecker-3624900

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

joelpittet created an issue. See original summary.

joelpittet opened merge request !171

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented
Status: Active » Fixed

The guard works better here so we don't try to loop over the results of a non-existing table.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

  • joelpittet committed 43eab5d9 on 2.1.x 
    fix: #3624900 Link cleanup fails when the queue table does not exist

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.