Whenever a user changes the title of a referenced node during the edit of that node you will receive a title mismatch error. But this doesn't explain how the user can resolve this error.

It would be more helpfull to explain they can "research the title" OR if they are shure of their selection they can "just use [nid:n] value". This is because the user is unaware that the title may have changed by somebody else and researching the title may be unsuccesfull. So this user should be informed of the option to use the [nid:n] value.

The error message like it is now leads to people not being able to save their node.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rp7’s picture

I agree with alexverb.

We are running a website with about 10 editors, this occurs now and then and is pretty confusing for the end-user.

Any special reason why validation is based on the title?

danielb’s picture

Status: Needs work » Active
jarrodirwin’s picture

Status: Active » Needs review
FileSize
1.02 KB

As there has been no reply as to why the title comparison is needed (seeing as all we really are concerned about is getting a valid nid), I have created a patch which checks on the nid instead of the title. If a nid is found and the DB search returns a node it will pass, otherwise it will throw the error.

This solves another problem where the title data saved in the DB is different to that which is from the POST. EG. DB: '\r\nSome Title', Form data: 'Some Title'.

rp7’s picture

Patch in #3 works for me.

BrockBoland’s picture

Patch in #3 is handy for another use too: when the displayed title isn't the "right" one.

In my case, I'm using a View as the data source for a node reference autocomplete field. I'd like to show the menu structure of each node shown in the autocomplete results, so I'm using hook_views_post_execute() to hack the titles used in the View's result set. Without the patch in #3, this causes the title mismatch error.

I'm not going to RTBC this only because I haven't tested it exhaustively and it may not be the desired functionality for this module, but it's working for me.

Alex Andrascu’s picture

Assigned: Unassigned » Alex Andrascu

Ok then. Let's see how can we get this in.

Alex Andrascu’s picture

Alex Andrascu’s picture

Version: 7.x-2.0 » 7.x-2.x-dev
Alex Andrascu’s picture

Status: Needs review » Fixed

Commited to 7.x-2.x-dev.

Can you please test ?

Thank you.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.