Hi @dlevchik
Thanks a lot for your work on the issue!
I am currently unable to invest time into this, would love if anyone could join on the discussion :)
Such a function would be an absolute gamechanger! +1
The AI Core is such a central piece of architecture and will only gain importance in the future, and if we don't make the first move here, someone else will.
This would also allow ease of integration with other modules that aim to integrate AI output in a very low barrier entry way. And when implemented, I am quite sure that usages would skyrocket.
I am strongly in favor of merging this to the AI core, especially because of the safe way using a submodule - if you don't like it, don't enable it.
florianmuellerch → made their first commit to this issue’s fork.
Done, thanks for the effort!
@alberto56 I expect this behavior as you wrote only if the paragraphs field itself is not translatable (Paragraph fields officially do not support that). I assume that if it‘s translatable, the two values (fr and fr-fr) are no longer connected.
Maybe also try with another language like de or en (just more standard that fr-fr). But otherwise your suggestion should sound right (except without the patch, the fr-Version should be shown in fr-fr to be precise, because fr-fr is unpublished which then falls back to fr).
Hi @arakwar
Thank you for raising the issue and for your suggestions!
However, I do not think that this module should move in this direction for the following reasons:
- Usage of features is actively discouraged as from their project page →
- The problem seems to originate not even in the features module, but by your application which in my opinion is something that the features module did never consider supporting. If it should do so, it should definitely be implemented in the features module.
If you feel otherwise, please specify your use case a bit more in detail with some config examples, so I can get a better picture of the issue. And if you could provide a patch or MR, that would be great :)
Because of no one else participating in the discussion, I'll close this issue for the moment.
Thanks for the explanation and also the good work!
I couldn't merge the MR because of a Gitlab error, therefore I commited your changes manually.
Thank you very much!
Thank you all for the work! I like the idea.
However I believe we need a way to overwrite the view, because if the module was previously installed, the view won't be refreshed to contain the IP and user agent fields.
How could we do this?
I've removed the is_null condition because is_array also checks for that. Otherwise thank you very much for raising the issue!
Couldn't merge the MR, therefore re-commited but credited you. Thanks for raising the issue!
Merged, thanks for the MR!
I want to apoligize for my late reaction, I was not aware that having a README.md is of some significance.
I used your patches and MRs and altered the readme a bit to represent recent changes.
Please use version 1.4 to use the commited changes.
Thank you very much for your work!
Hi @alex.bukach, thanks for reaching out!
I have a hard time understanding the issue deep enough. This module only does one thing, which is to override the libraries at `core/jquery` and `core/jquery.once` (readding the latter), see jquery_once.module. The other thing it does is seperately providing the files as new dependencies called `jquery_once/jquery` and `jquery_once/jquery.once`.
I could only assume that this could happen if you both declare a dependency on `core/jquery` and `jquery_once/jquery` or `jquery_once/jquery.once`, leading to both loading the jQuery library seperately (`core/jquery` and `jquery_once/jquery`).
Can you check your dependencies that you for example only ever use `core/jquery` and `core/jquery.once`, and never `jquery_once/jquery`? Keep in mind that the core itself at this point still loads `core/jquery` sometimes automatically.
Let me know if this helps!
Someone with a bit of time on their hands should create a guide on drupal.org (I don't even know how that would work) and start a comprehensive documentation about how render arrays are working and how they're supposed to be used. Therefore I suggest to leave it open until we find that "someone".
@quietone Thanks for the engagement :-)
I raised the issue out of the experience that all developers that I newly introduced into the Drupal ecosystem seem to struggle to grasp this concept, and still to this day, I didn't find neither a really comprehensive guide, nor an absolute overview over possible render array keys.
This does not only need to be in documentation: Imagine a contrib module that goes through all modules and lists their render array keys. However I'm not sure if, as a contrib module, you would have access to list all the types and themes built into the core itself.
There's just guidance and overview that is still lacking. If you have good resources (maybe also from elsewhere) please feel free to share!
@enchufe that is simply pure gold, thank you so much! You saved me a loooot of headache!
And for the issue, I now use the dev branch and the change works absolutely fine, so I think it could be released. Could this be closed, or RTBC?
@enchufe thanks for the issue, was looking for this!
How do you solve the delayed loading of any given script provided by a module (when consent was not yet given), simply by its attributes? Any hook I don't know of yet?
Hi @bvoynick
Thank you very much for your inputs and efforts for the merge request! :-)
I very much like the idea of handling cache properly. However I don't quite understand the use case in this particular example.
Could you provide an example where this comes into play? At the moment, the config is read directly on call, and then held in local memory. How does cache metadata affect this process?
Hi @brockfanning, thank you for your interesting question!
I personally assume that Drupal Core aims to remove jQuery alltogether, leading to both core/jquery and core/jquery.once libraries being dropped out. I plan to keep this module as compatible as possible for as long as possible because I simply like the way jQuery and jQuery.once work.
The only way this module would not be future-proof is if core decided that under core/jquery they release a piece of software that is different from default jQuery versions, and would be missing as we simply override it. But this would in fact break a lot of existing installations even more, so I don't see any evidence of this.
As a last resort, you could always take the code of this module (which is really fairly simple) and put it in your own module and adapt some changes, if you need something urgently. However I would assume that others might encounter the same issues, raising the need for an issue here in the issue queue to tackle the problem for everybody.
Have a great sunday and a nice week,
Florian
Hi @dusandelucia
The short answer is: "It depends" :-)
I personally would not migrate any custom code, if you just started and then installed this module. Every jquery.once usage will continue to work as usual, so there's no need to change your code.
However all other modules most likely already have changed their own code and use the built-in Drupal.once(), which is also fine.
I would avoid using both jQuery.once() and Drupal.once() in the same module, let alone in the same file. I would decide on one of the two and then consistently only use that, to avoid problems.
In fact, I also have a project running that uses now both Drupal.once() and jQuery.once() in the same large module, but it runs just fine - if the two libraries do their own jobs and don't intersect with each other.
Hope that helps - happy site building!
Well well how the turntables...
Apparently it was all a mistake again. I later found out that even when using 3.6.3 again, it wouldn't work anymore.
Root cause was something completely different: Another module included another instance / version of jQuery which ultimately caused the issue.
@InaW sounds promising!
When I tried something similar, I ran into issues when I saved the node - Drupal threw an error that "untranslatable fields cannot be changed and must be changed on the original language" or something similar... Did you test that solution? Works fine?
@InaW I didn't find a solution to this particular problem yet. Instead I decided that editors on our platform actually probably want asynchronous translations, that's why I enabled translation on the paragraphs field instead, despite being unsupported. However in your particular case, there's no solution for that and I think there should be.
florianmuellerCH → created an issue.
florianmuellerCH → created an issue.
I've just released official 1.0 of the module, however I'm totally fine if you get a tested and working solution in your MR, I would merge that and release 1.1 from that.
I just would like more feedback from people on this, and the MR would have to be adapted.
Hi @demonde
Thanks for your suggestion!
I wasn't aware that there were any more regularly used libraries that relied on jQuery. Apart from jquery.cookies, there were apparently also a lot more, like jquery.ui, jquery.joyride, jquery.form etc...
I focused the module on jQuery.once as I was in need for that, and it's also quite prominent in the name. Therefore I think I cannot extend the modules scope to bring back "all" jQuery libraries.
However I would love to link it on the project page if someone does a module like this, e.g. "Bring back jQuery" :-)
Feel free to use and re-use this module's code if it's of any use to you, if you want to develop such a module.
Hi @stox!
Good idea :) I just needed the module asap, that's why I threw it together like that.
I'm not entirely sure how I could control composer dependencies in particular, especially as Drupal itself does add a composer file when the project is released and packed... Would you or anyone else mind making a PR or a patch with a draft?
Thanks!
Confirming that #53 did the trick for me on 2.0.1, while #56 didn't solve the problem?
I'm running Drupal 10.1.0 and I had the issue as well with the table headers being repeated, so I can confirm this is still an issue.
Also +1 from me, patch removed the error "Invalid address: (Sender)". Thank you!
Thanks for the initiative and the MR!
Thank you very much @audacus for bringing this issue to my attention and fixing it!
Thank you all for your work! #21 and the info in #22 helped me a lot!
I added a JS behavior to make the selected elements sortable. To do that I had to add my library and a class in the base element:
$element = [
'#type' => 'details', // I added this directly here
'#open' => $default_open, // I added this as a parameter
'#title' => $title, // I added this as a parameter
'#attributes' => [
'id' => Html::getUniqueId('entity-browser-' . $entity_browser_id . '-wrapper'),
'class' => [
'entity-browser-form-trait-element', // NEW CLASS for JS behavior
]
],
'#attached' => [
'library' => [
'my_module/entity-browser-trait' // ATTACH new library
]
]
];
Be sure to add the dependency to core/sortable in your libraries.yml.
(function ($) {
Drupal.behaviors.entityBrowserTraitSortable = {
attach: function (context, settings) {
$(once('sortable-entity-browser-images', '.entity-browser-form-trait-element table.responsive-enabled tbody')).each(function() {
let $tbody = $(this);
let $parent = $tbody.closest('.entity-browser-form-trait-element');
$tbody.find('>tr').css('cursor', 'move'); // This is a convenience thing and could be moved to CSS
Sortable.create($tbody[0], {
onEnd: function (e) {
let $to = $(e.to);
let list = [];
$to.children('tr').each(function() {
list.push($(this).attr('data-entity-id'));
});
$parent.find('input[type="hidden"].eb-target').val(list.join(' '));
}
});
})
},
};
})(jQuery);
As this affects core and I have the need to apply multiple patches, I created a patch for 10.x to apply.
I would love to offer my time as I love Adminimal on all my projects.
I can opt into security advisory policy and also have already multiple own and co-maintained contrib modules as a background.