Plugin Author Admin

[obenland]

• Create a Plugin Author role.
• Allow access to Plugins they authored or have commit access to.
• Automatically subscribe authors to review and support feeds. See ​this comment.

They can change "Tested up to", Tags, and add/remove committers. It would probably make sense to keep the title and content around but not editable for context.

[dd32]

In 2562:

Plugin Directory: Add the starts of a Plugin Committers metabox & the methods required to alter the database records.
See #1571

[Otto42]

Automatically subscribe authors to review and support feeds.

Make sure there is an unsubscribe option as well. I don't want to receive those emails.

[Otto42]

After more thought, I would rather not have this automatic subscription option enabled at all. Instead, we could make it opt-in still, but more prominently displayed somewhere.

My concern is with the emails being sent by WordPress.org to not be perceived as "spam" by systems like Gmail and the like. If we start sending them automatically, then that's a risk. An opt-in is better than an opt-out here.

[imath]

Replying to Otto42:

Instead, we could make it opt-in still, but more prominently displayed somewhere.

+1

[Otto42]

Okay, so, existing Role explanation:

Plugins don't have "Authors" or "Owners" in the current system.

Plugins have:

• Committers. These are people who have commit access to the plugin's SVN tree. Committers can add new committers by w.org usernames, and remove existing committers (including, until recently, themselves, to much hilarity for all involved).
• Contributors. These are people who are listed in the readme.txt file and who thus show up as the "Authors" of the plugin on the plugin page. This also affects their profile on profiles.wordpress.org, as in those plugins show up on their profile.
• "Primary Author". This is a mostly unused field which is the author of the "topic" in the bbPress installation. It is the original submitter of the plugin entry, and though we retain it (and serve the information as "author" in the API), it is unused by pretty much everything. We keep it around for historical information only. It occasionally comes in handy when resolving disputes as to who "owns" a plugin, but mostly it's useless. Note that this can be changed on the plugin Admin screen by directory Administrators, but not by anybody else. We don't change it without a valid reason. Again, historical context.
• Administrators (plugin reviewers). All reviewers have admin access to the plugin directory. They can see closed plugins, disabled plugins (hidden but which still serve updates), and the Admin screen for all plugins. They can change any data.
• Moderators. We don't use this in the current bbPress system. Admin or nothing. This is room for expansion in the new system if needs be.

Like themes, plugin committers have no backend access. Only access to the special "Admin" button on the front end, which grants them the ability to add or remove other plugin committers. This gives them, as one would guess, commit access to that plugin's SVN directory, after the sync process which happens once an hour. Nothing more than that.

[obenland]

Let's not take over the Generate POT file and Add Domain to Gettext Calls parts. See ​https://wordpress.slack.com/archives/meta/p1457113478001511

[dd32]

Just noting that providing multiple users access to editing a post, without letting them edit every other post, is currently blocked by ​#wp36056

[obenland]

Replying to dd32:

Just noting that providing multiple users access to editing a post, without letting them edit every other post, is currently blocked by ​#wp36056

Just to be as clear as possible, that only concerns Committers, not "Primary Authors" as they'll be listed as the Plugin's author, correct?

[dd32]

Just to be as clear as possible, that only concerns Committers, not "Primary Authors" as they'll be listed as the Plugin's author, correct?

Correct, but the "Primary Author" is never exposed anywhere, it's a datapoint that is ignored everywhere.

[obenland]

In 2752:

Plugin Directory: Allow plugin committers to be added and removed.

Still needs cap checks.
Uses wpList to seemlessly add/remove committers. Works similar to the
category meta box.

See #1571.

[obenland]

In 2753:

Plugin Directory: After [2752], improve error handling and docs.

See #1571.

[obenland]

@ipstenu's thoughts on plugin admin:

• Tested up to
• Tags
• Committers
• Contributors
• Support moderators for plugin forums

We have the first three covered already. We should discuss if contributors (see definition in 8) should be displayed in the admin as well, or if it should stay in the readme.

Support moderators for plugin forums feels like a low priority feature to me. We could think about creating a ticket for it and circle back to it after the initial launch.

[DrewAPicture]

Replying to obenland:

Support moderators for plugin forums feels like a low priority feature to me. We could think about creating a ticket for it and circle back to it after the initial launch.

I'd be curious to know what the experience is like for a non-moderator plugin author. I was always under the impression that being able to sticky posts and have some measure of control over your own plugin support forum was an oft-requested feature before whatever version of that was implemented in the current repo.

@ipstenu: What do you think?

[obenland]

In 2763:

Plugin Directory: Move list table classes into their own directory.

See #1570, #1571.

[obenland]

In 2764:

Plugin Directory: After [2763], update @package docs.

See #1570, #1571.

[Ipstenu]

Replying to DrewAPicture:

I'd be curious to know what the experience is like for a non-moderator plugin author. I was always under the impression that being able to sticky posts and have some measure of control over your own plugin support forum was an oft-requested feature before whatever version of that was implemented in the current repo.

Not super often. All they really wanted was sticky and mark resolved. These days maybe once a month someone wants a sticky topic closed. I think we could even do away with that if we had something that hooked into the readme or the plugin repo admin page.

'Sticky Notice' - and that would show on the top of the forums. Be a lot easier for the plugin admins to control and edit and update as needed.

[obenland]

In 2776:

Plugin Directory: Make edit.php more of a dashboard for plugin authors.

H/t mcguive7.

See #1571.

[obenland]

edit.php after [2776].

[dd32]

In 2777:

Plugin Directory: Introduce the Plugin Committer/Review & Admin roles. Use the capabilities throughout the core flows of the admin.
This also has a few hacks to make plugin committers/authors only see plugins which they can manage, although a few core bugs remain which cause non-owner committers not to be able to edit plugins properly.

See #1571

[obenland]

In 2788:

Plugin Directory: Don't let Plugin Committers and Reviewers quickedit plugins.

Only PLugin Admins and above have the necessary privileges to change the things
quickedit allows users to change.

See #1570, #1571.

[obenland]

In 2790:

Plugin Directory: Don't show review tools to Plugin Committers.

See #1570, #1571.

[obenland]

In 2791:

Plugin Directory: Show Plugin Committers their unpublished plugins as well.

See #1571.

[obenland]

Plugin Authors currently can't edit a plugin that is in review. In reality that only prevents them from changing tags, as committers can currently still be added/removed. Should we allow Committers to change tags while their plugin is in review, or should we prevent them from adding/removing committers?

/cc @Ipstenu @dd32

[Ipstenu]

I think it's fine as-is.

Not being able to change tags at this point will stop some of them from being really silly.

[obenland]

In 2792:

Plugin Directory: Prevent Committers from accessing certain admin pages.

This can be extended as needed.

See #1571.

[obenland]

In 2793:

Plugin Directory: Don't link to non-existent plugin previews.

See #1570, #1571.

[obenland]

In 2798:

Plugin Directory: Handle list view links in Plugin_Posts class.

Overwrites WP_Posts_List_Table's get_views() method, taking plugins into
account that the current user might not have authored, but has commit access to.

See #1570, #1571.

[obenland]

In 2829:

Plugin Directory: Don't use context outside the admin.

Since there is no title in edit.php, we need a context to let users know
plugin they're currently editing. In the toolbar that context is not available
however.

See #1571.

[obenland]

In 2830:

Plugin Directory: Capability improvements.

• Fill built-in roles with custom caps.
• Let Plugin Reviewers be able to manage their own plugins like regular authors.

See #1570, #1571.

[obenland]

In 2836:

Plugin Directory: Cache commit access data to avoid multible db calls.

Reduces DB calls on edit.php from 127 to 11.

See #1570, #1571.

[dmchale]

+1 for a better way for plugin authors to know they NEED to subscribe to their support forums. After playing with the "WP Dev Dashboard" plugin today, I only just found out that one of my plugins had 2 support forum posts from 3 months ago. I never fathomed I would have to "opt in" to receive those notifications, as the plugin author. If it's to remain an opt-in feature that's still fine, I understand otto's concerns mentioned above - as long as it's much more prominently displayed.

[Ipstenu]

Honestly? Plugin developers don't HAVE to support their plugin. Do they don't need to monitor the forums and get alerts (which only work anyway if users post in the right places). It's a convinience for those who do, and should be more obvious, but no, this should not be the default.

Having it as opt-in when, say, you submit the plugin would suffice. It would be part of the submission process and maybe a toggle on the admin dash for later monitoring. "What plugins AM I subscribed to?"

[obenland]

In 2860:

Plugin Directory: Display the amount of unresolved support topics.

support_resolutions gets updated from the support forums side.

See #1571.

[obenland]

In 2971:

Plugin Directory: Fix typo to avoid undefined variable notice.

See #1571.

[obenland]

In 2977:

Plugin Directory: Use html() to display error message.

Actually displays username in code tags now when a new committer could not
be added.

See #1571.

[obenland]

In 2979:

Plugins Directory: Smoothen out capability set up.

Only adds caps to built-in roles if they still exist.
Sets the default role to what plugin authors/committers will have.

See #1570, #1571.

[obenland]

In 2983:

Plugin Directory: Add meta data on plugin submission.

Adds readme meta data to the plugin post after uploading a new plugin.

See #1570, #1571.

[obenland]

In 3029:

Plugin Directory: Promote authors without a role.

Gives authors access to manage their plugin(s) if they don't have that already.

See #1570, #1571.

[obenland]

In 3128:

Plugin Directory: Allow plugin authors to edit their own plugin.

Gives authors access to their plugin when they don't have commit to it yet.
Happens between first submitting a plugin and it getting approved.

See #1571.

[obenland]

In 3129:

Plugin Directory: Give authors/committers a role on the site.

Disabled until capabilities have been properly reviewed.

See ​https://wordpress.slack.com/archives/meta/p1463104152001314
See #1571.

[obenland]

In 3131:

Plugin Directory: Let committers only see plugins they created and have commit to.

Reverts part of [3093].
See #1571.

[obenland]

In 3329:

Plugin Directory: Show Mine view to authors with one unapproved plugin.

See #1571.

[obenland]

In 3330:

Plugin Directory: Don't let plugin authors quick edit their plugins.

See #1571.

[obenland]

In 3332:

Plugin Directory: Fix a bug where plugin names in count query were escaped.

Introduced in [3329].

See #1571.

[obenland]

In 3333:

Plugin Directory: Make it clear to use usernames to add committers.

See #1571.

[obenland]

In 3350:

Plugin Directory: Show plugin's permalink in wp-admin.

Gives plugin authors a convenient way to view their plugin on the front-end.

See #1571.

[obenland]

In 3383:

Plugin Directory: First pass at a readme validator.

Adds an admin UI and the basic infrastructure to validate readme files.
Needs some more work in the parsing part.

See ​https://wordpress.slack.com/archives/meta/p1466062950000169.
See #1571.

[ocean90]

@obenland Tags like <code>Contributors</code> shouldn't be made available for translation:

/* translators: "Tested up to" */
sprintf( __( '%s is missing.', 'textdomain' ), '<code>Tested up to</code>' );

[obenland]

In 3400:

Plugin Directory: Only show permalink for plugins.

See #1571.

[obenland]

In 3413:

Plugin Directory: Don't make readme tags available for i18n.

See #1571.

[obenland]

In 3414:

Plugin Directory: Don't verify referer if nothing was submitted.

See #1571.

[obenland]

In 3506:

Plugin Directory: Add a metabox to allow committers to change the primary author.

See #1571.

[samuelsidler]

Milestone Plugin Directory v3 - M1 deleted