Redirect loop after upgrading from 2.1.4 to 2.3.1

After installing 2.3.1, going to the root of the site creates a redirect loop. Loops do not occur on any other pages -- i.e. you can land on item pages, admin, etc and everything seems to work fine.

This problem has been confirmed in all browsers and from outside the library (it is not a cookie or cache issue). I have checked omeka_options, truncated the session table, and removed .htaccess but none of these measures appears to change the behavior

Uncommenting SetEnv APPLICATION_ENV development does nothing so Omeka is not perceiving an error.

However, if I restore the old DB and files, everything works great. Where should I be looking for a solution? Thanks,

kyle

Have you set a custom homepage in Navigation? If you have, does setting that back to [Default] resolve the problem?

We're making progress. I had set a custom homepage and setting it to [Default] did help. The public side mostly seems to work with the proviso that I need to do something about the homepage and that clicking on a tag causes a hanging process described below.

It appears I misspoke about being able to get into admin -- I must have been looking at another session before the migration when I thought it worked.

Anyway, if I try to log into admin, it just hangs. CPU gets pegged with a mysql process. Mysql processlist shows an entry that includes 'SELECT COUNT(DISTINCT(tags.id)) FROM omeka_tags AS tags
LEFT JOIN omeka_records_tags AS `reco....' for each time I try to enter. If I click on a tag from the public side, it also hangs and creates a similar process. I can wait as long as I want and the processes don't seem to go away. CPU stays pegged.

We've had previous reports of extremely poor performance when counting tags (as happens on the admin home page).

If you're comfortable applying a patch, you can try this fix for the problem. After applying the patch, you can go to admin/upgrade and you'll be prompted to update the database. Doing this won't affect your ability to do a "real" upgrade in the future.

That did the trick -- thanks!

kyle

Out of curiosity, roughly how many tags and items do you have in your site? The slowness problem seems to mostly be relating to scaling in tags and assignments of tags to items, and it'd be interesting to know how many you have that ground things to such a halt.

Not so many -- I'm only showing 12,351 tags and 16,031 items.

However, two tags have been used over 10,000 times and 10 tags have been used 800 times or more just in case the number of times an individual tag has been used is relevant. This is legit as they're used to link items in a complex dataset