Reproduce:
- Create an iFrame that uses the URL parameter (call it individual_url, for example)
- Have a template page in front of the page that contains the iFrame. This template programatically sets the individual_url parameter on the referral to the parent page of the iFrame (i.e. https://xxx.xxx/main_page?individual_url=<my URL>)
- Check the URL of the page in the location bar. The individual_url parameter will have changed from <whatever I set> to "undefined." It does not matter if the value is URLEncoded or not.
- Attempt to reload the page
Expected:
- The URL would not be "undefined"
- The page would load properly
Actual:
- The URL is undefined
- The iFrame returns a 404
Note: If I put in two if the "individual_url" tags, both with the same name ("individual_url"), when the page is displayed only the first individual_url is changed -- the second is good. The page appears to take the second as legitimate, however, and displays the iFrame.
Strange:
does exactly this. What is the reals parameter you use? Because Wordpress has a big list of reserved words.
Using any of https://codex.wordpress.org/Reserved_Terms
can behave strange.
Please also check the more advanced features of the pro version:
http://www.tinywebgallery.com/blog/advanced-iframe/advanced-iframe-pro-demo/url-features#h49
Is much more advanced. there you extract anything from the url and use if for the iframe. Also query parameter. Maybe this works for you.
Best Regards,
Michael
I am using the Pro version, and the name of the variable is $individual_url, which is not a reserved word.
The URL is constructed thusly:
$redirect_url="https://oureventstream.wpcomstaging.com/live-stream-control/?EncoderGUID=".$EncoderGUID."&Nickname=".urlencode($Nickname)."&individual_url=".$individual_url."&individual_url=".$individual_url."&jwf=6666";
error_log("Redirecting for live stream control: ".$redirect_url);
wp_safe_redirect( $redirect_url );
As you can see, there is a log message. This is it:
[26-Jul-2020 00:56:33 UTC] Redirecting for live stream control: https://oureventstream.wpcomstaging.com/live-stream-control/?EncoderGUID=c4d02f831942667da8b62078b1177c0d&Nickname=Earth& individual_url= https://oureven tstream.com/individuals/iframe_7fa14d5f956780fbe49e4bc3e546382c.html&individual_url= https://oureventstr eam.com/individuals/iframe_7fa14d5f956780fbe49e4bc3e546382c.html&jwf=6666
I have tried both urlencode() and as above, without effect.
Page live-stream-control is an Elementor Pro page with the Advanced iFrame Pro embedded via the following shortcode:
[advanced_iframe src= https://oureventstream.wpcomstaging.com/TOAD width="1280px" height="800px" map_parameter_to_url="individual_url" ]
When rendered, the page URL is:
https://oureventstream.wpcomstaging.com/live-stream-control/?EncoderGUID=c4d02f831942667da8b62078b1177c0d&Nickname=Earth &individual_url=undefined&individual_url= https://oureventstream.com/individuals/iframe_7fa14d5f956780fbe49e4bc3e546382c.html&jwf=6666
There is another iFrame on the page that's implemented by direct HTML:
<iframe scrolling=no height=200 width=800 src= https://oureventstream.wpcomstaging.com/stream-status-template/></iframe>
It does not appear to be interfering with your plugin.
The code that fails is in a template page directed to as a redirect from an OnClick() event for a button. Prior to hitting the button, the user makes a selection from a dropdown list, where the OnChanged() event stored the selected Value as a cookie. The template page reads the cookie, performs a series of database queries, and establishes the complete URL for the iFrame. It then uses wp_safe_redirect() to load the iFrame parent page, passing the individual_url as a parameter. When rendered, the first individual_url is invalid, while the second remains unchanged.
The failure is 100% reproducible in my environment using this pathway, but there is another pathway to the same page that works properly.
The code that works constructs the URL on the fly as well, again storing it as the value in a dropdown list. In fact, both pages use the same OnClick() method to construct the URL, but the difference is that the one that works makes an immediate redirect, in Javascript, using
window.location ="/live-stream-control/?"+SelectedObject.value;
So, now we know that the wp_safe_redirect() pathway fails consistently (so does plain old wp_redirect), while the JavaScript execution works as expected. That and the intervention of the template page, are the only differences between the two pathways.
I spent four very long days trying to understand and figure out what was going wrong before I hit on the idea that maybe, for some reason I could not begin to understand, you guys messed with the parameter value -- deleting it so it became undefined, when redirected using wp_safe_redirect().
I know that the Javascript call bypasses WordPress entirely and just forces a load of the target page, so any post-processing you might have relied on would not have been done. Working under that theory, I tried a great many different combinations of settings for the iFrame, all without effect -- the variable remained magically changed to 'undefined.' I was about ready to pull your asset when I hit on a work-around.
I gambled that whatever the bug was it would only hit once in a given parsing loop, and I was right. You eat the first copy of the variable for some reason, but leave the second alone. PHP does not, to the best of my knowledge, implement a widely-accepted equivalent for the C++ memmove() function, and most orgs stay away from things like the Singleton pattern or smart pointers in PHP, so the problem was probably a low-level bug. It is possible that you are using some advanced design patterns, but more likely you're assigning NULL to the parameter somewhere, because that's usually the only way a valid variable goes to 'undefined'.
It is fortunate that I found the work-around, as it has two benefits. First, and most important to me, it unblocks me. Second, I sort of care about this as a bug, but only in so far as it reflects on my impression of your company. I am a software developer with many years experience, and how a company responds to notifications like these tells me a great deal about the overall organization -- organizational and/or corporate attitudes, values, and capabilities.
Good luck.
John
Hi John,
the plugin does not support arrays at map_parameter_to_url when you define parameters. This happeds when you define the same parameter twice.
As a pro user you can use the placeholders in the url. See
http://www.tinywebgallery.com/blog/advanced-iframe/advanced-iframe-pro-demo/url-features#h49
{query-X [,defaultvalue]}: the value of the query parameter sent by GET or POST. ?example=myvalue would be {query-example} -> myvalue. The optional defaultvalue is used if the parameter is not found.
In your case you can use {query-individual_url} directly in the url.
I might support this is the future. Not sure why you define the same parameter twice.
Best Regards, Michael
Hi John,
I'm not sure which version you use. I added in 2020.6 that if a array is given only the first value is forwarded to the iframe.
now only the first parameter is passed.
Best Regards, Michael
