Making WordPress.org

Opened 6 years ago

Last modified 7 months ago

#3845 new feature request

Linting for Plugin Submissions + Filters for Plugin Directory Searching

Reported by: s3w47m88's profile s3w47m88 Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords: 2nd-opinion needs-screenshots
Cc:

Description (last modified by dd32)

I was asked to repost this here and told I could link to the original Ticket: https://core.trac.wordpress.org/ticket/45005


This is apart of a bigger project for my staff and I, you can find the context here https://www.theportlandcompany.com/2017/09/10/proposed-improvements-to-the-wordpress-ui/.

Although this particular, and final, ticket, is slightly off-topic from that post but was born from wanting to preserve "The WordPress Way" and modern UI design principles.

Currently, when installing Plugins, you:

  1. Search for a Plugin to fill a need.
  2. Narrow it down to X Plugins you want to test.
  3. Install them all.
  4. Activate one.
  5. Deactivate, activate another and compare.
  6. Repeat until you've tested them all.
  7. Choose the one you want and move on.

The Problem

9 out of 10 times we're just checking to see if the Plugin isn't absolute garbage. Reviews are helpful sometimes, but how many reviews does one have to sift through to answer X questions? Often times reviews never even answer basic questions like:

  • Does this Plugin register alerts properly?
  • Can those alerts be dismissed?
  • Does this Plugin add things across the admin or does it keep itself contained to it's admin pages?
  • Does this Plugin properly register all of it's scripts?
  • Does this Plugin register scripts on the front end? Back end? Both? Neither?

And we can imagine many other questions like these.

But to have to install a Plugin, and in some cases use it extensively, just to answer these kinds of technical but essential, questions is very time consuming. Leaving a review for every bad Plugin out there becomes a part-time job and often doesn't result in an improvement to the Plugin in the end anyway.

With tools like linters or unit testing, we wonder why are we manually testing things like this *if* it could be automated to some degree? Why don't these things affect the score / rank of Plugins in the directory when searching so well-built Plugins are ranked higher than poorly built ones?

The Conceptual Solution

So, we propose the following. But we realize this is a large undertaking that affects a lot of things. It's probably something that needs to be introduced incrementally and probably not exactly as we propose.

  • On each Plugin's page in the Directory would be a sidebar that lists an icon.
  • Hovering over the icon would display the question. Ex. "Does this Plugin register all of it's scripts properly?"
  • If the answer is yes, it's green. If the answer is no, it's red. If it's not applicable either the icon could be gray or just not appear.
  • The answers to these questions could be answered automatically when a Plugin is submitted to the repository. Run through a linter of some kind which generates a JSON file, or values in a database that the Plugin Directory Page users.
  • There could be two columns of these icons. One for the system to automatically evaluate, the other for the developer to give an answer. Since algorithms aren't always perfect it ensures developers have a voice (like the ability to reply to a bad review) and for us to improve the system based on those use cases.
  • Then, we introduce Filters to the Plugin Directory Search and Filter utility, both in the WordPress Plugins page in WordPress itself, and on WordPress.org. This would allow users, like us, to say "Only show me Plugins that meet these standards."

Once initially implemented, like Advanced Custom Fields Plugin, this could be scaled quiet easily. Could also become contextual and expand way beyond basic Plugin standards.

For us, we hate Plugins that don't register scripts correctly, introduce their own color scheme to things where they're not allowed to (ex. menu icons, settings pages). We also hate that every Plugin seems to introduce their own types of metaboxes and placement of them on their pages. Even if they look and work great it's not "The WordPress Way" and is disorienting.

Our Effort

We're happy to create some designs to show what this all would look like, and a flow chart to show how things connect if this is something the leadership want to entertain. And if it gets far enough along, certainly contributing code level solutions.

Change History (7)

#1 @garrett-eclipse
6 years ago

Thanks @s3w47m88 appreciate you opening here.

#2 @dd32
6 years ago

  • Description modified (diff)

#4 @dufresnesteven
5 years ago

This is tricky.

I feel like tooling has come around to be able to do this with fair accuracy but I'm not certain the directory should be responsible for it.... unless it held a much more opinionated way of how plugins should be architected/coded. This would undoubtedly result in endless conversations of how to build plugins. Coding standards are typically fluid. What you may consider necessary, may not be for others.

This sounds like a great plugin to write though!

This ticket was mentioned in Slack in #design by estelaris. View the logs.


4 years ago

#6 @estelaris
4 years ago

  • Keywords needs-screenshots added; ui-feedback ux-feedback removed

this ticket was mentioned in design triage today and we need more information before we can propose a solution. @s3w47m88 would you like to provide a screenshot of what you are proposing?

#7 @dd32
7 months ago

  • Milestone Improved Search deleted
  • Type changed from enhancement to feature request

Just removing this from the Search related tickets, as it's not really search-related, but rather additional information about plugins that could help with deciding which plugin to install.

Similar tickets: #4309, #3126, #7452

Note: See TracTickets for help on using tickets.