Search button breaks when used on a multiple link or text field

Any progress on this, zuuperman? We're facing the same problem.

I have tested this now, and for me it works.

Are you using the "link field"?
How is that configured?
Are you use us using the 7.x-2.5 version of Linkit?
What browser are you using?

Hey Anon,

We're using Linkit 2.5, a link field with the default settings and "Enable Linkit support" checked (using the "Raw URL" option) and number of values set to unlimited.

The problem occurs in both Chrome and Firefox (latest stable versions).

The exact problem is as follows:

• If there is currently only one link field, the search button will work.
• If you add another link field, using the "add another item" button, the search button also works for this newly created item.
• However, the search buttons on any of the above/older link fields of this set stop working.

I think that the changing of IDs (as described in Zuupermans example) might be the cause of this.

This is very strange, it works perfect for me.

The ID should not be a problem as when you adding a new field with the ajax wrapper, that field ID will be inserted in the list of field Linkit works on automaticly. I can confirm that this works on a clean install.

When you say "stop working", how does that appear?

If you are able to help me debug this, it would help very much.
Its quite easy.

In Firebug, or any other browser console, type console.dir(Drupal.settings.linkit.fields)
Right after the edit form page is loaded, then hit the "add another item" button and type console.dir(Drupal.settings.linkit.fields) again.
This time the new field should be in that list.

I have named my field like you have "page related pages link" and then I do this on a clean install I get.

edit-field-page-related-pages-link-und-0-url
edit-field-page-related-pages-link-und-1-url

Your edit-field-page-related-pages-link-und-0-url--2 is strange as its like a second URL field in the first one.

edit-field-page-related-pages-link-und-0-url--2

I think that there is something with the ajax call. Something with the context of it as the Drupal ajax will prevent the same id:s to be printer again within a request.

Tho its strange that there are two users with the same problem.
What do you two have in common that is different from a clean install.

@gillesv: Do you have the exact same problem symptom? that the field ID becomes edit-field-XXXXXX-und-0-url--2?

I have tested this on your site zuuperman, and I can confirm the issue.

But I tired to install the standard profile, then adding a link field with the same settings as the one have in the feauture.
It works.

Then I enabled some feautres (xxxxx_core, and xxxxx_page) and then added a new content type with the same link field on.
Its now broken, but the first one works. Adding new field will have the same behavior as the broken ones.

I bet that there is some other module or custom code that is breaking this so I have to close this issue as it works on clean installs and many other sites.

Please feel free to repoen this issue again if more info gets provided.

Jup, we do have the exact same problem. The number that gets added to the end of the ID...
It's too bad this can't be fixed in the Linkit module, but thanks for looking into it!
We'll have to prevent using the Linkit field with unlimited number of fields for now.

We'll have to prevent using the Linkit field with unlimited number of fields for now.

or help me find why this is happening.

I have the same issue.
It's default Drupal behavior for now. It's really a bit weird, but id's of elements changed after Ajax mult-field element adding,
because of drupal_html_id() function.

And problem that '#id' attribute of element changed only for children of 'link_field' element type, that's why this works wrong:

    if ($element['#type'] == 'link_field') {
      $field_id = $element['#id'] . '-url';
    }

We add JS setting with id for 'link_field' field, but inside form processing inner text field for URL will have another id.
I have quick and ugly patch for now, but it helps for me.

Having the same problem, modified the patch from #12 to work with LinkIt 2.6

Patch #12 and #13 do not work for me, cus after trying to alter inserted link, its redirect me to linkit/dashboard/field with error in javascript : e is undefined ( e.value = text ).
I`m modified patch #13 and now I can change value of alredy inserted link.

Same problem. No custom related code used

Got the same problem. So as a quickfix I made reroll of patch #12 and #13 for the latest dev. Aslo I would reccomend to update jquery_update module to the latest stable version, as some bugs with ajax were fixed there.

Need to take a look on clean installation!

The problem as I understand it is that in the case of link_field, the code is guessing what the ID will be after processing:

    $field_id = $element['#id'];

    // Special treatment for link fields.
    if ($element['#type'] == 'link_field') {
      $field_id = $element['#id'] . '-url';
    }

This is because the url is not processed at the moment that the #process function is invoked:

'url' => array (
  '#type' => 'textfield',
  '#maxlength' => 2048,
  '#title' => 'URL',
  '#required' => false,
  '#default_value' => NULL,
),

Are there other modules involved in causing this problem? Probably, but I still think it is wrong to guess the ID.

My approach in fixing this is to use #after_build function, rather than #process function. Patch attached.

Re #17 Your solution looks nice, we can avoid any ambiguity this way and don't use that "starts from" selector in js.
Also I've tested it and can confirm that it works correctly.

+++ b/linkit.field.inc
@@ -172,7 +172,7 @@ function linkit_field_profile_validate($element, &$form_state, $form) {
+function linkit_process_field_element($element, &$form_state) {

+++ b/linkit.module
@@ -329,7 +329,7 @@ function linkit_element_info_alter(&$types) {
+      $types[$element]['#after_build'][] = 'linkit_process_field_element';

Just a small nitpick: I think we should rename function to something like linkit_field_element_after_build to be consistent.
And then push it to maintainer review.

Made changes I mentioned in #18, attaching patch.

+++ b/linkit.field.inc
@@ -172,7 +172,7 @@ function linkit_field_profile_validate($element, &$form_state, $form) {
+function linkit_field_element_after_build($element, &$form_state) {

Add type casting.

Added type casting and more informative PHPDoc.

What about this patchs? Handles titles for url field aswell.

1. No need to check for 'link_field' == $element['#type'] three times per function.
2. This $field_js['data']['linkit']['fields'][$field_id]['title_field'] = $element['#id'] . '-title'; will work only if element type is a link_field.

Here is the patch with reworked after_build callback.

P.S. #21 works fine, but doesn't contains support of titles of link_field.

+++ b/linkit.field.inc
@@ -170,72 +170,78 @@ function linkit_field_profile_validate($element, &$form_state, $form) {
+    'title_field' => "$field_id-title",

As you said, this will only work for link fields.

This line will brake if the field is no link field.
Uncaught TypeError: Cannot set property 'value' of undefined

This patch only removes that line.

Yeah, there was an error. I've fixed insertion to field of "link" type.

Well this is getting a bit larger then expected, its hard to see the difference in the patch as all the code style changes.

The code styles for the js files in the patch does not match whats stated in https://www.drupal.org/node/172169.

What is wrong with the current js files?

Was fixed a lot of potential issues and simplified the code.

Code style practices, that you've specified, is outdated (please, follow the first link on that page).

So, I guess this task should have NR state.

And this one even better. Simplify JS and PHP, form a lot of Likit JS instance on a backend.

The work you've done BR0kEN is really good, I love it, though I rather see all the cleanup and simplifications in a separate issue.
That means all the js changes.

How about I give you credits for the patch #24, then we open a new issue for the js cleanup and simplifications and close this?

Would be better if you commit the last one, because it's faster than create a separate issue.

I see nothing bad in this, because patch solves the problem and, as a bonus, contains some code improvements.

But, the last word is yours.

+++ b/js/linkit.field.js
@@ -2,134 +2,144 @@
+        try {
+          var $link = $(link),
+              text = $link.text(),
+              href = $link.attr('href');
+        }
+        catch (e) {}
+
+        this.replaceFieldValue(instance.titleField, text || link);
+        this.replaceFieldValue(instance.source, href || link);

This doesn't work. link is not an element. The value of link depends on the insert plugin.

I agree with #29 to commit a smaller change with more focus. It would be a lot easier to annotate later.

@anon, did you tested the code? When link looks like "/node/2" (f.e. "raw_url" plugin) then construction $('/node/2') throws an exception. Due to this I've used try - catch construction.

Tested everything with different insert plugins and field types. Notes:

1. Re #33 try - catch does handle all insert plugins correctly.
2. #28 patch works incorrect with link "Title" field and "raw_url" plugin, url inserted as title instead of search result title, as it is currently in 7.x-3.x. Attaching patch to fix this.

Reroll against latest dev.

@l0ke, I have a small remark to your patch:

+++ b/js/linkit.field.js
@@ -2,134 +2,149 @@
+          text = instance.linkContent;

Here you use a global text variable. Need to be care with this.

But, I guess your patch is not actual - I've made a research and found a better way to implement support of "link" field.

P.S. Do not forget about interdiffs. :)

Okay, updates came.

P.S. Use interdiff from #42.

Like the way link field handled in #44 patch, "Title" always have search title if used, and "URL" is always like raw_url, independent of insert plugin.

This means same profile with "html_link" insert plugin can be used for example for rich text field and link field, and output would be HTML link for rich text field, and correct Title and URL for link field. I think it's a good approach.

No errors were found by manual testing.

@BR0kEN, Yes I tested the code, and find the same thing as (2) in #34.

Thanks for all the help. I have committed patch in #44.