Our recent observation of …
- using this WordPress.org blog
- coming across some HTML iframe coded elements not showing
- always having src attributes starting with http: … which we wait for clientside means to fix for …
- mixed content errors that can occur
… these HTML iframe element contents would often not show for the readers of the blog, and it is our theory that web browsers, within the last while, changed rules to the effect “one strike and you are out” and for us waiting for clientside means to change that “http:” to nothing (ie. get your protocol off the address bar protocol) was too late to help (avoid Mixed Content errors), and so we’re now fixing CMS WordPress blog content at the “server PHP side” in good ol’ header.php to improve the situation here at this blog …
<?php
if (isset($post->post_content)) { // iframe issue
$ifrs=explode('</' . 'ifr' . 'ame' . '>', $post->post_content);
$worryb=false;
if (strpos($post->post_content, "</" . "ifr" . "ame>") !== false) { $worryb=true; }
for ($ichb=(-2 + sizeof($ifrs)); $ichb>=0; $ichb--) {
$worryb=false;
if (strpos($ifrs[$ichb], '<' . 'ifr' . 'ame' . ' ') !== false) {
$bcontent=explode('<' . 'ifr' . 'ame' . ' ', $ifrs[$ichb])[-1 + sizeof(explode('<' . 'ifr' . 'ame' . ' ', $ifrs[$ichb]))];
$crlflines=explode("src='http:", $bcontent);
if (sizeof($crlflines) > 1) { $worryb=true; } else { $crlflines=explode('src="http:', $bcontent); if (sizeof($crlflines) > 1) { $worryb=true; } }
if ($worryb && strpos($bcontent, 'http://localhost') === false) {
$post->post_content=str_replace('<' . 'ifr' . 'ame' . ' ' . $bcontent, '<' . 'ifr' . 'ame' . ' ' . str_replace('http:','',$bcontent), $post->post_content);
$ifrs=explode('</' . 'ifr' . 'ame' . '>', $post->post_content);
}
}
}
}
?>
… to fix HTML iframe mixed content potential errors before they get presented and called, in any way, on a WordPress blog webpage.
If this was interesting you may be interested in this too.