Directory Maintenance

Maintaining the directory can be a full time job. In order to do this, we rely on multiple tools to constantly scan, review, and monitor checkins. There are some filters on SVN that prevent dangerous code from being committed to the repositories, the rest of the work is done by scanning.

Removing Plugins Removing Plugins

Plugins are removed for reasons other than security, however that is the most recognized reason.

Any time a plugin is closed, the developers must be contacted, and the action must be logged on the private P2. If a daily post exists, add a comment with the plugin link and why it was closed. Otherwise create a new one.

Immediate Closure Immediate Closure

Plugins are closed immediately for the following situations:

  • Security issues
  • GPL violations
  • Flagrant abuse of other community members
  • Users being banned from the repository (all plugins are closed when this happens)
  • Intentionally disguising themselves to get around previous blocks/bans

Top ↑

Warnings Warnings

Except in extreme cases, make sure the developer(s) has received at least one warning before closing plugins.

Reasons to warn first:

  • Sockpuppets (delete all suspect reviews first)
  • Self promotion in related plugin support threads or reviews
  • Tag abuse
  • Readme scamming
  • Frequent commits to game the ‘recently updated’ list

If a warning has been sent with no response, send a second warning of “FINAL WARNING” and explain the behavior must stop. Provide them with a realistic due date. For example, if a plugin has been warned multiple times to stop making needless commits and tag abuse, allow them 4-5 business days to comply.

Top ↑

By Request By Request

Verify the request came from either a developer with commit access or someone who works for the company. If so, reply with the PreDefined email “Reply: Removal Request Completed”

Otherwise use “Reply: Removal Request – From email doesn’t match that of the plugin owner”

Top ↑

Scanning the Repository Scanning the Repository

This requires a local copy of the entire plugin directory which can be downloaded with the Plugin Directory Slurper. Alternatively you can use the unofficial WordPress Directory Search.

You can use grepack, or ag to scan the plugins repository.

Top ↑

Examples Examples

The following examples assume that you have a copy of all the plugins checked out into a folder called “plugins” and you wish to save your scans in a folder called “scans”

Looking for global $tag in all PHP files:

$ ack "global[^;]+\$tag" --php ./plugins/ > scans/global-tag.txt

Find everyone using http in an enqueue:

$ find ./plugins -type f -exec grep "wp_enqueue_\(style\|script\)\s*(.*[\"']http://" {} > scans/http-enq.txt

(On OS X, add \; after the {} to avoid the “no terminating…” error)

Find all instances of a specific file:

$ find ./plugins -type f -name "*datepicker-*.js" > scans/datepicker.txt

Top ↑

Summarizing Output Summarizing Output

Parsing the output can be difficult, since the output often looks like this:

.plugins/appmaker-woocommerce-mobile-app-manager/lib/appmaker-wp/endpoints/appmaker/class-appmaker-wc-rest-backend-posts-controller.php:705: $date_data = rest_get_date_with_gmt( $request['date'] );

In order to make life less insane, there’s a summarize script:

$ ./summarize-scan.php scans/rest_get_date_with_gmt.txt
5 matching plugins
Matches  Plugin                             Active installs
=======  ======                             ===============
      4  rest-api                                   40,000+
      4  wptoandroid                                    30+
      5  custom-contact-forms                       60,000+
      2  appmaker-wp-mobile-app-manager                 50+
      4  appmaker-woocommerce-mobile-app-manager       200+

This will not clean up false positives, so before you assume that’s your answer, do review the raw output to make sure you don’t have incorrect data.

Top ↑

Tools and Resources Tools and Resources