• My server error logs show countless errors with a missing wp_shepherd_tec_tasks table. This table is indeed absent in my database. Is this a table that should be present for The Events Calendar? And if so, how can it go missing and how do I restore it?

    Its absence doesn’t seem to affect TEC frontend features at all. And I have another website with TEC, where the table is present in the db, but that website also has Event Tickets, so it might be that the table is related to Event Tickets. So maybe there’s nothing to the error message. On the other hand, it occurs dozens of times in the logs, so at the very least it’s a slight performance hit while php deals with the error.

    Here’s an example error:

    28.09.2026 03:54:42 thrillercomplot.nl [client XXXX:XXX:XXX::] AH01215: stderr from /home/strato/http/power/rid/93/92/528929392/htdocs/thrillercomplot.nl/wp-cron.php: WordPress database error Table 'dbs13302830.wp_shepherd_tec_tasks' doesn't exist for query SELECT DISTINCT(id) FROM wp_shepherd_tec_tasks WHERE action_id = 665 made by do_action_ref_array('action_scheduler_run_queue'), WP_Hook->do_action, WP_Hook->apply_filters, ActionScheduler_QueueRunner->run, ActionScheduler_Abstract_QueueRunner->run_cleanup, ActionScheduler_QueueCleaner->clean, ActionScheduler_QueueCleaner->delete_old_actions, ActionScheduler_QueueCleaner->clean_actions, ActionScheduler_QueueCleaner->delete_actions, ActionScheduler_DBStore->delete_action, do_action('action_scheduler_deleted_action'), WP_Hook->do_action, WP_Hook->apply_filters, TEC\\Common\\StellarWP\\Shepherd\\Provider->delete_tasks_on_action_deletion, TEC\\Common\\StellarWP\\DB\\DB::__callStatic, TEC\\Common\\StellarWP\\DB\\DB::runQueryWithErrorChecking, TEC\\Common\\StellarWP\\DB\\DB::TEC\\Common\\StellarWP\\DB\\{closure}, call_user_func_array

    The page I need help with: [log in to see the link]

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Support Darian

    (@d0153)

    Hi @florismk

    Thanks for reaching out.

    Yes, that table should be there. The Events Calendar creates wp_shepherd_tec_tasks on its own, and Event Tickets isn’t required for it. On a calendar-only site the table simply stays empty, which is why your front end works fine.

    The errors come from WP-Cron’s routine cleanup of old scheduled actions. That cleanup checks this table once for every action it deletes, which is why the error repeats so frequently.

    Why the table is missing

    TEC only creates the table when the stored version number for it is absent. Your site still has that version number, so TEC assumes the table already exists. This usually happens when a database cleanup plugin, or a migration or restore, removed the table but left the option behind.

    Deleting that stored version makes TEC recreate the table on the next admin page load.

    How to fix it

    1. Back up your database.
    2. Delete the stored version. In phpMyAdmin, run:
       DELETE FROM wp_options WHERE option_name = 'stellar_schema_version_stellarwp-shepherd-tec-tasks';

    Or with WP-CLI:

       wp option delete stellar_schema_version_stellarwp-shepherd-tec-tasks
    1. Open any wp-admin page, such as the Dashboard. TEC will create the table immediately.
    2. Confirm it worked by running:
       SHOW TABLES LIKE '%shepherd%';

    If your site uses Redis or Memcached object caching, flush that cache after step 2, since the old option value may otherwise still be served from memory.

    After that, the errors should stop.

    As always, please test it first on a staging version of your live site.

    Let me know how it goes!

    Thread Starter Floris

    (@florismk)

    Thanks, @d0153 ! I’ve succesfully applied your solution. Indeed, after deleting the option the table reappeared the moment I loaded admin. I’m diving back into the logs tomorrow for an unrelated issue, but I expect those errors to have vanished. I’ll check back in to confirm after I’ve seen it.

    (The unrelated issue is recurring hours-long server outages, which my hosting provider refuses to investigate because the error logs contained WP-related errors, and they don’t support WP. So I had to solve these errors before I can proceed with getting them to look into it. It’s anyone’s guess how they think this minor db issue would cause prolonged 500 errors…)

    • This reply was modified 4 days, 22 hours ago by Floris.
    Thread Starter Floris

    (@florismk)

    And of course, all errors disappeared from the logs from the moment I applied the fix onward. Worryingly though, the site outages also disappeared. Any chance the missing table problem might cause a 500 Internal Server Error?

    Plugin Support Darian

    (@d0153)

    Hi @florismk

    Thanks for your message, and good to hear it’s sorted out.

    To answer your question: yes, the missing table was at least part of what was causing the 500 errors. Each cleanup run was checking for a table that wasn’t there, which is enough to bring down the request.

    If the errors come back, send over the full log entries and I’ll take another look. There may be a second cause worth tracking down.

Viewing 4 replies - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.