JavaScript Conflict: script.js hijacks video in homepage modal

Hello BestWebSoft Team, I’m experiencing a specific JavaScript conflict with your reCaptcha plugin that I believe may affect other users as well. The Issue On my website’s homepage, I have a link that opens a YouTube video in a pop-up modal ( https://www.website.com/#modal-video-01 ). Your reCaptcha plugin is intermittently hijacking the <iframe> container that is meant for the video. Instead of the video, the modal shows the “protected by reCAPTCHA” message. This happens randomly, creating a poor user experience. Steps to Reproduce On a WordPress site, create a homepage that has a link designed to open a video in a modal window. The modal’s HTML should contain a placeholder <iframe> or a placeholder div that a script will later populate with a video <iframe>. Click the link to open the video modal. Observe that sometimes the correct video appears, but other times, the reCaptcha iframe is loaded instead. Note: When I tested reCaptcha v3, the problem became consistent, with the reCaptcha message appearing 100% of the time. Technical Analysis of the Cause I’ve traced the conflict to your plugin’s front-end JavaScript file: /js/script.js. The gglcptch.prepare function contains a code block that aggressively searches for any empty element with the class .g-recaptcha and injects a reCaptcha widget into it.codeJavaScript /* Problematic Code Block in js/script.js */ if ( 'v2' == gglcptch.options.version || 'invisible' == gglcptch.options.version ) { $( '.g-recaptcha' ).each( function() { if ( $( this ).html() === '' && $( this ).text() === '' ) { // ... code to render reCaptcha ... gglcptch.display( container, params ); } } ); My theme’s video modal system (and likely others) uses a placeholder element that also has this generic class name. Your script is mistaking this video placeholder for its own, causing a race condition where it overwrites the video <iframe> source. Proof of the Conflict Here is the generalized HTML of the modal’s iframe when the conflict occurs versus when it works correctly. The src attribute is the only thing that changes. When it FAILS (reCaptcha hijacks the src): codeHtml <iframe title="Video Player" src="https://www.google.com/recaptcha/api2/anchor?..." ...></iframe> When it WORKS correctly: codeHtml <iframe title="Video Player" src="https://www.youtube.com/embed/VIDEO_ID_HERE" ...></iframe> Suggested Solution This type of conflict could be avoided if the jQuery selector were less broad or if there were an option to exclude certain pages (like the homepage) from this specific part of the script’s execution. A simple workaround for many users would be to wrap this aggressive block in a check to avoid running it on the homepage, for example: if ( ! $(‘body’).hasClass(‘home’) ) { … }. We would be very grateful if you could investigate this. We value your plugin but this conflict is currently preventing us from using it on our site. Thank you for your time and your great work on this plugin. Hi Rena, Your breakdown of the .g-recaptcha selector and the modal race condition is excellent. Quick fixes to try: Scope targeting: only render inside a marked container (e.g., .gglcptch-container or [data-gglcptch=“true”]). Exclude modals/placeholders: skip elements inside .modal/.video-modal or those already containing an iframe. Delay init: run gglcptch.prepare after the video iframe mounts or on modal open. Page opt-out: guard by template/body class (e.g., if (!$(‘body’).hasClass(‘home’)) { … }). Example guard: $(’.g-recaptcha’).each(function() { const $el = $(this); const isTargeted = $el.is(’[data-gglcptch=“true”]’) || $el.closest(’.gglcptch-container’).length; const isModal = $el.closest(’.modal, .video-modal’).length; const hasIframe = $el.find(‘iframe’).length; if (!isTargeted || isModal || hasIframe) return; if (!$el.html() && !$el.text()) gglcptch.display(this, params); }); If you need to document or summarize video walk‑throughs, a free tool that converts public YouTube videos to clean transcripts with one‑click summaries Hi, Thank you for your request and for your interest in our plugin — we really appreciate it. We will investigate this issue and include the necessary changes in one of the upcoming updates.