Corrections Plugin - error

I get an error when the metadata field I choose to allow a correction for is an Item Type Element that I’ve created. For instance, I have an Item Type “Audio” to which I’ve added an Element “Lyrics.” "Lyrics’ shows up on the Corrections Config page and I check it and save. From the front-end, I see the Corrections link and form correctly but when I submit:

exception 'Omeka_Record_Exception' with message 'Cannot find an element with an ID of '84'!' in /var/www/omeka/application/models/Mixin/ElementText.php:312
Stack trace:
#0 /var/www/omeka/application/models/Mixin/ElementText.php(508): Mixin_ElementText->getElementById(84)
#1 /var/www/omeka/application/models/Mixin/ElementText.php(473): Mixin_ElementText->_getElementTextsToSaveFromPost(Object(ArrayObject))
#2 [internal function]: Mixin_ElementText->beforeSaveElements(Object(ArrayObject))
#3 /var/www/omeka/application/libraries/Omeka/Record/AbstractRecord.php(251): call_user_func_array(Array, Array)
#4 /var/www/omeka/application/libraries/Omeka/Record/AbstractRecord.php(210): Omeka_Record_AbstractRecord->delegateToMixins('beforeSaveEleme...', Array)
#5 /var/www/omeka/plugins/Corrections/models/CorrectionsCorrection.php(53): Omeka_Record_AbstractRecord->__call('beforeSaveEleme...', Array)
#6 /var/www/omeka/plugins/Corrections/models/CorrectionsCorrection.php(53): CorrectionsCorrection->beforeSaveElements(Object(ArrayObject))
#7 [internal function]: CorrectionsCorrection->beforeSave(Array)
#8 /var/www/omeka/application/libraries/Omeka/Record/AbstractRecord.php(277): call_user_func(Array, Array)
#9 /var/www/omeka/application/libraries/Omeka/Record/AbstractRecord.php(531): Omeka_Record_AbstractRecord->runCallbacks('beforeSave', Array)
#10 /var/www/omeka/application/libraries/Omeka/Controller/AbstractActionController.php(188): Omeka_Record_AbstractRecord->save(false)
#11 /var/www/omeka/plugins/Corrections/controllers/IndexController.php(30): Omeka_Controller_AbstractActionController->addAction()
#12 /var/www/omeka/application/libraries/Zend/Controller/Action.php(516): Corrections_IndexController->addAction()
#13 /var/www/omeka/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('addAction')
#14 /var/www/omeka/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#15 /var/www/omeka/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(105): Zend_Controller_Front->dispatch()
#16 /var/www/omeka/application/libraries/Zend/Application.php(384): Zend_Application_Bootstrap_Bootstrap->run()
#17 /var/www/omeka/application/libraries/Omeka/Application.php(79): Zend_Application->run()
#18 /var/www/omeka/index.php(23): Omeka_Application->run()
#19 {main}

This doesn’t happen when I choose any Dublin Core Metadata.

What do you think? I see this page but I think I’ve narrowed the problem down to using an Item Type Element rather than a Dublin Core metadata field.

I’ve tried to spend some time troubleshooting this, but the code is too labyrinthine for me. It seems that maybe only Dublin Core fields get shown for several functions when the record type is not an item. For an item and a collection, e.g., the “Item Type Element” fields show up with the all_element_texts function, but not records whose type is CorrectionsCorrection which is what the Corrections plugin sets itself up as. Same with getElementById.

But it’s quite difficult track down where this is coming from.

Any advice on how to think about solving this bug?

So far, it looks like it’s something askew in how Corrections uses the ElementText Mixin. I haven’t tracked it down, but I should have some time to devote soon (since it’s not an RRCHNM plugin, work on this has to be deferred to off-hours, but I’m still all about fixing these issues).

1 Like

OK more observations:

  • In the ‘element_sets’ table, ‘Item Type Metadata’ has the value "Items’ for ‘record_type’. By contrast, Dublin Core has the ‘record_type’ of NULL. This seems to make “Item Type Metadata” only be available to Items and not to CorrectionsCorrection ‘record_type’ as used in the ‘element_texts’ table.

If I change the ‘record_type’ of “Item Type Metadata” to NULL, the Corrections Plugin works with the special metadata associated with Item Types.

Changing the ‘record_type’ to NULL, though, makes the “Item Type Metadata” show up where it shouldn’t in the Admin, e.g., with Collections, etc.

How can we force Corrections to also use “Item Type Metadata” even though it’s entries aren’t “Items”?

This seems relevant:

If I wanted to try to hack this, it might make sense to allow the ‘record_type’ field in the ‘element_sets’ table to have more than one record type listed. Right now, you can have NULL or one record type (like Item or Collection). It’d be good if you could have a (json?) list of multiple record types, e.g., “Items, CorrectionsCorrection”

Where in the code does the record_type get looked-up to determine if a record uses an element set? We could probably easily make it just parse the json or comma-separated list, etc. What do you think of that?


My cludge for right now:

In the ‘element_sets’ table, I’ve changed the value for the field ‘record_type’ to NULL for the ‘Item Type Metadata’ record. This has the effect that the ‘Item Type Metadata’ fields (or "elements’) becomes available not only ti Items, but all “records” including “CorrectionsCorrection” records. As a side effect, unfortunately, ‘Item Type Metadata’ fields also then become available to “Collections” and the tab for them shows up under "Collections. So I also added this css to my “/admin/themes/default/css/style.css”

body.collections #section-nav li a[href='#item-type-metadata-metadata'] { display:none; }
which works well.

We should change the way records are associated with Element Sets: there should be a record_elements table with a field foe ElementSetId, and another field for RecordType. That way, CorrectionsCorrection, e.g., could associate itself with ‘Item Type Metadata’


Thanks for doing all that digging around. What you describe about the db changes makes sense, and I’d certainly like to avoid having to do that. Some things are built into the queries from the ElementText mixin that could also avoid it. I’ve made some progress, but haven’t nailed it down yet.

1 Like