No data supplied for parameters in prepared statement MySQLi PHP

We recently enabled Contribution version 3.1 and now we can't add any items on our production system:

We're on php Version 5.4.31, and Zend Engine v2.4.0

###

Omeka has encountered an error

Zend_Db_Statement_Mysqli_Exception
Mysqli statement execute error : No data supplied for parameters in prepared statement

#0 /home/represen/public_html/artifacts/application/libraries/Zend/Db/Statement.php(303): Zend_Db_Statement_Mysqli->_execute(Array)
#1 /home/represen/public_html/artifacts/application/libraries/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)
#2 [internal function]: Zend_Db_Adapter_Abstract->query(Object(Omeka_Db_Select), Array)
#3 /home/represen/public_html/artifacts/application/libraries/Omeka/Db.php(79): call_user_func_array(Array, Array)
#4 /home/represen/public_html/artifacts/application/libraries/Omeka/Db/Table.php(648): Omeka_Db->__call('query', Array)
#5 /home/represen/public_html/artifacts/application/libraries/Omeka/Db/Table.php(648): Omeka_Db->query(Object(Omeka_Db_Select), Array)
#6 /home/represen/public_html/artifacts/application/libraries/Omeka/Db/Table.php(281): Omeka_Db_Table->fetchObjects(Object(Omeka_Db_Select))
#7 /home/represen/public_html/artifacts/plugins/Geolocation/models/Location.php(30): Omeka_Db_Table->findBy(Array)
#8 /home/represen/public_html/artifacts/application/libraries/Omeka/Record/AbstractRecord.php(383): Location->_validate()
#9 /home/represen/public_html/artifacts/application/libraries/Omeka/Record/AbstractRecord.php(533): Omeka_Record_AbstractRecord->isValid()
#10 /home/represen/public_html/artifacts/plugins/Geolocation/GeolocationPlugin.php(192): Omeka_Record_AbstractRecord->save()
#11 /home/represen/public_html/artifacts/plugins/Geolocation/GeolocationPlugin.php(444): GeolocationPlugin->hookAfterSaveItem(Array)
#12 [internal function]: GeolocationPlugin->hookContributionSaveForm(Array)
#13 /home/represen/public_html/artifacts/application/libraries/Omeka/Plugin/Broker.php(157): call_user_func(Array, Array)
#14 /home/represen/public_html/artifacts/application/libraries/globals.php(188): Omeka_Plugin_Broker->callHook('contribution_sa...', Array)
#15 /home/represen/public_html/artifacts/plugins/Contribution/controllers/ContributionController.php(393): fire_plugin_hook('contribution_sa...', Array)
#16 /home/represen/public_html/artifacts/plugins/Contribution/controllers/ContributionController.php(90): Contribution_ContributionController->_processForm(Array)
#17 /home/represen/public_html/artifacts/application/libraries/Zend/Controller/Action.php(516): Contribution_ContributionController->contributeAction()
#18 /home/represen/public_html/artifacts/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('contributeActio...')
#19 /home/represen/public_html/artifacts/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#20 /home/represen/public_html/artifacts/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(101): Zend_Controller_Front->dispatch()
#21 /home/represen/public_html/artifacts/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#22 /home/represen/public_html/artifacts/application/libraries/Omeka/Application.php(79): Zend_Application->run()
#23 /home/represen/public_html/artifacts/index.php(23): Omeka_Application->run()
#24 {main}

First guess from the errors makes me think something is wrong with the combination of Contribution and Geolocation. If you disable Geolocation, can you then save an item?

Sure, I'll do that, but the 3.0 version of Contribution worked 100% integrated with Geolocation.

Ok, that did prevent the error, and allow for an initial upload plus an edit to that upload.

Where in Geolocation should I go hunting and pecking? What can I do to get that working again, and maintain the use of Contribution 3.1?

Is Contribution 3.1 preparing statements differently?

My first guesses are that something's amiss in the hookAfterSave method in Geolocation, or something in how the map is added to contribution forms. At least that's where I'll be starting to look.

What version of Geolocation do you have, and am I guessing right that you have it configured to add the map to contribution forms? Relatedly, is this happening both when you use the contribution form, and adding an item normally on the admin side?

thanks

Geolocation 2.2.1

The contribution form loads the map, yep.

The error is only during a save/edit operation. Notably, this error does not happen on my VM, only on our production server.

I reactivated Geolocation and added an item through the admin. Worked great.

So it seems like the issue is on the Contribution side of editing.

Also, thanks!

Thanks for the info. Looks like there might be data from Contribution being posted that doesn't play well with how Geolocation processes data during the save. Hopefully this'll make it easier for me to recreate and nail things down.

Hmm...still can't reproduce it. You mentioned that it doesn't happen on your VM, but does on your production server. Could you tell more about the differences between those environments?

thanks

Patrick -- here is some output form both environments:

Production:
[represen@ramones ~]$ php -v
PHP 5.4.31 (cli) (built: Aug 13 2014 21:17:59)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
with the ionCube PHP Loader v4.6.1, Copyright (c) 2002-2014, by ionCube Ltd., and
with Zend Guard Loader v3.3, Copyright (c) 1998-2013, by Zend Technologies

[represen@ramones ~]$ mysql -h localhost -V
mysql Ver 14.14 Distrib 5.5.37, for Linux (x86_64) using readline 5.1

VM:
jherr@abi:~$ php -v
PHP 5.5.9-1ubuntu4 (cli) (built: Apr 9 2014 17:11:57)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies

jherr@abi:~$ mysql -h localhost -V
mysql Ver 14.14 Distrib 5.5.35, for debian-linux-gnu (x86_64) using readline 6.3

Patrick -- are you using Contribution 3.1 that was posted to GitHub, or Contribution 3.0?

Everthing is OK with Contribution 3.0, but we need 3.1's functionality.

Attempting a fresh install of Omeka and everything, I got this while enabling Contribution 3.1:

Mysqli statement execute error : Column 'multiple_files' cannot be null

I changed line 24 of Contribution/models/ContributionType.php to:

public $multiple_files = 0;

That got me past THAT error, but yielded a WSOD. When on the plugins page, however, it seems to be installed.

I've setup a basic contribution type, installed the latest Geolocation, attempted to add a public item through the non-admin.

Notice: Undefined index: Elements in /home/represen/public_html/artifacts_dev/plugins/Contribution/controllers/ContributionController.php on line 561

Fatal error: Unsupported operand types in /home/represen/public_html/artifacts_dev/plugins/Contribution/controllers/ContributionController.php on line 561

changed "$post['Elements'] += $currentElements;" to "$post['Elements'] .= $currentElements;"

( i write a lot of JS code, too.... easy mistake)

ANNNND, back to the original message:

Mysqli statement execute error : No data supplied for parameters in prepared statement

!!!

This is all on the Production system, using the latest and greatest of everything.

Debugging: finding this:
Notice: Array to string conversion in /home/represen/public_html/artifacts_dev/plugins/Contribution/controllers/ContributionController.php on line 561

Ah, I think I've finally seen the key thing -- The version of Contribution released by the Omeka team is only at v3.0.1, not v3.1.

It seems like you are working from a fork by Daniel Berthereau. Some aspects of that fork have been merged into Omeka's repo, but not all. If that's what's happening, you might try asking in the issues section on Daniel's repo.

I mention on line one of this forum posting that I'm using 3.1.

On this post, Daniel represents his changes as being what we'd need:
http://omeka.org/forums/topic/guest-users-edit-their-own-items

As a new person to the Omeka culture, it's impossible to know that Daniel has a fork, and is not the actual developer, given his post.

Anyway, it's that $item->getAllElementTexts() is returning a blank array.

Do you have any idea what I could do to make that return a data-full array?

getAllElementTexts just does what it says, there's not really changes to make to get it to do something different.

You're sure that the $item in this case has pre-existing metadata? (without knowing more about the fork, I assume this is for the purpose of editing a earlier contributed item)

Yes, I understand that making sure the $item has data is a way to make sure the object method returns a data-full array.

No, this is for an initial item post. Not an edit.

Sorry about the earlier confusion -- I hadn't remembered that Daniel's version bumped the version above what we have released and are working on, and the 3.0.1 / 3.1 is a switch we often see on the forums.

This reflects, actually, a shift in the Omeka ecosystem -- we're finding more and more people who interact with our plugins only via GitHub, and not our plugin release pages.

With a very few exceptions, the plugins we (the Omeka team) work on are under the "omeka" organization in GitHub, and official releases are on the list of plugins linked to above.

Patrick

Thanks, Patrick. I appreciate it, and that makes sense. I made the mistake of inferring that Daniel's post on the initial thread implied that his solution was ready for production use, and it was SO CLOSE, that I kept trying to make it work. I do wonder if PHP version has a play in this, but ... that's for another day.

Before starting down that path I got a fair bit into a custom plugin, and I'm going to look at hacking some PHP and SQL together for direct db writes. I've got data printing to screen, and was going to scratch a static script to POST to. I'd punt on the map, and do geolocation lookups with PHP, and a web service, or JS, and GOogle's lookup service. If my customer feels there is time to complete that path, I will, and I'm sure I'll have other questions I may post.

Thanks again,
John