So, what is in the database, that could be causing a jQuery script not to run? Another view targeted at the same node. Several views are targeted at the same node, including the News (content filter view), Stories (content filter view, which is actually News with a different category), and Events (content filter view). The views are 'tabbed' on the node, and on the 'broken' website, we wanted to turn off the 'Events' tab. Ultimately we just 'hid' the Events tab with style code, so we do not need the Events view, itself, to be turned off (disabled.) Making the Events view active on the node, even though style does not show the content of that view, fixed the jQuery script.
Another option I might look into is moving some of the Event view configuration / functionality to another, visible, view on the node. BTW, the hidden Events view is where the AJAX-related Javascript for Drupal views is / was coming from on the 'working' websites.
Finally, I would really like to learn how to re-code this jQuery script in pure Javascript, but that will have to wait for another day.
I have been working on this issue practically non-stop for several days now . . . Today, I had the idea to connect the database for a 'working' website to the codebase for the website with the 'broken' jQuery script. The jQuery script worked! Conversely, if I connect the database for the website with the 'broken' jQuery script to the codebase for a 'working' website, now won't run the jQuery script. This tells me nothing though! What on God's green earth could be in the database that would stop a jQuery script? And why won't my Chrome or FireFox dev consoles tell me something is happening like that? According to Chrome and Firefox, the page loads very cleanly, even though the jQuery is broken.
I mean, it does kind of make sense that the problem would be in the database. The sites in question are developed side-by-side, and there is VERY LITTLE deviation between the codebase for each of the websites. The only difference between them should be the content created on them. It still doesn't help me figure out how to fix the problem though.
Regarding Possible Solution 1 -- I managed to get the Views-related Javascript files I had a question about to load. You just need to tell (one of) the Views on that node to load AJAX. (The more odd thing is that the 'working' sites, do not have AJAX=true for those Views either, and still the JS files for Views load. Essentially, the 'broken' site is doing it correctly in not loading JS assets that are not being used on the page.)
Anyway, still need to figure out how to do it with pure JS; or figure out why jQuery is not doing the same things that it does on the other, working, sites.
It is supposed to add the class to the UL element, and then sort the children within the UL. What it IS doing, is nothing.
jQuery (of some kind) is operating, because there is no error like 'jQuery is undefined' or whatever. The jQuery system just doesn't DO anything on this one site. Again, this works on other sites I have built, which are based largely on a singular 'source project' (but, I digress.)
#2 worked for me too. Thanks @jcampbell2 → . Let's just hope the Core developers have gotten over their infatuation with CKEditor5 . . .
Duplication error only happens on Drupal 10.1.x WITH BigPipe module and this module enabled at the same time.
My reference to testing with Drupal v9.4.15, was just to ensure there were no new issues created using this patch on Drupal below v10.1.x.
Hid the previous patch I uploaded to this issue. Use the patch file 🐛 Menu controls displayed twice using Claro on Drupal 10.1.x Needs review from the 'Duplicate Menus in Drupal v10.1.x' issue instead, that patch includes the fixes for this issue.
I never did figure out where to put the once directive, so I hacked a fix. I added code to check if BigPipe module was installed. If it is, the menu_parent_form_ui.js file tries to build a new variable but fails, this prevents the code from building the second, redundant, menu settings drop-down.
I have tested this with Drupal v9.4.15 and Drupal v10.1.4, and it seems to work for both -- with and without BigPipe installed.
The attached patch file supersedes all previous patch files I have uploaded.
It has to do with BigPipe module -- per this comment 💬 Drupal behaviors are added twice Closed: works as designed . To test, I disabled BigPipe, and only one menu settings option was presented by Drupal 10.1.x. Now I just have to figure out WHERE to implement the once function within the js files for this module, so BigPipe doesn't mess up the display.
jrwest_webguy → created an issue.
Patch notes:
I am a novice at git stuff, and this patch file might not work. Worst-case scenario, manually edit the 3 effected files.
Changes:
- menu_parent_form_ui.info.yml -- Changed the Core requirements item.
- menu_parent_form_ui.libraries.yml -- removed the css pointer, now the empty css file shouldn't cause MIME-type errors on some web browsers (in theory).
- js/menu_parent_form_ui.js -- Changed the CSS classes the javascript is looking for. The classes I chose should appear in more Drupal themes with javascript-driven menu systems.
I have modified the file, and the menu selector is working again; just need to figure out how to post the changes (patch) on here.
jrwest_webguy → created an issue.
My situation may not apply. I just discovered a custom module -- designed to chop up the menu select field at each sub-level -- is not (currently) compatible with the Claro theme, which is why the menu drop-down was disappearing for me. Disabled the custom module, and my menu drop-down started to display correctly with Claro as the admin theme. My apologies for the confusion. I will set this back to Postponed (maintainer needs more info.)
#74 was very helpful for me as well. Thank you @junaidpv and @rex.barkdoll.
The image below is from my Drupal 10 site, but I see the exact same thing on my D9.4.15 sites as well. (Yes. I know, gotta upgrade.)
This snip is from the 'Add item to menu' form from Drupal core, when Claro is the Admin theme. Note I have highlighted in yellow the fact that -- probably because I am not finding a commensurate file within the Claro theme itself -- that the select element twig file (select.html.twig) is being pulled from Drupal core, instead of the theme. In any case, we can see the element's (in-line) styling, circled in red, is such that it's hidden. (Would have been more efficient to use display: none; css code.)
If Claro had a select.html.twig file, this issue might be resolved.
What is a configuration-managed site? Are we no longer supposed to be using Composer? (Found this thread after a Composer-based update caused my site to start throwing a 'missing module - mysql' error.)
Thank you for the tip on updating the config/sync/core.extension.yml file.