Now that developer.wordpress.org is truly taking shape, it would be great if we could start thinking about how we can get contributor activity appearing on a person's profile.

So far we have the following activity:

1. Contributions to the theme and plugin developer handbooks:

​https://developer.wordpress.org/plugin/credits-2/ ​https://developer.wordpress.org/theme/credits/

2. Submitting a user contributed note

For example: ​https://developer.wordpress.org/reference/hooks/wp_get_attachment_image_attributes/#comment-61

And possibly (when the workflow is sorted)

3. Having a suggestion approved for changes to curated code reference content

It would be cool if contributors could get a badge under the following circumstances:

• anyone who is listed as contributing to the handbooks
• anyone who has 10 or more user contributed notes approved in the code reference

Plugin and theme authors currently have the power to mark threads as resolved within their own support forum, which is great.

Problem description However, some of the larger plugin/theme shops have a support team to help out on their own support forums. I think it would be useful to be able to recognize those people in the support forums, like we’re able to recognize authors.

Proposal So what I would like to propose is adding a new role: Plugin/Theme Support. Everyone with this role should have rights to mark topics within their own support forum as resolved, and should not be affected by posting speed limitations for their own support forum. This role should also show in the forums as ‘Support’, similar to author.

The reason why I propose a new role, instead of adding the capability to the contributor role is because, in my opinion, they serve a different purpose. Let me explain.

A contributor is someone who helped your open source project forward. This can be by providing feedback, writing code, creating images, doing marketing or being a friend of the project, for example.

Someone working on support does contribute his/her (paid) time to your project and is in that way a contributor. However, I think there are more than enough valid use cases where you don’t want someone who contributed code (for example) once to be able to close support request on behalf of the author.

That’s why I think having a separate support role would be viable. It would show the community that this person is vetted and answering on behalf of the plugin/theme author.

Related ticket This proposal is related to ticket #2598.

Managing support role Of course, it should be possible for plugin authors to manage the list of support people. I see two reasonable ways to do so, which should be mutually exclusive.

One way is by adding the usernames to the readme.txt file, the same way contributors are currently added. The other way would be to add users the same way committers are currently added, on the Advanced View of the plugin.

Showing support staff To be transparent about this, we’d probably also need a place to list people in the support role. This could be the Advanced View page, or even the plugin page itself.

When a user wraps text in their forum posts with "<li>" tags - The layout of the page breaks.

For an example of this see - ​http://wordpress.org/support/topic/please-ignore-just-testing-something?replies=1#post-4430248

Go to developer.wordpress.org and search for add_attachment hook:

​https://developer.wordpress.org/?s=add_attachment

You'll get 5 duplicate results for a single hook:

• ​https://developer.wordpress.org/reference/hooks/add_attachment-5/
• ​https://developer.wordpress.org/reference/hooks/add_attachment/
• ​https://developer.wordpress.org/reference/hooks/add_attachment-4/
• ​https://developer.wordpress.org/reference/hooks/add_attachment-3/
• ​https://developer.wordpress.org/reference/hooks/add_attachment-2/

Hello,

While I was working on these tickets: #2100 and #2907

I've noticed that my error log was getting grumpy and I saw this error:

[22-Jul-2017 11:26:20 UTC] PHP Notice: Undefined index: consumer_key in tggr-source-twitter.php on line 152

For some reason when you view the results page on the front end the twitter module bugs out randomly ( not all times ) and after that php error all the settings are getting reset so you are losing all login information etc.

I haven't been able to find out why.

@dipeshkakadiya is on it for a solution so we can implement it on gwtd3 new website as well.

Pointers for devs: Grab the /trunk of Tagregator through svn, apply the extra patches to have the latest as they have not been implemented yet and then work on this ticket.

When toggling a status in the Flag section, the toggle afterwards is missing the capitalisation, this is because it just sets the label afterwards to the command, rather than the textual label for it.

The attached patch adds internationalised Enable/Disable text which it switches in/out instead of using the command. It's hard-coded inline with the JS, as that's the format of the current JS and changing it up further probably deserves a rethink of the entire flagging UI and storage.

For the new CampSite theme we had the idea to include a speakers bio page with an improved sessions list not only showing the session title, but also an excerpt as well as links to the slides and WordPress.tv video. We decided against a page template and rather add this additional markup to the post types plugin.

The description for ​Theme Check plugin appears to be parsed incorrectly (see the screenshot).

The first code sample lacks the code formatting. In the readme.txt both samples are formatted the same way:

Examples:
`define( 'TC_PRE', 'Theme Review:[[br]]
- Themes should be reviewed using "define(\'WP_DEBUG\', true);" in wp-config.php[[br]]
- Themes should be reviewed using the test data from the Theme Checklists (TC)
-----
' );`

`define( 'TC_POST', 'Feel free to make use of the contact details below if you have any questions,
comments, or feedback:[[br]]
[[br]]
* Leave a comment on this ticket[[br]]
* Send an email to the Theme Review email list[[br]]
* Use the #wordpress-themes IRC channel on Freenode.' );`

There are a couple problems with our current data set. They're not strictly related to each other, but I'm creating a single ticket for this because I'm guessing that the solution to both will be the same: switch from our current data source to a better one.

• Problem #1: Incorrect IPv4 results. No data source will be perfect, but [several online database had correct results for instances where ours weren't ​https://make.wordpress.org/core/2017/04/14/nearby-wordpress-events/#comment-32448].
• Problem #2: No IPv6 support. Without this, the results will quickly lose effectiveness. As of May 2017, ​IPv6 adoption is at 18% globally and rising relatively fast. Some countries are as high as 32%.

It looks like our database was updated recently (March 2017), but I can't find any info on where the original data comes from. @dd32, @tellyworth, do either of you know? Do you have any thoughts on other potential sources?

Implement programmatic or settings changes that can be made to /plugins/ and /themes/ to allow for individual theme or plugin pages to conform to the SEO Standards. Examples of this format will be:

(1) /themes/

• Title - ? (For example, $Theme_Name, Free $Main_Theme_Category Theme - WordPress)
• H1 - ?
• Meta Description
• ? (of note, we can not do all of the standards, we must start with the most important)

(2) /plugins/

• Title - ? - $Plugin_Name, $Main_Plugin_Category Plugin - WordPress
• H1 - ?
• Meta Description
• ?

More information on this can be found here: ​https://docs.google.com/document/d/13YxtyPNIz8798EpZT-AXh1SW2QNLGm9PBhtDJo7O16o/edit?usp=sharing

The last 8 months or so I have been working on a new WP-CLI ​18n-command that makes it easier for WordPress projects to generate POT files.

Before that, I have been using makepot.php for years, but the tool is not intuitive and really flexible. Also, with JavaScript internationalization (​#wp20491) and Gutenberg being a thing, it was clear that makepot.php wasn't the right tool for the job anymore.

Then there's also issues like #3601 and ​#wp42747 that make it harder for WordPress projects to really use makepot.php. Even for WordPress core I discovered two cases where strings were not extracted at all:

• <strong>ERROR</strong>: "Table Prefix" can only contain numbers, letters, and underscores. (source: wp-admin/setup-config.php:262)
• <strong>ERROR</strong>: "Table Prefix" must not be empty. (source: wp-admin/setup-config.php:258)

The WP-CLI command on the other hand does not have these issues.

That's why I propose switching to this new WP-CLI command for string extraction on WordPress.org infrastructure.

Some of the features:

• Automatically detects plugins and themes and extracts file headers.
• Allows extraction of only a specific text domain.
• Supports JavaScript string extraction, even for JSX and ESNext.
• Allows merging the resulting POT file with an existing one, e.g. one created by Babel.
• Powerful rules to include/exclude specific directories (minified JS files, vendor, .git folder, etc.)
• Supports extracting strings from WordPress core the same way it's done today with 4 different projects. See ​https://github.com/wp-cli/i18n-command/pull/69 for examples.
• Can warn about strings with wrong placeholders, as well as misleading or missing translator comments. This could be very useful for core but also plugin/developers to improve polyglots UX.

Also, the command is extensively tested with Behat (with PHPUnit tests for some parts planned) and is already used in ​third-party projects.

With WP-CLI being an official WordPress project and this new command being superior to makepot.php in many ways, I think we have an opportunity to consolidate lots of things here, reduce the maintenance burden, and to make it easier for people to use WordPress I18N tools and to contribute to them.

It goes without saying that I'd love to help making this a reality, even if it means adding some new features to the command or fixing nasty bugs.

I'd suggest giving this command a go locally with some plugin, theme, or core to get a feeling for it.

Since we built it with WP-CLI 2.0 in mind, which should be released tomorrow, you might need to run the following commands to install it locally:

wp cli update --nightly
wp package install wp-cli/i18n-command

Alternatively, you can check out the ​GitHub repository and run it from within its directory (still requiring WP-CLI 2.0 though).

Copied over from ​#wp12696:

Replying to apeatling:

It would be awesome if you could pass an ordering parameter to plugins_api() that would allow you to return a list of filtered plugins in a specific order.

I'd love to be able to use the API to return a list of the most popular / newest / recently updated plugins on the repo that contain the tag "buddypress".

Something like this would be awesome:

$plugins = plugins_api( 'query_plugins', array( 'tag' => 'buddypress', 'page' => 1, 'order' => 'popular' );

Even better, also allow search filtering:

$plugins = plugins_api( 'query_plugins', array( 'tag' => 'buddypress', 'search' => 'album', 'page' => 1, 'order' => 'popular' );

I'd be happy to implement this if I can get access to the API source on WordPress.org.

Reply from Otto:

This wouldn't be terribly difficult to add to the API, but it's pointless until core supports doing it there and is able to request the ordering. So, moving to the plugins component.

Now that the arguments for plugins_api() have been documented, paired with the fact that there are existing filters in plugins_api() for modifying arguments, I think there's now a more compelling case for implementing an 'orderby' (or similar) argument in the dotorg API.