Cancel

Jeff Chandler

Alex Shiels Proposal For Improving The WordPress Plugin Management Page

While WordPress 3.8 and 3.9 substantially improved the theme experience within WordPress, the plugins page hasn’t had the same treatment. In fact, the page hasn’t changed much since 2.7.

WordPress 2.7 Plugins Page
WordPress 2.7 Plugins Page

However, that may change as Alex Shiels has proposed a detailed outline explaining the improvements and changes he’d like to see. According to Shiels, the goal is to improve the experience for both new and experienced users.

One of the suggested improvements is to have the plugin-install.php be the default page when selecting the Plugins menu in the backend of WordPress. I generally use the plugins page to activate or deactivate plugins for troubleshooting purposes. By making plugin-install.php the default page, it would require an extra step to browse to the installed plugins page.

Instead, I’d rather the default page be left alone and enable the search box to find plugins within the directory. Other users have chimed in with similar feedback. As Shiels mentioned, “the Search Installed Plugins box on plugins.php is easily mistaken for a plugin directory search.”

Users Mistakenly Use The Search Box To Search The Plugin Directory
Users Mistakenly Use The Search Box To Search The Plugin Directory

I want the search engine for plugins to be improved. I’d also like to be able to organize search results by ratings, reviews, download count, etc. I’m happy to see the tag cloud may potentially be removed in favor of specific categories.

Something I’d love to see is the ability to rate and review plugins from the backend of WordPress. This way, I wouldn’t have to visit each plugin’s page on the directory to give feedback. I’d also like to be able to access that information somehow on the Installed Plugins page.

I think the Visit Plugin Site URL should link to the WordPress.org page listing for the plugin, not the author’s website. It would make it a lot easier to find the appropriate location to get support or view other data about the plugin on WordPress.org.

User Submitted Ideas

There are a lot of great ideas in the comments of the post. For instance, Brad Tousnard suggested a Plugin installation that uses AJAX to install plugins in-place instead of having to go through a series of steps or have separate browser tabs open to install multiple plugins.

The plugin page doesn’t show whether or a not a plugin is dependent on another to work properly. Although there is a four-year old trac ticket that has a lengthy discussion about the topic, nothing concrete has been established. Once it’s out, the next step would be to create an easy way to see those dependencies when searching for plugins.

How to Get Involved

Since nearly everyone has experience managing plugins in WordPress, it’s no wonder the post is generating so much feedback. If you want to get involved with helping Shiels make improvements to the page, keep an eye on the Plugins Component on Trac. This is where tickets specifically for that part of WordPress will be located. You can also leave feedback on the post with suggestions you have.

What changes would you like to see that would improve searching, adding, and managing plugins in WordPress for new and advanced users?

Category: ,
Tags: ,
6

6 responses to “Alex Shiels Proposal For Improving The WordPress Plugin Management Page”

  1. I am just curious…why do we need a search box for installed plugins?

    how many plugins could an average site use? Can’t you scroll down the page?

    I don’t think I had enough plugins that my plugins page will go to page 2/3/4/5/etc…

    Unless you are a big tech website or similar…why do you need to SEARCH for a plugin on your own site?

    Create forum topic from comment

  2. I agree with Miroslav…

    That said, I would love to see the search results only showing plugins that are compatible with my WP installed version. If I’m running a WP 3.9 installation, I don’t need to see plugins that work up to V2.5.

    I’m going to get off the subject a little bit, and probably be controversial. My suggestion would be to have 2 plugin depositories to begin with. One that will host only current plugins. So, for now, if any plugin that is not compatible up to v3.9 should be removed from the main depository and placed in the second depository, call it archive depository or whatever else you want. With every new WP version, it should be up to the developers to update the compatibility data (compatible up to 3.9 etc…). If they don’t do it in a timely fashion, the plugin should be archived and moved away from the main depository, and placed in the second one. If those developers want the promotion back to the main depository, update the data, and if needed the plugin itself.

    I cannot tell you how many plugins I see that some users say they work, and some don’t, for the same plugin and WP versions. There is no grey area here, it either works or it does not. We should force the plugin developers set the record straight in a timely fashion, or force the plugin to be adopted by somebody who will be more responsible, and in the meantime demote it to the archives depository.

    So for me, it’s not how the plugins are found in the backsite, but the chaotic way that the whole plugin depository is organized and operated.

    If anything, give us at least better filtering tools like version compatibility, and average ratings, just to mention a couple of filters that will make finding things easier and faster. If these filtering tools (advanced search forms) get created, then there should not be the need of a second archives depository as I suggested above. The themes have advanced searching, why not the plugins, that is needed even more?

    Just couple of suggestions to make my life easier…

    Create forum topic from comment

    • There would need to be an update to how those compatibility tags are handled before that could work, as those tags are essentially useless at the moment. The plugin developer needs to update the readme file with EVERY WordPress update just to keep that tag current at the moment, which is something most of us can’t be bothered doing.

      Create forum topic from comment

      • Maybe track Plugin compatibility by major core version, rather than by minor version? That would make things quite a bit easier for Plugin developers to maintain.

        The other thing is that such information needs to be de-coupled from the readme-parser jump to the latest Stable tag.

        If, however, developers could simply update the compatibility tags in trunk, life would be much easier. Unfortunately, the parser looks for “stable tag”, and if found, continues parsing not from trunk, but from the readme in the found stable tag. So, even if Plugin compatibility is updated in trunk, users won’t see the change.

        As it is currently, to update version compatibility, Plugin developers either have to modify an already-tagged version of the Plugin (non-optimal for proper version control; once it’s tagged, it doesn’t change), or release a point version just to update the compatibility information.

        So, provide Plugin developers some way of providing Plugin meta data that is separate from the stable-tag readme file.

        Create forum topic from comment

  3. I’ve found that there is a grey area: sometimes I’ve installed three-year-old plugins that work without any problems, and sometimes new and compatible plugins conflict with installed plugins, so the plugin’s age is probably not the right way to filter out plugins from the directory.

    But if we could give feedback from the plugin management screen directly, as Jeff suggests, it would be easier to filter out any incompatible plugins.

    Create forum topic from comment

  4. Just say “no” to implementing more AJAX solutions in WordPress. Its usability is decaying thanks to AJAX. I am sick and tired of AJAX. It is way overused by people who don’t think about the consequences of continually loading content into a browser window, or about how frustrating it is to watch a greyed-out screen try to get around an obvious timeout error.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d