Plugin installer tool

Remember when you had to install WordPress plugins by uploading them manually via FTP? I do. Heck, I remember when there weren’t plugins, and you had to copy and paste PHP code! We’ve come a long way, but I realized the other day that there is one more way that we could improve ease of installation.

Say you’re a plugin author, and you have this great plugin. How do you get people to install it? Well, you could link to its page in the plugin directory, where they’d be prompted to download a zip file. Or you could offer the zip file yourself. But why are we offering plugins the same way we were in 2004? We have a built-in plugin installer. Let’s use that! So how would you do that? I guess you’d just tell people “Hey, go to your wp-admin and search for ‘My Awesome Plugin.'” That introduces a lot of chances for failure. They might even end up with the wrong plugin!

I made a better way, and will be working on integrating this into WordPress.org this summer.

To see it in action, click here. All you have to do is type in the URL of your WordPress blog.

The tool auto-detects the WordPress installation by looking at the X-Pingback header. You’ll be presented with the plugin installation form for your blog. Click “Install Now” and the plugin will be installed. Much easier, and you know they’re getting the correct plugin.

Plugin authors can go here for more info. I’ll make sure these URLs forward to WordPress.org once we get it set up there, so you can start using this now.

Update: It has a bookmarklet now. If you click that bookmarklet from a WordPress Plugin Directory page, it’ll prompt you to install the plugin you were viewing.

Here’s a screencast showing it in action!

57 thoughts on “Plugin installer tool

  1. Doesn’t work for me. Always tells me that that URL is not a WordPress blog. Also, it returns fairly quickly, too quick to have actually checked anything, IMO.

    What is it looking for, exactly?

    • Replying to myself: I see that it looks for X-Pingback in the headers.

      That won’t work with a site using WP-Super-Cache, as that header won’t be there for non-authenticated users.

    • Huh, would have expected WP-Super-Cache to keep that header, as it is a standard WP header. I guess it can fall back to scanning the HTML for the Pingback endpoint.

    • Okay, it now looks for the following:

      1. HEAD against URL given, looking for X-Pingback header
      2. GET against URL given, looking for a URL ending in xmlrpc.php
      3. HEAD against URL given with “wp-login.php” appended, looking for X-Pingback header

      That should cover all but the strangest setups. It works on yours, now!

    • Works, but why not just GET the URL given and look for the meta head pingback code? You can check the headers at the same time.

  2. It just worked for me (although I don’t have WP-Super-Cache enabled due to its conflict with other plugins).

    Question: Is there a way to have it so the user doesn’t have to type in the dashes to match the exact slug path?

    Perhaps spaces could be substituted for dashes, which would make it idiot proof for the masses.

  3. I think you need to work on explaining the user why one blog has the ability to install a plugin on another. I’m guessing the security is still sound (it relies on you being logged into your blog already), but from their point of view, they’re not really seeing their own admin site branding anymore and don’t know what is going on.

    Granted, the type of person that is going to install a plugin like this isn’t going to be Joe Paranoid Internet User, but the whole point is to make installing plugins more accessible, so consider how this impacts your trust relationship with less savvy users.

    I got to our second screen the first time around (but didn’t complete the install process), but when I came back again, I had the same problem that Otto did (and I’m also using SuperCache).

    • It’s tricky, because that screen is normally presented in an iframe within WordPress. I have no way of launching that iframe from within the context of their blog… I can only present the iframe. And the iframe doesn’t have any branding.

      I could just redirect to the iframe on their site, but it there still wouldn’t be any branding, and they’d have to take note of the URL in the address bar.

      What I might be able to do is play with the iframe presentation. I’ve made it look seamless, but I could make it more of a lightbox presentation, which may make it obvious that the installation screen is coming from their site.

      Maybe in a future WordPress version, we can have a more integrated plugin installation screen built in, so I can just redirect to that, and it will be obvious that they are in their blog.

    • I think ideally, WordPress shouldn’t be letting that page be loaded like that.. for a few reasons i won’t go into.

      I would like for the extend directory to offer a “Install Now” dropdown style button that lets you install it straight to a blog you have.. But i’m not sure how that’d get integrated on .org..

      But my point is, It should redirect to the users own domain/installation and have a “Site xxx has directed you here, Would you like to install this Plugin|Theme?”

    • I think we need a way to request that the iframe is launched from a url argument so that you don’t have to wrap the site in an iframe.

      For people who aren’t logged in to their site – like I wasn’t – you get a wrapped WordPress Login screen which we shouldn’t be encouraging people to enter there username/password into as that just encourages them to fall for a phishing attack.

    • Peter: Thats pretty much what i’m thinking of, But as well as their WP login details, some people might not notice its not their blog, and that FTP credential screen isnt a WordPress page at all..

      I can see this functionality catching on with plugin authors, but i can tell that if it does, some malicious users will use it to phish their WP login/FTP creds

    • Most users are familiar with installing plugins and addons in their browser from websites. If this is integrated with WordPress.org in the future, it could just popup a warning similar to the one you get when installing a FireFox addon from an untrusted website.

  4. John L. says:

    For a slightly different implementation of the same idea, check out the SEO Ultimate plugin’s “Auto Installer” (after clicking the link, look for it in the sidebar)

  5. Why does WordPress need localhost FP details? Rather than the normal ‘connect to a remote server’ to download?

    • graq says:

      “WordPress asks you for the FTP login information to itself if the folder/files are not writable by PHP.”

      Really? That doesn’t sound right to me. What exactly does the webserver need write access to in order to not prompt the user (admin) with the ‘Connection Information’ screen? I have given full write access to the plugins directory.

    • “I forgot to mention that PHP also needs to be the owner of the files.”
      Do you mean the web server? PHP wont be a user in itself, unless you specifically created a ‘php’ user, which I doubt many people do.

      I’ve toyed with some of the wp-config settings on the codex page (http://codex.wordpress.org/Editing_wp-config.php), but I still cannot get it to work.

      Some serious magic-fu going on, that is not clearly documented.

  6. Facebook’s implementation of their API for data usage from other websites comes immediately to mind. I was perfectly comfortable with signing into my Facebook account when prompted with the Javascript form, but am immediately uncomfortable with allowing a remote site to let me redirect to a logged in portion of a WordPress admin page to then install software.

    Could we maybe setup functionality within a WordPress admin that allows a user to setup say a secret picture or phrase and then display it along with a permission dialog that says this other website is trying to install the following plugin on your blog, please be aware and allow or disallow? If not logged in, we could redirect to a login page, immediately followed by the message.

    Positive action that incorporates my blog’s unique identity for its admin is very important in my mind.

  7. Mark, this is beyond excellent!!!

    At the risk of sounding like I’m saying I had the same idea (I did; I was planning write in and then try to advocate for its inclusion in WordPress core + WordPress.org) I’m sooooo glad that you wrote it because you doing it means you see the value and as a core team member will work to get it integrated into the WordPress community; I think it can really help.

    Looking at the comments I’ll let the others discuss the security and trust issues with you but I’ll suggest that once its on WordPress.org at least that you cookie their domain name so they don’t have to enter it if they go to a second or third plugin site. Just a thought.

  8. Remember when you had to install WordPress plugins by uploading them manually via FTP?

    Yup, I remember that.

    Heck, I remember when there weren’t plugins, and you had to copy and paste PHP code!

    Oh yeah, I remember that too. I even recall when installing/upgrading WordPress sent the faint of heart running in the other direction. Does this mean I’m getting old?

    Nice job on the installer, Mark. As long as the process can be secured properly (which I’m sure it will be) it might just bring some needed standardization to the way developers offer up their plugins.

  9. As long as the ZIP archive option is still available and isn’t replaced by the installer as the only method. I always like to know what’s going on with my files, so use the FTP method through an SSH tunnel. I do my WP updates/upgrades the same way.

    A) I’m more than a little concerned about providing login credentials to my entire server just to allow WP to update itself. I’ve never found any documentation on how robust the security is or isn’t when doing that.

    2) An installer introduces another level of code to the process. More levels, more opportunities for bugs to creep in temporarily unnoticed. Not to say that the code won’t be up to snuff but $%!& happens and, when it comes to modifying files on my server–not just how those files run–it’s another level of concern.

    c) In some cases, some of the plugin code has been modified to take care of quirks/conflicts/bugs. Without having the pre-install/update opportunity to compare modified vs new files before pulling the trigger, the conflict will resurface until the code can be compared and new files overwritten with modified ones if necessary.

    4) My host, PairNetworks, has some configuration or other that has to be changed temporarily to allow automatic upgrades to work and then changed back. I haven’t looked fully into this because of reasons A, 2 and c.

  10. Would be priceless if it could do the same but via an svn checkout. I keep all my plugins as svn checkouts, so a one-click solution would speed that up (though not by much).

  11. It does seem that everybody is into this kind of stuff lately. Don’t really understand it though, but thanks for trying to explain it. Appreciate you shedding light into this matter. Keep it up

    Thanks
    Md.Alamin Khan

  12. Gerçekten WordPress plginleri işlerimize yarıyor ama bence wp nin biraz daha gelişmiş olması gerekiyor bu şartlar altında hızı falan yeterli değil hızlandıracak pluginler lazım arkadaşlar

  13. wordpress konusunda çok detaylı tartışmalar gerekli kurucularıyla vs. çünkü wordpress in bu kadar kullanıcısı olmasına rağmen yeterli sayıda özelliği yok iyi günler

    • Doesn’t work for me. Always tells me that that URL is not a WordPress blog. Also, it returns fairly quickly, too quick to have actually checked anything, IMO.

      What is it looking for, exactly?

  14. Donna says:

    hummm. just call me Joe Paranoid, per earlier comment. i found a plug-in i needed, it was using this plug-in method. i tried it, not thinking it would really work, it did. i promptly got worried, promptly uninstalled it, came searching and found this which does legitimate the method, but still, i don’t understand it so wouldn’t use it again.

    best
    Donna

  15. This is a great feature in WordPress.. but you are probably not right in your statement about earlier alternatives. I used a WordPress plugin named ” One Click Install” . It was really a great plugin – It could easily download and install themes from the source file ( WordPress Plugin Directory) . :)

  16. Thanks for your personal marvelous posting! I certainly enjoyed reading it, you can be a great author.I will be sure to bookmark your blog and will eventually come back in the foreseeable future. I want to encourage you to ultimately continue your great work, have a nice weekend!

Comments are closed.