Error fetching browse markup. 500 (Internal Server Error) after upgrading to 4.0.0

Hello,

I just upgraded from Omeka 3.x to Omeka 4.0.0. I use the Faceted Browse module, which has been working great so far. After the upgrade, and after updating the module to the latest 1.3.0 version, I get a Error fetching browse markup. 500 (Internal Server Error) when I navigate to the page where the faceted view is. What can the error be?

log:

ext Doctrine\DBAL\Exception\InvalidFieldNameException: An exception occurred while executing 'SELECT r0_.id AS id_0, r0_.title AS title_1, r0_.is_public AS is_public_2, r0_.created AS created_3, r0_.modified AS modified_4, r0_.resource_type AS resource_type_5, r0_.owner_id AS owner_id_6, r0_.resource_class_id AS resource_class_id_7, r0_.resource_template_id AS resource_template_id_8, r0_.thumbnail_id AS thumbnail_id_9, i1_.primary_media_id AS primary_media_id_10 FROM item i1_ INNER JOIN resource r0_ ON i1_.id = r0_.id AND (r0_.is_public = 1) LEFT JOIN `value` v2_ ON r0_.id = v2_.resource_id AND (v2_.is_public = 1) AND (v2_.property_id = 84) INNER JOIN item_site i4_ ON i1_.id = i4_.item_id INNER JOIN site s3_ ON s3_.id = i4_.site_id AND (s3_.id = ?) WHERE (v2_.value_resource_id IN (SELECT r5_.id FROM resource r5_ LEFT JOIN item_set i6_ ON r5_.id = i6_.id LEFT JOIN media m7_ ON r5_.id = m7_.id LEFT JOIN item i8_ ON r5_.id = i8_.id LEFT JOIN value_annotation v9_ ON r5_.id = v9_.id WHERE (r5_.title = ?) AND (r5_.is_public = 1)) OR v2_.`value` = ? OR v2_.uri = ?) GROUP BY r0_.id ORDER BY r0_.created DESC, r0_.id DESC LIMIT 25' with params [1, "I and my true love", "I and my true love", "I and my true love"]:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'i1_.primary_media_id' in 'field list' in [...]www/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:79

This is likely not an error in FacetedBrowse. You are missing the new primary_media_id field, so it appears that a specific migration didn’t run when you upgraded to Omeka 4.0. What version of Omeka did you upgrade from? Did you upgrade in an unusual way? Are there other pages that result in an error, like when editing an item with media?

I had to reverse to my previous installation because I don’t have the luxyry right now to have the site down.

I upgraded manually, by uploading the new folder to the FTP space, minus config, themes, modules, and then upgraded the single modules and theme. This is what I’ve always been doing for minor versions. I don’t have SSH access. I upgraded from Omeka S 3.2.3, and the Facet Browse page was (and is now that I’ve reverted it back to 3.2.3) working properly.

One thing I noticed before reverting is that the items weren’t showing in the backend, i.e. the list was empty. I did have the number right in the count, they just weren’t there. I appreciate it might not be a Faceted Browse issue. Nevertheless it might be a migration / database update that needs to be done and I’m not presented with the option of doing.

You should be getting automatically redirected to the upgrade/migrate page when you move to a new version, where you’d have to click a button to upgrade the database. If you aren’t being redirected, you can go directly to the URL /migrate within your Omeka S install.

OK, I’ll do that next time. The instructions for a manual upgrade say that one should go to /admin, which is what I did. Perhaps we could include the /migrate address for the benefit of others running into the same problem.

See here:

In your web browser, go to your site’s admin page (/myomekas/admin) and run any migrations that are needed.

Yeah. Normally what happens is, if you go to /admin, you get redirected to /migrate if an upgrade is required, which is why that’s the suggestion there.

The only thing I can immediately think of off the top of my head is that the version number stored in your database is wrong for some reason. We detect “needs an upgrade” status by comparing the version number in the code from the one stored in the database, so you really should be getting redirected. I guess very aggressively configured PHP caching could cause a similar problem (the version number not being updated, just from the other end), but you’d probably see more issues than just that.

We could have a note somewhere about how to “manually” check for upgrades like this, but we wouldn’t want it to be in the “normal” flow for users reading the instructions.

So, I just logged in to my PHPmyAdmin and I see that the key version in the settings table is set to 4.0.0.! What does that mean? As I said, I reverted back my installation to 3.2.3 (that is, my files, not my database, because I thought that hadn’t been touched). Everything works as before though. Shall I hardcode ‘3.2.3’ in that key now?

Probably that’s the source of the issue… not sure how that would have happened but yes, if you’re running 3.2.3 currently, editing the key there should get you the proper automatic redirect when you do next go to upgrade.

1 Like

I have run another (manual) upgrade and I can confirm that this time the /admin page redirected me to the /migrate one. All good.