I review plugins for WordPress.org, and one of my pet peeves is when I see a plugin that purports to connect your site to their service…. using an iframe.
I have a stock reply to those:
Having the admin dashboard be just an iframe isn’t permitted.
We don’t permit plugins to phone home like that (for two main reasons – security and appearance – too often people assume that they just signed into WORDPRESS and not your plugin). Please change your code to use an API or just link back to your site so they can configure things there.
The minority of the time, this is accepted, fixed, and moved on. The majority of the time, people complain that it’s ‘easier’ or ‘not confusing’ or ‘someone else is doing it.’
If everyone on the planet would stop using someone else doing something wrong as a reason to allow them to do it, I’d be so happy… But that isn’t the point. The point is that using an iframe in a plugin is a bad idea in general, and a horrible idea for your admin panel.
Let me step back. Like everything else, iframes are awesome to a point. They’re a great, easy, way to include content in your site without having to include a mess of code. When YouTube was new, iframes was the only way to include videos, and they looked like this:
<iframe width="420" height="315" src="//www.youtube.com/embed/dQw4w9WgXcQ" frameborder="0" allowfullscreen></iframe>
You’ll notice the iframe has to specify a height and width, which means I can’t adjust my site quite as much as I want to. The other major issue here is that I’ve had to specify http, which means if my site runs https, I will have security issues. Now, there are workarounds to this (and YouTube now uses a src of //www.youtube.com/embed/oHg5SJYRHA0 to mitigate the security issue), but there’s another, cooler, aspect to how it’s all working.
If you use WordPress, you don’t have to paste in the iframe at all, ever, because you have embeds! What the embed does is use the magic of oembeds to … well … embed! This allows WordPress to reach out to YouTube, ask how it wants to embed itself, and use either embed code or iframes or html5, or whatever else we come up with! It does this using an API (application programming interface) which let’s it talk back and forth. This same principle applies to your plugin pages. If you use an iframe, it’s a quick and dirty way to include content from your service (like a login form) on the plugin-user’s site.
So why don’t I like people to use it? Let’s start with the login issue. The admin page could be changed to point that iframe anywhere it wants, making it easy to send you to a page that looks a lot like the ‘right’ page but isn’t. This is a lot harder to do if, instead, you have an API that securely transmits data. If someone can edit the php code of your plugin, either one is possible to be redirected, but the API details are a little harder to fake.
An iframe is also a problem when you consider layout. Yes, it can make design easier in that you are in full control of the design, but you’re not in control of the rest of the site. I like the eggplant color for my admin dashboard, and if your iframe clashes with that because you don’t ‘look’ like WordPress, then it’s jarring for a user. Another worry? Adblock or Ghostery, the two most popular browser extensions ever, will often block those things.
Finally, and for me this is the biggest one, your users won’t know where their account is. Look, I know it should be obvious when you have something that ‘makes’ an account with a service that the account belongs to the service. And yet. One of the places I help out is with WordPress.org password resets. 90% of the emails are for people trying to reset the password on their own blogs. You can’t convince me that people actually know what they’re doing anymore, if they ever did.
So please, don’t put an iframe in your plugin as the only way I can access your admin area. It’s lazy, it’s insecure, and it’s confusing. It’s 2014. Trust me, people understand allowing their blog to connect to Twitter now.
