Restrict custom plugin headers

[ernilambar]

Restrict plugin headers used for updaters.

Example:

GitHub Plugin URI: johndoe/package
Bitbucket Plugin URI: johndoe/package
...
etc

Those are not supposed to be in the plugins hosted in WordPress.org plugin directory.

[davidperezgar]

Yes, that's necessary. And It should be an ERROR with severity 7.

[afragen]

As the developer of Git Updater it would have been nice if y'all reached out to me to ask. The headers are harmless to any plugin in the repository as Git Updater will preferentially update from the Plugin Repository for any integrated plugin that is running on the primary branch/release branch.

[davidperezgar]

No, it's not allowed a different updater that Wordpress.org for the plugins hosted.

[afragen]

It uses the dot org updater and serves updates from dot org for the primary branch.

[afragen]

It only serves updates for development branches and only then if the Git Updater plugin is installed and activated.

[costdev]

As noted by @afragen in the related issue:

FWIW the WordPress Beta Tester plugin has had this header in place for years.

This header has been in place and has been known about for years, and has not been a problem.

I ask that this is reconsidered given this.

[sc0ttkclark]

This is really disappointing to see that being included. I know so many plugin devs who have this here precisely to allow folks to beta test their plugins. Given that WP plugin directory informs us to not use .org repo to develop on and only for releases, that leaves folks with very few options.

I politely request a reversal on this.

[kraftbj]

I agree this should be reverted. If the site owner has installed the Git Updater plugin, then this header provides information for it. The fact that it is present doesn't provide for a third party update. Guidelines 3 and 8 are applicable, but neither apply to simply the header.

The Git Updater code itself is not allowed in the repo, but restricting these headers do not make sense.

Blocking the Update URI header if it says anything other than Wordpress.org or w.org, however, does make sense since that would prevent the repo from being used as the update source.

[jb510]

Plugin and theme headers have always been extensible by design. Update uri’s were added after years of extensive core discussion (plugins 5.8. Themes 6.1). This should be immediately reverted.

[lucprincen]

Why has this suddenly become a problem? Please list the issues these headers have caused for people, because I can't seem to find them.

These tools are mainly used for testing, not side-loading. You have made the life of me, as a plugin developer, unnecessarily hard.

[Zodiac1978]

Even this longer explanation shows that it should be allowed:
https://make.wordpress.org/plugins/2017/03/16/clarification-of-guideline-8-executable-code-and-installs/

[xwolfde]

Many internal plugins that are never intended to be published on wp.org are developed on behalf of agencies. The use of the PCP is also desirable for such plugins. Because if agencies were to get used to the required quality of the PCP, this would in turn benefit all public plugins.
Therefore, the restriction would have a bad effect, because it would result in agencies or clients omitting the PCP or questioning it.

[xwolfde]

A suggested solution that should satisfy everyone:
Introduce a checkbox when starting the plugin, like this:

[ ] Test organizational requirements for publishing the plugin on wp.org

This would allow you to differentiate between tests that concern programming quality and those that only concern the rules for publishing on wp.org.
This could also solve the problem of hidden files ( #692 ), for example. These would also only be prohibited on wp.org, but would be allowed in the developing process (e.g. the .gitignore).

[chriscct7]

Re: feedback from today, the Plugins Team has posted a note on the ticket the Team asked @afragen to open originally to investigate the false positive issue here: #718 (comment)

We're going to restrict this issue so that we can keep a single unified conversation on the same topic and therefore more easily address anything. Please feel free to read through the reply on #718 and contribute on that ticket :)