WordPress.org

Make WordPress Core

Opened 4 weeks ago

Last modified 3 weeks ago

#44198 reopened enhancement

add "Multisite support" readme header to plugin directory

Reported by: littlebizzy Owned by:
Milestone: Awaiting Review Priority: normal
Severity: minor Version:
Component: Plugins Keywords: 2nd-opinion close
Focuses: multisite Cc:

Description

Building on the recent "Requires PHP" readme.txt header addition:

https://make.wordpress.org/plugins/2017/08/29/minimum-php-version-requirement/

Multisite support could also be specified, e.g.:

Multisite support: No [Yes]

Change History (9)

#1 @swissspidy
4 weeks ago

  • Keywords reporter-feedback added

Hi there!

What's the purpose of this line besides displaying the info in the plugin repository?

There are a couple of tickets about leveraging the PHP version field to prevent installing incompatible plugins etc.

Would you want to prevent installing plugins on a multisite that say they aren't compatible? I'm not sure this would be feasible.

#2 @littlebizzy
4 weeks ago

Would you want to prevent installing plugins on a multisite that say they aren't compatible?

Potentially yes, or at least for a notice/warning in the plugin directory.

Would avoid a huge amount of support questions, etc.

Defaulting to "No" or "n/a" unless "Yes" is specified would be ideal, in our opinion.

#3 @knutsp
4 weeks ago

A simple plugin doesn't need to "support" multisite, it just works as on single site.

This may be more confusing than informational.

#4 follow-up: @littlebizzy
4 weeks ago

A simple plugin doesn't need to "support" multisite, it just works

Don't think so, friend:

https://www.google.com/search?q=make+wordpress+plugins+multisite+compatible

By not having such a notice/warning, one could argue the plugin directory is insinuating Multisite support as being the norm, when in fact the majority of plugins are not tested by their author in a Multisite environment.

This inherently introduces Multisite installs to more security/stability risks...

#5 @knutsp
4 weeks ago

Your search does not make my statement invalid, only that there are a lot of questions and issues, which is very true.

Typical issues in single vs multisite are global resources like user management, caching, .htaccess manipulation and mu-plugins insertion.

Plugins that target multisite specific things are marked "Network only".

But thousands of plugins are more like "Hello Dolly" or a bit more advanced. It will be hard/impossible to make those authors claim multisite support, so they will stand without, or as "Multisite support: No".

A thinkable tri-state value (Yes,No,n/a) will not make this better, and the wast majority of plugins will then have "n/a". Plugin authors most, those who make the simple ones, do not test with multsite and may insert "No" when there is no multisite issue at all.

The solution to this "illiteracy", imho, is not a new header, which is likely to create as much confusion as without it, is simply education and documentation. This can be better.

Last edited 4 weeks ago by knutsp (previous) (diff)

#6 @littlebizzy
4 weeks ago

A thinkable tri-state value (Yes,No,n/a) will not make this better, and the wast majority of plugins will then have "n/a". Plugin authors most, those who make the simple ones, do not test with multsite and may insert "No" when there is no multisite issue at all.

On the contrary, it would make things infinitely better:

-- conscious, informed decision making (for both users and plugin authors)

-- purposeful code and environment clarity

-- better directory organization

Instead of "n/a" perhaps it could be more literal: "Unknown."

Any argument you could make for "Requires PHP" headers you could double-down on for "Multisite support" headers. It's time for WordPress.org to acknowledge that Multisite is not the same CMS as single-site WordPress.

And yes, any plugin that hasn't been tested on Multisite shouldn't be assumed to support it.

None of this would prevent "determined" Multisite fans from installing plugins at-will.

#7 in reply to: ↑ 4 @jeremyfelt
3 weeks ago

  • Keywords reporter-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Replying to littlebizzy:

By not having such a notice/warning, one could argue the plugin directory is insinuating Multisite support as being the norm, when in fact the majority of plugins are not tested by their author in a Multisite environment.

I agree that most plugins are likely not tested by their authors in a multisite environment. However, I don't think most of these plugins are incompatible with multisite. Many of the APIs used by plugins work exactly the same in both environments and there is no reason to expect a difference.

Adding a header for multisite compatibility would likely leave most plugins reporting as incompatible with multisite. Plugin authors would not really have a compelling reason to test in a multisite environment and manually confirm.

In the rare case where a plugin is compatible with single-site and not with multisite, I would rather find a way to document an alternate approach or address any underlying bugs in core so that it doesn't remain a compatibility problem.

#8 @littlebizzy
3 weeks ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened
Adding a header for multisite compatibility would likely leave most plugins reporting as incompatible with multisite. 

That is precisely the point, and precisely what is true currently.

Plugin authors would not really have a compelling reason to test in a multisite environment and manually confirm.

Exactly the opposite -- by adding such a header plugin authors would be forced to clarify whether their plugin supports Multisite or not, in exactly the same manner as the Requires PHP header.

Would be nice to hear from more of the Plugins team. I'm reopening this, since it allows us to do so. This ticket could alternatively be re-named : Remove Requires PHP header unless Multisite Support header added.

#9 @jeremyfelt
3 weeks ago

  • Focuses multisite added
  • Keywords 2nd-opinion close added
  • Milestone set to Awaiting Review

Happy to leave this open for more discussion.

I'll reiterate that I don't believe most plugins are incompatible with multisite.

Note: See TracTickets for help on using tickets.