JS 7.x-2.x Integration

Hm, yes.. I can see how this may be confusing at first, my apologies. Unfortunately there's not very good documentation on the 7.x-2.x branch yet (still a work in progress). But I'm glad you took a stab at it cause it's shown me some areas of documentation that need to be worked on (especially around the 7.x-1.x upgrade process).

While working on this, I did realize that the easiest way to detect whether or not the request is via core or JSv1 vs. JSv2 is by detecting if global $_js has been set (which is only available in JSv2).

After that it's more just a matter of plugging in the necessary #js_callback on the select element (so it generates the necessary XSS token) and then modifying the data sent with your AJAX request for JSv2.

I didn't change the menu path (for JSv1 compatibility), however in JSv2 the AJAX request doesn't need to send the module and callback in the path anymore. This is done through js_module and js_callback parameters in the POST data.

Ultimately, yes... I would recommend using $.jsCallback() as it will cut out a lot of redundant clutter on the JS sides of things, but in reality it's not needed as long as you know what JSv2 is expecting on the backend. I simply created these jQuery methods as helpers for anyone that wanted to use them (best probably from scratch though).

I'd like to further explain the purpose behind #js_callback and $.jsCallback().

#js_callback will add data attributes to whatever element you attach it to via JSv2's new #pre_render callback:
<select class="..." data-js-module="shs" data-js-callback="json" data-js-token="..." ....></select>

When used with $.jsCallback(), you don't have to implement your own verbose $.ajax and then specify all the necessary parameters (like the above patch is doing). Instead, you can focus on just the data you're sending back. For example, say $element is the <select> element above:

$element.jsCallback({
  callback: 'shs_json_term_get_children',
  arguments: {
    vid: settings.vid,
    parent: parent_value,
    settings: settings.settings,
    field: settings.fieldName
  }
});

This would automatically pull in the data attributes from select and merge them in with the data supplied here. One of the reasons for this is that it decouples the backend requirements and allows the front-end to know have to worry about what the module, callback or token is (as these, in theory, could change).

However, given that you're also dynamically creating <select> elements, I suspect it would take a greater amount of effort to completely redo the code here. Regardless, I definitely recommend you take a look at the code in js.js just to see what it could do for you! I am most certainly open to suggestions :D

I think all the legacy cruft should be removed now that js_7.x-1.x is officially marked as unsupported and a security risk. It doesn't make sense to keep support for it here too (which just let's people stay on old, insecure code).

@jadsay, js_7.x-1.x is no longer supported. It's a security risk. Do no use it.

As I stated above, js_7.x-1.x is no longer supported. It's a security risk. Support for it should be removed by this patch.

Ok. I'm not sure what is/was going on above. So many patches that differ in size and seem to implement other issues + short array changes.

I decided to start from scratch based on the current dev version and completely refactor how the callbacks are implemented.

This supports both with and without JS, naturally, but I've made the assumption that in 7.x-2.0 (if that will ever come to be), the JS module should be a dependency (for simplicity sake).

I've marked quite a few functions as deprecated, mostly due to lack of necessity/replacement with JS module equivalents.

Due to the JS changes, I recommend that this be merged ASAP to avoid the need for another re-roll and the mess that was created above.

I have tested this thoroughly, but if others here are willing to as well and RTBC it; that certainly will help.

---

I've also gone ahead and created a new release for the JS module: js_7.x-2.5.

While this new JS module version shouldn't be necessary for this patch to work, I recommend that you update regardless.

Whoops, forgot to change the element path for the add token after some last minute rearranging of some code (it's late for me).

This issue is only indirectly involved with translations (because it has to move some code around), it's not primarily about them.

This issue is specifically about the integration of JS module 7.x-2.x.

Comments like #28 & #29 are similar to what has previously derailed this issue (see above). Saying that an issue/patch "isn't working" just because it didn't fix your specific issue (which is an entirely different issue BTW) only does an issue and the people who have worked on it a disservice.

Issues specifically regarding multilingual/translations should be filed as a separate issue. Please stop hi-jacking this one.