John_G

Nothing changed.

I don’t know weather you did not read my message thoroughly or you did not test the scenario.

PHP 7.0.6
Fresh WordPress 4.6
Piklist 0.9.9.9
No hook handlers added.

Piklist demos -> Add-More's -> Todo's (Serialized Group)

The same behavior I explained earlier.

+1

Piklist

So, I don’t know if is it you modified some plugin jquery.suggest.js (because there is no credentials in minified file) or is it solely yours. But the logic of highlighting of substring is bullshit. Look:
Let’s assume we have some title “The classy glass” (I think you already spotted the pitfall).
1. User enters “class” + space
2. Suggest suggest “The classy glass”
3. The highlighted part of the suggest is the html:

The <span class="iss_match">class</span>y glass

4. Then this html string is cached with all the tags.
5. User presses any white space characters.
6. The plugin again replaces all class substring with the same template:

The <span !class!="iss_match">class</span>y glass
The <span !<span class="iss_match">class</span>!="iss_match">class</span>y glass

Note the substrings between exclamation marks.
So, any string that is a substring of <span class="iss_match">$&</span> gets screwed.

1. I fixed this issue by disabling caching of the rendered items of the suggest list. Somehow they are cached with html markup (stupid).

file: jquery.suggest.js
//c.addToCache(b, a.length)

Someone should fix the logic of caching. Who is the author of the jquery.suggest ?

2. Also I modified the highlighting by modifying the

file: jquery.suggest.js

addMatchClass: function(a, b) {
  var REGEX = '(' +
    this.$input.val().trim().split(/\s+/).join('|') +
    ')';

  return a.replace(
    new RegExp( REGEX , "ig"),
    '<span class="' + this.options.matchClass + '">$&</span>')
},

This is somewhat of upgrade. Now all the words from the input field get highlighted independently.

For now I don’t have live site. But I’ll add remark below the search field:
“Dear users don’t type [as,is,ss] and after [Space,Ctrl,Shift or any other white space symbol], because this terms are not particularly good for searching.”
I think you should find the logic flaw instead of implementing some kind of stop lists. Any of this combinations of characters may be the thing the user searches for (for instance, a model of a device).

Also, I can restrict the plugin to search only the title (for example).
Suggest part of your plugin must provide the visual assistance for the data it somehow gets from the response without no assumptions that some words are “so common” that I (plugin) will display them out of square.

I want you to say that this is right: <span></div>

Consider such scenario: you need to combine JSON for client side. With single get_post_meta you will have to filter metas by hand and repeat keys (keys for filtering = cmb2 metabox field ids):

$metas = get_post_meta($id);
$keys = array_keys($keys_i_need);
$filtered = array();
foreach ($metas as $key => $value)
{
  if (in_array($key, $keys))
  {
    $filtered[$key] = $value;
  }
}

Сам яндекс рекомендует :

Код счётчика можно устанавливать в любое место HTML-кода, желательно ближе к началу страницы.

Так что опция была бы не лишней.

It does not matter if it is separate metabox or not. The design of the plugin does not allow to save group(if not using type=>group) as a single meta entry. Everything results in a mess of metas. One have to deal with multiple get_post_meta instead of retrieving all the corresponding data in one go.

You should not overthink anything. Group filed is a group firstly. Repeatable is different story.