Trouble Saving (and the Resolution)

Just wanted to let you know of a problem and the resolution we recently had:

When I attempted to save, I would get a string of code:

An error has occurred in saving the exhibit:

object(Omeka_Db_Exception)#140 (8) {

["e:protected"] => object(Zend_Db_Statement_Mysqli_Exception)#141 (6) {

"] => string(91) "Mysqli statement execute error : Incorrect integer value: '' for column 'featured' at row 1"

["string:private"] => string(0) ""

It seems that there was a bug which is preventing one from "saving" an exhibit that isn't featured. We were able to get around this by clicking "Yes" for "Is Featured" (leave "Is Public" as "no")

Hi, I'm going to need a bit more info to figure out what was causing this. Did this bug occur if you didn't choose a value for 'featured' on the form, or was it specifically when you chose to make the exhibit 'not featured'? Also, did that error output to an otherwise blank screen when you did that, or was it on a styled html page?


I'm getting the same error but with version .10. The steps that recreate the error:

1. Click Add Exhibit
2. Complete form leaving the default Exhibit is featured: to No.
3. Click either Save Changes or Add Section.

The exhibit can only be added if Exhibit is Featured is set to Yes.

Tested editing the Exhibit and the error continues to happen when ever I try to flip the feature to no.

Hope that helps with the debugging, let me know if there is any other information you need

What version of PHP are you running?

We are using PHP 5.2.6 on a CentOS 5 box with Apache 2.2.3. The database is MySQL 5.0.41 on a Windows NT box.

I can't seem to duplicate this error on my machine or our server. AFAIK the version of PHP you are running is fine. It's unlikely that we'll be able to fix this bug unless we can duplicate it somehow. What I would recommend is, if you want your exhibits to not be set to featured, you can change it manually through phpMyAdmin by running the following SQL statement:

UPDATE exhibits SET featured = 0 WHERE id = X (replace X with the ID of your exhibit).

Hope that helps to some degree.

Is there a way to get the actual values that are being inserted to be shown in error log file rather than just question marks. Currently the error log show the insert statement as

insert into 'exhibits' ('title', 'description', 'credits', 'featured', 'public', 'theme', 'slug', 'id') VALUES (?,?,?,?,?,?,?,?)

Is there some flag or something that can be switched so the text is shown rather than just question marks. It would help in tracking down the problem to see what is being sent for insertion.



The ? in the SQL query indicate usage of bound parameters, which is a security technique that prevents users from hijacking the database by putting in a value like '); DROP TABLE items;' or something equally nasty. Unfortunately the substitution takes place at a very low level within the Zend Framework code, so you'll only see the ? when it gives a dump of the query.

You could see what is being posted by putting this line at the top of your admin/index.php, and then submitting the form:


I added the statement you suggested above but then dug a bit more and added a couple of print statements to the application/libraries/omeka/db.php file. Specifically to the insert function.

It turns out that the values coming into the function are not being handled the same for the public and featured buttons. (They are both radio button with the same values so my guess is it should be.) See below for the results of a print_r($values).

Array ( [title] => test exhibit [description] => desctipiont [credits] => credit [featured] => [public] => 0 [theme] => [slug] => blahjadsdfklj [id] => 14 )

In this case I had set both public and feature to 'No'. The html form has 0 as the value for both public and featured. If you let me know where to look to find where the value parameter is set set I'll start digging around there.



What's happening is the form is for some reason posting an empty string '' for the featured form input, rather than posting a '0', which is what happens on mine and most other Omeka installations. If it tries to save the empty string to a database column that only accepts integers, it will barf.

Try converting line 83 of models/Exhibit.php from this:

$this->featured = (bool) $post['featured'];


$this->featured = (int) $post['featured'];

Let me know if that works.

Thanks, that seems to have fixed it. I'm just curious when you say the form is posting the empty string do you think this is this on the web server side or the browser? If it is the web server side would it be best for me to just change all of the (bool) $post['featured'] to (int) $post['featured'] for any/all the fields in the database that are set as tinyints. The image_type_id is having the same problem in the items table.

Yes I would recommend doing that. If you are using subversion, you could post a patch of the lines you changed to make it easy for us to incorporate those bug fixes into the next release. Otherwise, maybe you could post the file/line # of the lines you changed. Thanks!