Lingering artifacts of deleted Sprout Forms plugin causing queue failure for updating search indexes

Question

I noticed I had a task failure notification that I couldn't clear in my Craft 3 cp for updating search indexes. Found this in queue.log:

2020-01-15 20:02:44 [-][41673][-][error][craft\queue\QueueLogBehavior::afterError] [26] Updating search indexes (attempt: 1) - Error (time: 0.000s): Class 'barrelstrength\sproutforms\elements\Entry' not found

I had installed Sprout Forms and also Sprout Email recently, but then disabled & removed them when they weren't quite what I was after. However, I see they've left some pieces of themselves in my database: tables sprout_addresses, sproutemail_notificationemails, sproutemail_sentemail, sproutimport_seeds, sproutreports_datasources, sproutreports_reportgroups, sproutreports_reports. (I had also installed Sprout Import on this site back when it was still running Craft 2 but it's long gone now, or I thought it was.)

Can I just drop these tables? And does that solve my queue problem? I'm tempted of course to just try and see, but don't know where there may be more bits of these plugins in my database or codebase that might cause trouble if I disappeared these tables. For example, I do see a FK relationship from the one existing row in sproutemail_notificationemails to a row in craft_elements; not sure what happens if I delete that row too.

Would be grateful for advice on the best approach here. Thanks in advance.

Answer 1

OK, as I mentioned in my comment from a few hours ago, I did delete the orphaned entries row, and all the leftover sprout* tables, plus a row in craft_elementindexsettings that had 'barrelstrength\sproutforms\elements\Entry' in the type column; none of that cleared my cp failures. I then searched all columns in all tables for '%barrelstrength%' and found a bunch of additional stuff, which I opted to delete (on dev!) one at a time to see what would happen. I don't have/need any Sprout plugins installed anymore at all, to be clear.

Deleting all the relevant rows in craft_fieldlayouts, craft_fields (plus the related rows in craft_fieldlayoutfields), and craft_resourcepaths didn't help. I finally went ahead and deleted the row in craft_queue, reluctantly, because I'm not real clear on how queue tasks work or are triggered. That did clear the error in the cp, but left me not totally confident that my search indexes were in fact up to date.

So, to be very sure, I used the CLI resave/entries command. Had to increase my PHP memory for it to be able to finish (I have about 11,000 entries), but it did, and now I've logged back into cp and I see it's working on the "Update search indexes" task again. Hooray! It's obviously going to take a while, but once that's done, I think I should also take the three hours to run a spider on my dev site here to be sure it doesn't find any 500 errors caused by my deleting database rows with wild abandon, and then I'll consider my problem solved.

After that, I'll get to do all this over again on production, while resolutely pretending I didn't see more random leftovers from Sprout Import when I searched all columns in all tables for '%sprout%'.

[Update, later: no 500 errors upon spidering. On production, it worked as a quick version of all the above shenanigans to delete anything in craft_elements with type like '%barrelstrength%' and then delete the one row in craft_queue that referenced the failed task. Having looked at what was happening in my database during the time it took to update search indexes after I resaved every single entry via CLI, I have a better sense of what's actually happening during that process, and 99% sure now that the CLI resave wasn't actually necessary. This quick fix also obviously skips over removing the various outdated Sprout-related data in my database, but For Science, I wanted to know if it would be possible to get queued tasks moving again within a couple of minutes rather than some hours, and the answer was yes... though I would not have wanted to skip the step of spidering a live site for 500 errors after manually deleting data from the database, if I hadn't taken that step on dev.]

@Ben, I'm very grateful to you for your quick reply to get me started on resolving my issue, but also please consider this comment a request for Barrel Strength to think about if there are ways to improve Sprout plugin uninstall cleanup—whether that's programmatic improvements or just making sure users know if there are steps we should take before uninstalling to prevent a situation like this. I installed Sprout Forms and played with it for just about three hours before deciding it wasn't right for what I was trying to do; it will end up having cost me considerably more time than that to be confident that the site is running as well after uninstalling as it was before installing. Thanks again.

Answer 2

UPDATE: This should no longer be an issue. All of our plugins have been reviewed and updated with more consistent uninstall behavior.

---

If you no longer have those plugins installed, you should be able to drop all of those tables without creating any new issues.

That may not clean up all of your data though, as the queue error is pointing to an orphaned Element. To see any orphaned elements you can run a query search for all Sprout elements on your elements table. The following may need to be adjusted if you have a different database prefix:

SELECT * 
FROM craft_elements
WHERE type LIKE '%barrelstrength%';

Deleting these Elements from your elements table should cascade and clean them up anywhere else they may be used in the database. Be careful with the following operations and be sure to test on a dev database to make sure everything works as you expect. There could be scenarios I'm not considering.

Once you find the Elements you want to delete update your query to just grab the Element IDs of the specific Elements you want. You could also query these ID values from the plugin-specific element tables if they are still in your database.

SELECT id
FROM craft_elements
WHERE type LIKE '%barrelstrength%'

To delete Elements you're going to pass those IDs to a delete statement. A standalone delete query will look something like this:

DELETE FROM craft_elements
WHERE id IN (1, 2, 3);

If you want to combine both queries since you're selecting the IDs from the same table that you are deleting from you can create a temp table to get around that. This can result in a slow query if you have a large number of elements. In that case, you could delete multiple batches of a smaller number of elements.

DELETE FROM craft_elements
WHERE id IN (
    SELECT tempElements.id
    FROM (
        SELECT id
        FROM craft_elements
        WHERE type LIKE '%barrelstrength%'
    ) tempElements
);

Again, please be careful when operating on the Craft database directly. Be sure to create backups, test on a development database, and review things closely. Craft has a highly relational data structure and plugins may behave in different ways in how they store their own data.

A less risky way of approaching this may be to write a short script and delete the Elements using the Element API:

foreach ($elementIdsToDelete as $elementId) {
  Craft::$app->elements->deleteElementById($elementId);
}