Symphony.

My exact process to recreate it as follows:

1. Open up a section where there is an Unique Upload Field that is marked as optional.
2. Fill out the rest of the form as normal, ignoring the UUF.
3. Click save. Cannot be Null error.

If the field is set to required I get the error message as I would expect. Also, the changes I’ve made all save just fine.

Hm, I cannot reproduce your error, can you copy the error message?

Have you tried the normal upload field? Does that produce the same error?

Right. OK. So. I created a test section and it worked just fine. It contains all the field-types that are in the other section so it can’t be an incompatibility issue between extensions. It has to be an issue with my database, correct?

I’ve checked out the offending field in PHPMyAdmin but it’s a bit above my head so I took a screen shot and zipped it with the full error (attached).

Attachments:

Archive.zip

I’ve seen that error before, when I was debugging.

In my database, the mimetype CAN be null. It sounds a bit like your database has been set for a required field, but the field itself is set to not-required.

Have you tried changing the required property to required, saving, and putting it back again? I don’t know if the upload field actually changed the database for this, but it might be worth a shot.

In the meantime, I will take a look into how the table is actually built, to see if that might cause the error.

Update:

The table is built in field.upload.php (in symphony/lib/toolkit/fields/) in the following code:

    function createTable(){

        return Symphony::Database()->query(

            "CREATE TABLE IF NOT EXISTS `sym_entries_data_" . $this->get('id') . "` (
              `id` int(11) unsigned NOT NULL auto_increment,
              `entry_id` int(11) unsigned NOT NULL,
              `file` varchar(255) default NULL,
              `size` int(11) unsigned NULL,
              `mimetype` varchar(50) default NULL,
              `meta` varchar(255) default NULL,
              PRIMARY KEY  (`id`),
              KEY `entry_id` (`entry_id`),
              KEY `file` (`file`),
              KEY `mimetype` (`mimetype`)
            ) TYPE=MyISAM ; "

        );
    }

In here, it clearly sais: NULL for the values file, size, mimetype and meta.

Does your function look the same? If so, maybe the database has changed because of an update, or something? (That’s pretty much all I can think of)

I fixed it!

I double-checked the function and did the required/not-required save toggle but that didn’t do it. So I took another look at the database and compared it to what was supposed to be there. Nothing stood out so I looked at the error again…

It says size cannot be NULL. I checked what it was supposed to be and it was supposed to allow for NULL. So I changed it. Worked!

(I’m telling all of this because I’m leading up to this question: Is there a chance I’ve broken something else or set myself up for a future issue?)

So I changed it. Worked!

Yes, that’s what I thought. It is weird the database has it “wrong” though.. When the table is built, it clearly sais: allow for NULL.

I’m telling all of this because I’m leading up to this question: Is there a chance I’ve broken something else or set myself up for a future issue?

For as far as I can see, you’ve only set the value to what it’s supposed to be. The field itself sets it to the same value you just did, so it shouldn’t create any new issues.

The only thing I find really weird is how the table got that way. Have you updated from a previous version?

I’m glad it’s finally fixed though!

Yes, this was from 2.0.8RC3 to 2.1.0. I grabbed the files off GitHub when the notice about the final version came out in my RSS feed.

brendo hit the bull’s-eye.

This is actually a rare edge case, and I think nobody is to blame here. Due to changes in the core the size column must allow for a NULL value. Symphony’s updater caught all the standard upload field tables, but it couldn’t catch the Unique Upload field tables.

So I will try to replicate the updater logic in the extension and release a new version.

@dougoftheabaci:

Is there a chance I’ve broken something else or set myself up for a future issue?)

Definitely not. You just did the right thing manually.

@creativedutchmen: Thank you for your help on this!

Unique Upload Field updated to version 1.1 on 11th of August 2010

Please update to the latest version if you are using Symphony 2.0.8RC3 or later.

Unique Upload Field updated to version 1.2 on 12th of October 2010.

MySQL 5.5 compatibility, as described in this thread.

Why this extension is placed in the category “Events” instead of “Field types”?

Probably my fault. Sorry for that.

Unique Upload Field updated to version 1.3 on 10th of February 2011

user feedback on fail if file is too large?

Is this a feature request or a bug? What exactly do you mean?

I’m simply not getting any feedback from the system if the file is above the maxuploadsize.

If you try and hit those PHP limits with the standard Upload field, is there any difference? The Unique Upload field should behave exactly like the standard Upload field. So:

• If there is a difference in behaviour, it’s a bug in the Unique Upload field
• If they behave identically, one might take a look at Symphony’s standard (default) Upload field. In this case please post your problem on the Symphony issue tracker (because this field is not an extension but part of the core system).

I hit a problem with this today when I had two Unique Upload fields in the same section. If you use the same file for both, they are given the same file name as time() is the same (second) when they are both saved. This becomes a problem when you want to remove one of the files to replace it with a new one, since both fields reference the same physical file.

Perhaps this could be modified to use microtime() instead, or a combination of microtime() plus a random number, so reduce the risk of this occurring?

Very good spot, Nick! I will implement a "more unique" solution for the filename.