Field set to unique in table

[horst]

Hi, I have the need to set a field to unique as described here (point 2.)

It is a integer input within a repeater. I have set that field to match a minimum and maximum value and also input is required!

When trying to save the page with an already used value the page doesn't save that field and do not output any error or warning. It silently lost the data, even with debugging enabled in config.php.

What can I do to avoid this?

[ryan]

Uniques aren't officially supported by that fieldtype, so it's a bit of an unknown. But I would think we should be seeing an exception thrown (and error message at the top of your screen). Do you see anything related in your /site/assets/logs/errors.txt? Can you try switching back to the default admin theme, just in case something about the theme is causing an error to be suppressed. 

[horst]

Hi Ryan,

• Using the default AdminTheme with english language displays an ErrorMessage at the Top of the page: Duplicate entry '1002' for key 'data'

• Using the default AdminTheme with the german language pack do display nothing!

• Using the Metro AdminTheme with the german language pack do display nothing!

• Using the Metro AdminTheme with english language do display nothing, too!

Other Warnings/Errors, like 'Missing required value ...', 'Value is out of bounds ...' are always displayed as expected.
 
There are no entries in the Error-Logfile with this.

[ryan]

Using the default AdminTheme with english language displays an ErrorMessage at the Top of the page: Duplicate entry '1002' for key 'data'

This is what I'd expect to see. 

Using the default AdminTheme with the german language pack do display nothing!

This is kind of a mystery, as the language pack shouldn't make any difference here. I'll have to experiment and see what's up. 

Using the Metro AdminTheme with english language do display nothing, too!

I was going to go take a look at the MetroWire theme, but looks like it's no longer available for download. I'm getting a 404 when clicking the download link:

http://modules.processwire.com/modules/metro-wire/

[horst]

functional Link is: https://github.com/adamspruijt/metrowire

He has updated it in the Thread (only there).

[horst]

This is what I'd expect to see. 

  

This is kind of a mystery, as the language pack shouldn't make any difference here. I'll have to experiment and see what's up.

Ryan, did you find out something about that with the use of the language pack?

I'm fine with the default admin theme, but language pack would be fine.

[ryan]

I've looked into this, and don't think it's got anything to do with use of a language pack or admin theme. I tried executing the query manually in PhpMyAdmin and MySQL simply doesn't trigger an error when inserting duplicate values. It just skips the query. Maybe there are some conditions under which it will report an error, but not that I could find. I think the problem is that the query for inserting/updating fields looks like this:

INSERT INTO `field_test_unique` (pages_id, data) VALUES('17562', 'my-unique-value') ON DUPLICATE KEY UPDATE data=VALUES(data)

The "ON DUPLICATE KEY" part is where it's at. But we need that, otherwise we'd have to add another select to every insert/update just to see if something is already present. So it looks like any future fieldtype that supports a UNIQUE index would have to implement it's own savePageField() method with some more overhead to check things out and decide whether to insert or update. As a result, you can have a UNIQUE index right now, but it's just being enforced rather than reported. But making a new FieldtypeTextUnique or something like that would be a way to solve it pretty easily. 

[horst]

...

So it looks like any future fieldtype that supports a UNIQUE index would have to implement it's own savePageField() method with some more overhead to check things out and decide whether to insert or update.

...

But making a new FieldtypeTextUnique or something like that would be a way to solve it pretty easily.

Thanks for looking to this Ryan.

So may I go to the wishlist and add a 'FieldtypeTextUnique' to it, or is it allready on a list you have?

[ryan]

Here you go:

http://modules.processwire.com/modules/fieldtype-text-unique/

[kongondo]

Here you go:

http://modules.processwire.com/modules/fieldtype-text-unique/

Ryan,

I'm really impressed, amazed at your level of productivity, responsiveness (and generosity)!

[horst]

On 18.4.2013 at 5:45 PM, ryan said:

Here you go:

http://modules.processwire.com/modules/fieldtype-text-unique/

( this is the community from Ryans point of view )

[diogo]

 

(but wait! there is someone acting very suspicious...)

[horst]

On 18.4.2013 at 8:19 PM, diogo said:

 

(but wait! there is someone acting very suspicious...)

No, this isn't suspicious, it's me saying skoal.

[diogo]

[fmgujju]

Can we have Unique field setting same as Required under Input tab on any field? The reason is that if I need to have an email address or number type or other built-in field type then I cannot have unique and if I have to apply unique to the field then I have to use FieldtypeTextUnique field type and cannot utilize built-in type.

[ryan]

This option may be coming in the future. 

[ceberlin]

Since this is a calculated comparison, I would love a feature where uniqueness starts after the language tree. So that i can have unique fields within a language but I can still copy the whole language tree and copy the "unique" fields over.

/de/file-with-uniquefield#1

/en/file-with-uniquefield#1

[horst]

Actually you can build these functionality by using a Repeaterfield that holds your fields for en + de.

[Peter Falkenberg Brown]

Dear Ryan,

I'm using TextUnique on a field called 'account_name', and process that field through the API.

I don't check for duplicate values in the code, because I figured that the field type would throw an error.

However, instead of an error, the field value is set to blank whenever a duplicate value is typed in,

and the user hits save.

Does the uniqueness check require special API code as well?

Thanks,

Peter

[Peter Falkenberg Brown]

Dear Ryan,

As a follow up, the textunique field does catch the duplicate value when one uses the admin interface.

Peter

[Peter Falkenberg Brown]

Dear Ryan,

I added this code to my php file that saves the values, and it worked. Is there a different and better way to interact with textunique fields, via the API, or is the following code a good option?

            if ( $field->type == 'FieldtypeTextUnique' )
                  {
                  $field_value = $sanitizer->text($input->post->$field_name);

                  $check_field_dupe = '';
                  $check_field_dupe = $pages->get( "id!=$current_page_id,$field_name=$field_value" );

                  if ( $check_field_dupe->id )
                        {
                        $field_value_error  = 'yes';

                        $field_error_text .= "<span class='error_text'>
                                              '$field_value' is not available.<br>
                                              Please try something different.
                                              </span><br>
                                             ";
                        }
                  }
 

Thanks,

Peter

[Peter Falkenberg Brown]

Dear Ryan,

Another update.

My code worked above, against normal pages. That is, the code check for dupes worked against "non-deleted" pages.

However, after saving a value that was not a dupe in non-deleted pages, the value was still erased by the text-unique field,

after saving with the API call.

I discovered that the conflicting value still existed in a page in the Trash.

So, 'textunique' is included pages in the Trash, which should not happen, in my opinion.

Yours,

Peter

[ryan]

$pages->get() implies an "include=all". You'd want to retrieve your pages with a function that filters things. Try replacing your get() with a find()->first(); and I think that'll give you the results you want. 

$check_field_dupe = $pages->find( "id!=$current_page_id, $field_name=$field_value, include=hidden, check_access=0" ); 
if(count($check_field_dupe)) {
  // you found a duplicate that's not in the trash
}

Or you could continue to use get(), but check if it's in the trash after retrieving it: 

$check_field_dupe = $pages->get( "id!=$current_page_id, $field_name=$field_value" );
if($check_field_dupe->id && !$check_field_dupe->isTrash()) {
  // you found a duplicate that's not in the trash
}

[Peter Falkenberg Brown]

Dear Ryan,

I've been searching for the syntax for find()->first() and couldn't find it. I noted that your code above is:

$check_field_dupe = $pages->find( "id!=$current_page_id, $field_name=$field_value, include=hidden, check_access=0" );

... even though you mentioned find()->first(). I searched through the wire directory and couldn't find that usage.

Does your find() line above, with the hidden and check_access params, not include the trash? If so, that would work, I think.

Or if there's a param like "not isTrash()" that would be good too.

On your second example [!$check_field_dupe->isTrash()] -- I would think that if there were more than one page returned, in the array,

that we'd have to use a loop to check if each was in the trash. Is that correct?

I guess you're also confirming that the textunique field does indeed require additional API code, unlike the email field, for example.

Thanks for your help,

Peter

[Peter Falkenberg Brown]

Dear Ryan,

Also, am I correct in thinking that deleted user accounts do not go into the trash?

I using the same type of API call to check for duplicate user names and emails.

Thanks,

Peter