Buggy logic for Unique Custom Fields

[Tanner Moushey]

Hey Jake! Thanks for all your work here!

I just found a bug with the logic for maintaining unique custom fields. The issue is twofold: 1. It appears that the postCustomFieldUnique custom option does not store a default value. So even though the box is checked, isset( $field['postCustomFieldUnique'] ) returns false because the value was never stored. 2. Currently the program only checks to see if postCustomFieldUnique is set and returns true regardless of the value (even should it be false).

I have included a patch that fixes this issue and also refactors the conditional logic for easier reading.

[Tanner Moushey]

Just checking on the status here. Anything I can do?

[Jacob Snyder]

Updating version. This and last commit fix #26

→ <<cset d35249d58f86>>

[Tanner Moushey]

Awesome, thanks Jake! Also, just so you know, the issue I was experiencing with this bug was that no custom fields were unique. So while this allows for non-unique custom fields, it also solves a bug where fields marked unique as the default were not being stored as unique.

[Jacob Snyder]

I was only able to reproduce the opposite, but your version is more stable and clearer overall, so it is bound to work better, and also be easier to maintain. Thanks!