6 Comments


  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?

    Reply

  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…

    Reply

    1. 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.

      Reply

      1. 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.

        Reply
  3. Melson

    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.

    Reply

  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.

    Reply

Leave a Reply