Upgrading to 2.2.2 - Database and 404 problems

Hi,

I've had some trouble upgrading two different Omeka instances from 1.5.2 to 2.2.2 and would be extremely grateful for some help!

For Omeka instance "A", when prompted to upgrade the database (the last step in the upgrade instructions), I receive the database upgrade error message: "SQL error in migration: Mysqli statement execute error : Duplicate column name 'added'." I've tried:

  • Connecting the instance to a different backup of the database
  • Modifying a line of code in "application/migrations/20100810120000_detachCollectorsFromEntities.php" as described in this post: http://omeka.org/forums/topic/upgrade-to-14-db-error-duplicate-column-name-added
  • Connecting the instance to a different database backup in which I have removed every single "added" column!

The same "duplicate column name" issue occurred when my predecessor tried to upgrade from 1.5.2 to 2.1.4 back in March 2014.

For Omeka instance "B", I am just receiving a 404 message. When I go to .htaccess and uncomment RewriteBase and input the instance address, I receive a totally blank page in the browser.

Does anyone have suggestions for other things to try? Please let me know if I can provide any more information.

For the first one, could you give the full stack trace after the "Duplicate column name 'added'" message?

For the second one, did you uncomment RewriteBase after trying it with it commented? It might be worth a try leaving it commented out, if you haven't.

Thank you very much for your help!

Here is the stack trace for the first one:

#0 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Db/Statement.php(303): Zend_Db_Statement_Mysqli->_execute(Array)

#1 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)

#2 [internal function]: Zend_Db_Adapter_Abstract->query('ALTER TABLE `li...')

#3 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db.php(79): call_user_func_array(Array, Array)

#4 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db.php(282): Omeka_Db->__call('query', Array)

#5 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db.php(282): Omeka_Db->query('ALTER TABLE `li...')

#6 /ip/liblilly/www/omekaCollectionsTest2/application/migrations/20120224000000_unEntityExhibitBuilder.php(48): Omeka_Db->queryBlock('ALTER TABLE `li...')

#7 /ip/liblilly/www/omekaCollectionsTest2/application/migrations/20120224000000_unEntityExhibitBuilder.php(21): unEntityExhibitBuilder->_updateSchema()

#8 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db/Migration/Manager.php(231): unEntityExhibitBuilder->up()

#9 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db/Migration/Manager.php(111): Omeka_Db_Migration_Manager->_migrateUp(Object(DateTime))

#10 /ip/liblilly/www/omekaCollectionsTest2/application/controllers/UpgradeController.php(43): Omeka_Db_Migration_Manager->migrate()

#11 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Action.php(516): UpgradeController->migrateAction()

#12 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('migrateAction')

#13 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))

#14 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(101): Zend_Controller_Front->dispatch()

#15 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()

#16 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Application.php(79): Zend_Application->run()

#17 /ip/liblilly/www/omekaCollectionsTest2/admin/index.php(28): Omeka_Application->run()

#18 {main}

For the second, I just set the debug.exceptions to true in 'application/config/config.ini.' When Rewritebase is commented out I receive the 404 page and when uncommented I receive the following notice:

Notice: Use of undefined constant HELPERS - assumed 'HELPERS' in /ip/liblilly/www/omekaExhibitionsTest/plugins/Neatline/plugin.php on line 47 Warning: require_once(HELPERS): failed to open stream: No such file or directory in /ip/liblilly/www/omekaExhibitionsTest/plugins/Neatline/plugin.php on line 47 Fatal error: require_once(): Failed opening required 'HELPERS' (include_path='/ip/liblilly/www/omekaExhibitionsTest/application/libraries:/ip/liblilly/www/omekaExhibitionsTest/application/models:.:/usr/local/php5.3.26/lib/php:/ip/liblilly/www/omekaExhibitionsTest/plugins/ExhibitBuilder/models:/ip/liblilly/www/omekaExhibitionsTest/plugins/ExhibitBuilder/libraries:/ip/liblilly/www/omekaExhibitionsTest/plugins/SimplePages/models:/ip/liblilly/www/omekaExhibitionsTest/plugins/CsvImport/models:/ip/liblilly/www/omekaExhibitionsTest/plugins/NeatlineTime/models:/ip/liblilly/www/omekaExhibitionsTest/plugins/Neatline/models') in /ip/liblilly/www/omekaExhibitionsTest/plugins/Neatline/plugin.php on line 47

Hmm. For the first one, it's not quite the same as in the post you linked to -- problem is coming from a different file, 20120224000000_unEntityExhibitBuilder.php in migrations.

The analogous change from that post would be to change

ADD <code>added</code> TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',

to

MODIFY <code>added</code> TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',

in line 43 (and possibly similarly in the subsequent lines). I don't quite understand exactly what's happening there, but that might be something to try.

Thank you for the suggestion. There was some movement, but unfortunately, I haven’t resolved the problem yet.

I went through this block and switched each line in order from ADD to MODIFY:
private function _updateSchema()
{
$this->db->queryBlock(<<<SQL
ALTER TABLE {$this->db->Exhibit}
ADD added TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
ADD modified TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
ADD owner_id INT UNSIGNED DEFAULT NULL,
ADD INDEX owner_id (owner_id);
SQL
);
}

Currently the error message reads: “SQL error in migration: Mysqli statement execute error : Unknown column 'record_name' in 'lilly_collections_search_texts'” It is stuck here whether or not one or more lines switched to MODIFY.

I did receive a few different error messages as I was going through the lines. I’ll mention them here in case it might be useful:

MODIFY added TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',

  • Resulted in duplicate column name ‘modified’

MODIFY added TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
MODIFY modified TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',

  • Resulted in duplicate column name ‘owner_id’

MODIFY added TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
MODIFY modified TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
MODIFY owner_id INT UNSIGNED DEFAULT NULL,

  • Resulted in Mysqli statement execute error : Unknown column 'record_name' in 'lilly_collections_search_texts'”

Here also is the stack trace for the current message:
SQL error in migration: Mysqli statement execute error : Unknown column 'record_name' in 'lilly_collections_search_texts'
#0 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Db/Statement.php(303): Zend_Db_Statement_Mysqli->_execute(Array)

#1 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)

#2 [internal function]: Zend_Db_Adapter_Abstract->query('ALTER TABLE `l...')

#3 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db.php(79): call_user_func_array(Array, Array)

#4 /ip/liblilly/www/omekaCollectionsTest2/application/migrations/20120813000000_changeToRecordType.php(22): Omeka_Db->__call('query', Array)

#5 /ip/liblilly/www/omekaCollectionsTest2/application/migrations/20120813000000_changeToRecordType.php(22): Omeka_Db->query('ALTER TABLE `l...')

#6 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db/Migration/Manager.php(231): changeToRecordType->up()

#7 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db/Migration/Manager.php(111): Omeka_Db_Migration_Manager->_migrateUp(Object(DateTime))

#8 /ip/liblilly/www/omekaCollectionsTest2/application/controllers/UpgradeController.php(43): Omeka_Db_Migration_Manager->migrate()

#9 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Action.php(516): UpgradeController->migrateAction()

#10 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('migrateAction')

#11 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))

#12 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(101): Zend_Controller_Front->dispatch()

#13 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()

#14 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Application.php(79): Zend_Application->run()

#15 /ip/liblilly/www/omekaCollectionsTest2/admin/index.php(28): Omeka_Application->run()

#16 {main}
Is there anything else I might try? Thank you!

This is indeed progress, but still very odd. What you posted indicates that the upgrade process got through a couple more steps of the table migrations, but is failing after another upgrade step didn't do its changes, which affected a later step.

It got through all the changes related to the original problem okay, and got through several more additional steps in the update, then hit this new snag. Basically, one much later upgrade step adds a new database column. Then another step changes its name. But the original new column was never created.

So it looks like parts of the standard upgrade process are happening okay, and others are not, without a discernible pattern so far.

That makes me a little hesitant to try additional hacks to the migrations just to get it to work, since it seems like there might be more fundamental issues.

If you have direct access to the database, it help to see the structure of the search_texts column as it exists right now in the process.

Also, you mentioned that your predecessor had encountered similar issues. Are you working from an upgrade of a database from before they made their attempts, or from wherever they got to and are picking up from there? If you have a clean backup of the database from before any upgrade attempts were made, that might make a cleaner starting point.

Hi,

Thank you for explaining where this stands so far! I believe I am working the the original 1.5.2 version of the database. The previous assistant had made a second copy of the database and attempted the upgrade using that copy. I have made my own copies of the original and have made my attempts with those.

The library I work for has an account on our university's MySQL server. I can access it through SSH or phpMyAdmin. I copied down search_texts in phpMyAdmin here. X indicates a blank field:
Field, Type, Collation, Attributes, Null, Default, Extra
id, int(10),X,unsigned,No,None,auto_increment
record_type, varchar(30), utf8_unicode_ci,X, No, None, X
record_id, int(10), X, unsigned, No, None, X
public, intyint(1), X, X, No, None, X
title, tinytext, utf8_unicode_ci, X, Yes, NULL, X
text, longtext, utf8_unicode_ci, X, No, None, X

Indexes:
Keyname, Type, Unique, Packed, Field, Cardinality, Collation, Null, Comment
PRIMARY, BTREE, Yes, No, id, 0, A, X, X
record_name, BTREE, Yes, No, record_type/ record_id, 0/0, A/A, X, X
text, FULLTEXT, No, No, text, 0, X, X, X

Interestingly, I tried clicking the upgrade button once more this morning, after leaving it for 4 days. Rather than the “SQL error in migration: Mysqli statement execute error : Unknown column 'record_name' in 'lilly_collections_search_texts'” message, I got "SQL error in migration: Mysqli prepare error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'INDEX owner_id (owner_id)' at line 5." I changed everything back to ADD and then changed to MODIFY one by one. It is now back to the “SQL error in migration: Mysqli statement execute error : Unknown column 'record_name' in 'lilly_collections_search_texts'” message.

Here is the stack trace for the new message I encountered this morning:

SQL error in migration: Mysqli prepare error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'INDEX owner_id (owner_id)' at line 5
#0 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Db/Statement.php(115): Zend_Db_Statement_Mysqli->_prepare('ALTER TABLE `li...')

#1 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Db/Adapter/Mysqli.php(388): Zend_Db_Statement->__construct(Object(Zend_Db_Adapter_Mysqli), 'ALTER TABLE `li...')

#2 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Adapter_Mysqli->prepare('ALTER TABLE `li...')

#3 [internal function]: Zend_Db_Adapter_Abstract->query('ALTER TABLE `li...')

#4 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db.php(79): call_user_func_array(Array, Array)

#5 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db.php(282): Omeka_Db->__call('query', Array)

#6 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db.php(282): Omeka_Db->query('ALTER TABLE `li...')

#7 /ip/liblilly/www/omekaCollectionsTest2/application/migrations/20120224000000_unEntityExhibitBuilder.php(48): Omeka_Db->queryBlock('ALTER TABLE `li...')

#8 /ip/liblilly/www/omekaCollectionsTest2/application/migrations/20120224000000_unEntityExhibitBuilder.php(21): unEntityExhibitBuilder->_updateSchema()

#9 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db/Migration/Manager.php(231): unEntityExhibitBuilder->up()

#10 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db/Migration/Manager.php(111): Omeka_Db_Migration_Manager->_migrateUp(Object(DateTime))

#11 /ip/liblilly/www/omekaCollectionsTest2/application/controllers/UpgradeController.php(43): Omeka_Db_Migration_Manager->migrate()

#12 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Action.php(516): UpgradeController->migrateAction()

#13 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('migrateAction')

#14 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))

#15 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(101): Zend_Controller_Front->dispatch()

#16 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()

#17 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Application.php(79): Zend_Application->run()

#18 /ip/liblilly/www/omekaCollectionsTest2/admin/index.php(28): Omeka_Application->run()

#19 {main}

Lastly, I checked with our IT support regarding a warning message in phpMyAdmin since I thought it might be related to the Omeka issues: "Your PHP MySQL library version 5.1.46 differs from your MySQL server version 5.0.83." They claim that there are no known issues cause by having them out of sync, though I thought I would bring this up just in case.

Thank you again for your help.

Hmm. I was hoping some straightforward pattern would show up, but maybe not. I'm going to guess that that new error about SQL syntax was just a stray typeo from changing that migration file.

So, with where you are, it gets to the migration file called 20120813000000_changeToRecordType.php. It seems to have already been completed based on the info you gave, but it is trying to run anyway.

The brute force method at this point might be to just keep hacking around errors as they come up. You're about half way through all the migrations (13 more to go).

To work around this one, open up that 20120813000000_changeToRecordType.php file and comment out this line:

$this->db->query($sql);

That will just skip over that sql query and move on to the next migration. To just get it done, we might be looking at stepping through each one and finding the best workaround.

I'd also be curious to know how many rows are currently in your schema_migrations table. There should be one row for each migration that was successful, with 37 total once the entire process finishes happily. Right now, if you have more than 23, that probably indicates that more migrations were partially completed.

If brute force is the only way, let's give it a shot! I'm extremely grateful for your help in squashing the issues that come up.

Before commenting out the line in 20120813000000_changeToRecordType.php, there were 23 rows in the schema migration table and now there are 27.

The error message is now:
SQL error in migration: Mysqli statement execute error : Unknown column 'relation_id' in 'lilly_collections_taggings'

#0 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Db/Statement.php(303): Zend_Db_Statement_Mysqli->_execute(Array)

#1 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)

#2 [internal function]: Zend_Db_Adapter_Abstract->query('? ALTER ...')

#3 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db.php(79): call_user_func_array(Array, Array)

#4 /ip/liblilly/www/omekaCollectionsTest2/application/migrations/20121015000001_renameTaggings.php(20): Omeka_Db->__call('query', Array)

#5 /ip/liblilly/www/omekaCollectionsTest2/application/migrations/20121015000001_renameTaggings.php(20): Omeka_Db->query('? ALTER ...')

#6 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db/Migration/Manager.php(231): renameTaggings->up()

#7 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db/Migration/Manager.php(111): Omeka_Db_Migration_Manager->_migrateUp(Object(DateTime))

#8 /ip/liblilly/www/omekaCollectionsTest2/application/controllers/UpgradeController.php(43): Omeka_Db_Migration_Manager->migrate()

#9 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Action.php(516): UpgradeController->migrateAction()

#10 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('migrateAction')

#11 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))

#12 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(101): Zend_Controller_Front->dispatch()

#13 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()

#14 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Application.php(79): Zend_Application->run()

#15 /ip/liblilly/www/omekaCollectionsTest2/admin/index.php(28): Omeka_Application->run()

#16 {main}

Off we go, then! Getting closer!

This one looks like it might be a bit tricky, since my first guess is that half of the migration file migrations/20121015000001_renameTaggings.php ran, and half didn't.

To check, look in the database for the table taggings. If that exists, check to see if there is a column record_id, and a column record_type.

If all of that is there, go into migrations/20121015000001_renameTaggings.php and comment out the _first_ query, but not the second. That is, comment out the first instance of

$this->db->query($sql);

but leave the second one to run. Then, pull that migrate lever again and we'll see how far we get.

Hi there,

Both the record_id and record_type columns existed in the taggings table. Here is the result I received after commenting out necessary line. Glad to be making progress!

SQL error in migration: Mysqli statement execute error : Table 'lilly_collections_records_tags' already exists

#0 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Db/Statement.php(303): Zend_Db_Statement_Mysqli->_execute(Array)

#1 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)

#2 [internal function]: Zend_Db_Adapter_Abstract->query('RENAME TABLE `...')

#3 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db.php(79): call_user_func_array(Array, Array)

#4 /ip/liblilly/www/omekaCollectionsTest2/application/migrations/20121015000001_renameTaggings.php(23): Omeka_Db->__call('query', Array)

#5 /ip/liblilly/www/omekaCollectionsTest2/application/migrations/20121015000001_renameTaggings.php(23): Omeka_Db->query('RENAME TABLE `...')

#6 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db/Migration/Manager.php(231): renameTaggings->up()

#7 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Db/Migration/Manager.php(111): Omeka_Db_Migration_Manager->_migrateUp(Object(DateTime))

#8 /ip/liblilly/www/omekaCollectionsTest2/application/controllers/UpgradeController.php(43): Omeka_Db_Migration_Manager->migrate()

#9 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Action.php(516): UpgradeController->migrateAction()

#10 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('migrateAction')

#11 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))

#12 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(101): Zend_Controller_Front->dispatch()

#13 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()

#14 /ip/liblilly/www/omekaCollectionsTest2/application/libraries/Omeka/Application.php(79): Zend_Application->run()

#15 /ip/liblilly/www/omekaCollectionsTest2/admin/index.php(28): Omeka_Application->run()

#16 {main}

Yay progress! This looks like migration in application/migrations/20121015000001_renameTaggings.php probably happened already, so in that file comment out the second $this->db->query($sql); line, too.

The database migration was successful!!!!

Now there is something funky going on with the theme. We were using a modified version of the Rhythm 1.3 theme. When trying to view public pages, I receive this error:

Fatal error: Call to undefined function settings() in /ip/liblilly/www/omekaCollectionsTest2/themes/seasons/common/header.php on line 5

The unmodified Rhythm 1.3 theme produces the same error, but the Rhythm 2.0 theme works perfectly. Do you think I might need to update some of the functions as described here: http://omeka.org/forums/topic/fatal-error-after-upgrade-to-213 since we are moving from 1.5.2 to 2.2.2?

Hooray!!!

Yep, themes will need to be updated. Most likely, you'll want to start with the new Rhythm theme and recreate whatever modifications you had done with the old one. Here's a list of common tasks, and there's also a link there to a list of new function names.

Ok, that'll be something for me to work on. I'll just make some CSS changes to the new theme.

Do you think you might be able to help me with the 404 for the other instance I've tried to upgrade? It seems like this might be an even more difficult starting point... I can also seek some help from someone who is knowledgeable about Omeka on campus.

The message reads:

"The requested URL /ip/liblilly/www/omekaExhibitionsTest/index.php was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request."

That looks a little odd, in that the message about the URL looks like it is the full file path, not just the URL that the server usually returns. That also looks a little like the files aren't where they should be. I'd double-check directly on the server that the expected Omeka files are there, and maybe ask your sysadmin if they have insights.

I just needed to edit RewriteBase to make it work! Thank you again for all of your help! I'm looking forward to learning about themes next :)