Recommendation: add notice about Plugin Guidelines

[maiki]

From https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/, specifically:

8. The plugin may not send executable code via third-party systems.

Externally loading code from documented services is permitted, however all communication must be made as securely as possible. Executing outside code within a plugin when not acting as a service is not allowed, for example:

• Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org’s
• Installing premium versions of the same plugin
• Calling third party CDNs for reasons other than font inclusions; all non-service related JavaScript and CSS must be included locally
• Using third party services to manage regularly updated lists of data, when not explicitly permitted in the service’s terms of use
• Using iframes to connect admin pages; APIs should be used to minimize security risks

and

13. The plugin should make use of WordPress’ default libraries.

WordPress includes a number of useful libraries, such as jQuery, Atom Lib, SimplePie, PHPMailer, PHPass, and more. For security and stability reasons, plugins may not include those libraries in their own code, but instead must use the versions of those libraries packaged with WordPress.

For a list of all javascript libraries included in WordPress, please review Default Scripts Included and Registered by WordPress.

I suggest adding a small note that including integrating your plugin will prohibit being listed in the public repo. :smile:

[ideag]

Hi @maiki, thank you for your suggestion.

I would argue, that using TinyLibraries would not make a plugin non-compliant with Guidelines. Because plugin author only adds a custom Plugin header line and a conditional function call. They can even use a fallback if TinyLibraries is not present. But that neither makes your plugin download external stuff (guideline 8), nor not use default WP libraries (guideline 13) - TinyLibraries is only about libraries that are NOT included in WP Core.

TinyLibraries itself, of-course, does violate Guideline 8 and I have no hope of getting it into the wp.org repo anytime soon. It also goes against the policy of not accepting framework type of plugins, too. But that should not prevent other plugins declaring compatibility with it and getting accepted to the repo.

Would you not agree with that?

[maiki]

It allows plugin developers to define what libraries they require for their code to function in plugin headers

In this example plugin declares that it requires WP Background Processing library.

Emphasis mine. In this sense, "compatibility" means in order for the plugin to work correctly, it requires a third-party plugin that will do the prohibited stuff... sounds sketchy, hence my recommendation.

I have zero want to discuss this at length, because you understand my stance and disagree. We've reached the crux of this discussion.

[ideag]

In this sense, "compatibility" means in order for the plugin to work correctly, it requires a third-party plugin that will do the prohibited stuff... sounds sketchy, hence my recommendation.

Not true, plugin developers can provide a fallback to function properly without TinyLibraries. TinyLibraries is just a way to organize such libraries better. Something like this:

if ( ! function_exists( 'TinyLibraries' ) || ! TinyLibraries()->require_library( 'butterbean' ) ) {
  require_once( 'path/to/my/local/copy/of/butterbean.php' );
}

On a more fundamental level, I think something like that ideally should be a part of the Core. This plugin is just a demonstration/proof-of-concept of how it should/could work.

Anyway, to be certain, I'll reach out to Plugin directory people to get an official stance on this.