There was a problem and the fix I found somewhere here in the forums was to alter the version number in the plugins table from 2.0.4 to 3.4. (I documented the change to the table but not the link to the forum thread - sorry).

So I’m guessing that let the sql upgrade command sneak by without doing everything it needed - like insert the table I’m now missing.

Is there some sql we could run that would verify/correct the tables we have in the broken version?

The relevant things are in the database; updating the plugin’s files won’t really do anything.

If you identify the differences between what you have and a “normal” set of tables for the plugin, you can plausibly manually make the appropriate changes. You can look at the upgrade function of the plugin to see what was added in what versions: the two columns you mentioned are among them, but also 3 added columns on the exhibit_pages table.

Making sure the structures match is easy enough, but the Exhibit Builder 2 to 3 upgrade is significant and makes many changes to the structure of the tables… not knowing where you encountered your issue or exactly what you did to resolve it makes it tricky to say with certainty if simply adding those columns will work. In particular the 2-to-3 upgrade converts your existing exhibit layouts to the new block-based system, and it’s very possible that if your original error occurred during that part of the upgrade that your existing exhibits would not be correctly present. You might be able to tell whether this is the case now, if you can look at the pages in exhibits.

In general, it’s not a good idea to update the version number manually in the plugins table, unless you’re sure you know what the consequences are.

I was able to cobble together a working instance by making a clean instance from our 2.0.4 copy, upgrading that, activating all plugins except EB, then dropping the exhibit builder tables there, and pulling in the tables from an old working copy of Omeka 2.4.1 with a working EB 3.3.1 in it. We lost about 20% of our existing exhibits but we will be able to copy/paste the missing ones in from the broken upgrades we did. It will take quite a bit of work, but in the end we’ll recover.

I would not have manually changed the version number in the plugins table had I not found that as a workaround here in the forums and thought through the consequences more closely. I can no longer find that suggestion in the forums so I earnestly hope it’s been removed or edited to save others from my misery.

If you do run across or remember the thread you’re thinking of, do let us know.

In general the best option for fixing a plugin upgrade issue is to restore to the pre-upgrade database of the plugin, fix the issue (in the database or in the code of the plugin’s upgrade function), and re-upgrade. Sometimes, especially where a backup is not available, hacky solutions like commenting out portions of the upgrade that are already done can work. Manually updating the version number can work, but you have to be very clear on the state of the database and what upgrades you’re skipping by changing the value.