After searching the internet far and wide for an iframe solution for WordPress, I mostly found uppity comments about how it was not secure, and you just should not use them.

Well, sometimes there are good uses for the iframe. Such as using an iframe for Google Calendar, or if a client uses some other third-party calendar provider and get their content through the use of the html tag iframe.

Remembering what I had to do to extend WordPress to be a more full-featured content management system, I took my cue and created a new page template. You could call it “calendar.php.”

It is in the template where I just chose to place all of my code for that page and pulled the iframe in rather nicely.

I used a PHP include to bring in the actual html, but I’m pretty sure it will work just putting the iframe code directly into the template file (though I have not tested that).

So if you’ve been beating your head against the wall looking for a way to get an iframe into the body of a WordPress page, this is a simple solution. Though one that is more technical than you should have to be for a content management system.

I found one example, but his solution did not work for me.

Taking his cue, however, I did implement SuperFish as a starting point.

Implementing SuperFish is pretty simple, so I’ll leave their documentation for that part of this “how to.”

After you get the SuperFish plugin working with wp_list_pages in WordPress, you run into a major problem with sIFR and any of the dropdown solutions for Wordpress. The CSS wp_list_pages creates is applied to the <li> tags, and sIFR will want to replace all of the sub-pages text as well as the text for the top level pages.

To get around this, I installed the plugin List Pages Plus and made a couple modifications.

Once you have the plugin activated, you need to edit the “list-pages-plus.php” file included. Change the following line:

$litem[$k] = "\n\t" . ‘<li class="’.$class1.$ac.’"><a href="’.$href1.’" title="’.$title1.$at.’">’.$pre.$text1.$post.’</a>’. "\n\t <ul> \n\t" .’<li class="’.$class2.$sac.’"><a href="’.$href2.$sah.’" title="’.$title2.$sat.’">’.$spre.$text2.$spost.’</a>’;

to:

$litem[$k] = "\n\t" . ‘<li class="’.$class1.$ac.’">’.$pre.’<a href="’.$href1.’" title="’.$title1.$at.’">’.$text1.’</a>’.$post. "\n\t <ul> \n\t" .’<li class="’.$class2.$sac.’"><a href="’.$href2.$sah.’" title="’.$title2.$sat.’">’.$spre.$text2.$spost.’</a>’;

And then change this line:

$litem[$k] = "\n\t" . ‘<li class="’.$class.$ac.’"><a href="’.$href.’" title="’.$title.$at.’">’.$pre.$text.$post.’</a>’;

endif;

to:

$litem[$k] = "\n\t" . ‘<li class="’.$class.$ac.’">’.$pre.’<a href="’.$href.’" title="’.$title.$at.’">’.$text.’</a>’.$post;

endif;

Now, if you really wanted to be complete, you should also change the position of the input box in the form for the admin, but it is not a necessary step. The hack will work whether it looks right in the admin form or not.

After you have made the above code changes, go into the settings for List Pages Plus and add <div class=navReplace> and </div> to the last two input fields for the parent item.

Now, change wp_list_pages to wp_list_pages_plus in your header file (or wherever you are implementing your dropdown menu with sIFR for the top level).

Your last step is to use the span tag as your selector for your sIFR replacements. Using the class example I gave above, your selector would be “.navReplace”

If you do the above, you can get sIFR working on your top level navigation items with dropdown menus.

A friend could not even access his wp-admin page, because of the glitch in the plug-in!

To the Bad Behavior author’s credit, he did issue a patched upgrade rather quickly. This is quite disturbing, however.

We noticed that this blog did not block us out of the main content or the admin, but it did prohibit MarsEdit from posting or retrieving posts. Very interesting. I’m not sure why the plug-in would only block certain types of access coming from the same IP. Because it was through MarsEdit, we did not see the standard Bad Behavior message. This makes it even more disturbing as we would have had no idea what was causing this failure in our offline blog editor.

WebGeek posts on “Bad Behavior Behaving Badly“:

This was no minor glitch, and something like this could have serious consequences for websites and businesses. If left unattended in this state for a long time, a site could lose valuable search engine rankings, after the spiders of the Big 3 (Google, Yahoo, and MSN) find that they are locked out repeatedly with 403 errors. It’s most likely that these losses would be temporary, but there’s no guarantee, and by that point the damage is done.

And the explanation comes from the Bad Behavior blog:

Update: Some people have asked for more details on what exactly happened. In brief, yesterday I moved all of my sites to a new dedicated server. In the process, I decommissioned an old blacklist I was running which I thought wasn’t being used, not realizing that Bad Behavior was still set to use it. Shortly afterward, I found myself locked out of my own blog, just as you all did. So therefore, this release.

WebGeek has recommended the removal of Bad Behavior from all blogs until stability can be assured. We agree, but suggest if you want to keep the updated version of Bad Behavior going on personal blogs you monitor closely, it will help to see if this plug-in has truly stabilized.

As always, be sure to backup your database prior to upgrading and thoroughly test your blog after the upgrade has been completed!

Enjoy!

As always, please be careful when upgrading, especially if you have heavily modified your WordPress install.

If you are updating from 2.1, this should be a problem-free upgrade. This blog was updated via Fantastico in just a few seconds.

UPDATE: Do not upgrade to this version of WordPress. There was a security breach and it could be a faulty build. Though it is unlikely that Fantasico installs of WordPress are affected, it is better to be on the safe side and not upgrade yet.