__group__ ticket summary component milestone type created _changetime _description _reporter tellyworth 815 Forums to Support Syntax Highlighting Support Forums Q1 enhancement 2015-01-15T15:05:02Z 2021-02-24T20:27:29Z "Quite often we're sharing code snippets to help our users when providing support. I would love to see the support forums support syntax highlighting. In it's current implementation it's not incredibly helpful to the end user. Here's an example: https://wordpress.org/support/topic/reorder-posts-in-collection?replies=4" nphaskins tellyworth 1278 Plugins Install API: Add ability to order results API Improved Search enhancement 2015-10-01T00:27:16Z 2021-07-28T21:40:21Z "Copied over from #wp12696: Replying to [ticket:12696 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 [#wp34035 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." apeatling coffee2code 1424 Automate meta contributor badge assignment when receiving props Profiles defect (bug) 2015-12-01T19:41:01Z 2017-09-01T16:52:48Z Profile badges don't seem to automatically appear for all areas. My core and plugins badges appeared on my profile on their own (as far as I can tell), but my Speaker badge had to be added manually with some difficulty, and my Meta badge hasn't appeared at all after getting first props a few weeks ago (see [2016]). morganestes DrewAPicture 1866 "Add a basic ""suggest an edit"" workflow to the handbooks plugin" Handbooks enhancement 2016-07-29T15:22:51Z 2020-05-04T16:53:17Z "We've talked about this quite a bit in the context of DevHub where User Contributed Notes are occasionally used as a feedback mechanism. Basically, we need a way for docs consumers to report problems or suggest edits of published documentation on .org. The initial proposal would be to build or use something akin to [https://wordpress.org/plugins/post-forking/ Post Forking] on the front-end of handbooks and eventually other places like DevHub or HelpHub. Personally I don't think an MVP has to be a ''complete'' solution, it mostly needs to cover the rift drawn between moving away from the Codex where any user could edit anything to the now largely closed systems on .org. I think starting with the handbooks would be the way to go." DrewAPicture tellyworth 2107 Prevent posting 10k lines of logs in replies, recommend Pastebin or GitHub gists Support Forums Q1 enhancement 2016-10-04T08:26:25Z 2021-07-16T13:30:00Z "To provide debugging information some users post their full logs in a reply. These can be up to 10k lines which makes reading the page really annoying because you have to scroll like 5 minutes. Examples: * https://wordpress.org/support/topic/qtranslate-x-compatibility-2/#post-8250157 * https://wordpress.org/support/topic/no-confirmation-email-received-2/#post-8235539 I suggest to prevent posting replies which have more than X chars/words/lines and to recommend using a service like Pastebin or GitHub gists." ocean90 SergeyBiryukov 2204 Forum RSS Feed Issues Support Forums defect (bug) 2016-11-03T19:01:18Z 2023-03-29T08:22:12Z "The RSS feeds generated by the new Plugin Directory platform have a number of drawbacks/defects compared to the feeds that were generated by the old platform. 1. When a new reply is posted to a topic: * The ""forum-level"" feed (e.g. https://wordpress.org/support/plugin/media-library-assistant/feed) generates a copy of the initial post for the topic, with the initial date/time and author. This is almost useless; you have to go back to the forum to access the text of the update and see who posted it. * The ""topic-level"" feed (e.g. https://wordpress.org/support/topic/importing-photoshop-iptc-data-into-wordpress/feed ) generates an update with the correct text, date/time and author. * The email message generated for ""subscribers"" to the topic also has the correct information, but the message comes as plain-text so markup for code blocks, lists, etc. is lost. 2. When the original post in a topic was modified, the feed generates and ongoing stream of ""updates"" identical to the original except for the ""This topic was modified 2 weeks, 6 days ago by ..."" text. This makes it hard to identify topics with genuine updates. 3. When updates are posted to old topics (e.g. started 8 months ago), no RSS feed update is generated. It is hard to know when new activity occurs in an old topic. Minor notes: 1. The subject line no longer includes the plugin name, which makes it harder to organize an archive by plugin. 2. The subject line no longer includes the post author, which would be fine if the actual author value was set correctly. 3. The subject line now identifies ""[Resolved]"" topics, but not any other status value. In short, RSS updates should contain: * The actual text of the update, with HTML markup * The actual date/time of the update * The actual author of the update * A subject line that includes the plugin name and perhaps the current status in addition to the topic title. " dglingren tellyworth 2320 Global stats for GlotPress to identify possible future GTE Translate Site & Plugins enhancement 2016-12-08T18:31:29Z 2019-07-02T07:52:43Z "On some locales (like Catalan), most of the translations are done by 3-4 people (with 2 of them being GTE), even if according to https://translate.wordpress.org/locale/ca there are 10 GTE, and almost a 100 contributors. This is a problem not only because it simply doesn't scale (with the amount of strings that themes & plugins have, 3-4 people are not enough), but also because is extremely hard for GTEs to identify ""active"" contributors to help and guide them so they become one day GTE, and for contributors to find active GTE so their strings get approved and don't stay forever as pending. Ideally, there should be a way of ""filtering"" the teams page (https://make.wordpress.org/polyglots/teams/?locale=ca) with some kind of ""active"" filter, with active being a rule such as ""has translated/reviewed more than X strings (could be 0) in the last 3-4 months"". That could help to really asses the health of a team, as you could quickly identify how many people is actively contributing to the project. Also, if that filter included some kind of aggregated cross-project stats (similar to the ones you get ""per-project"" in translate.wp.org), pointing to the projects they contributed, it would be easier to ""measure"" the amount of contributions people is doing: I, as a GTE, am more in validating strings translated by someone who contributes regularly than strings from someone who only translated 1 string two months ago. Computing such a huge amount of stats won't be light in terms of resources, but in order to be useful, these stats don't need to be ""live"": a weekly update would be more than enough to get a sense of the current state. This would also give extra visibility to the health of the team, on top of the ""activeness"" filter: knowing there are 100 people active when 99 of them only have translated one string isn't a sign of healthy at all. " xavivars netweb 2537 Support Forums: Audit Log for Mod Actions Support Forums enhancement 2017-02-27T19:46:42Z 2023-03-01T12:43:50Z "It would be helpful if the forums logged who marked a post resolved (or unresovled) as well as closed etc. From a moderator perspective, this would help track down plugin developers (for example) who automate resolving tickets. It would also mean we'd know who to ping if someone closed a post without a comment. Example: * Marked Resolved by Mika 11 Jan 2017, 22:00 * Marked unresolved by Otto 11 Jan 2017, 22:30 or * Closed by Jan 13 Feb 2017, 11:30 * Opened by Marius 14 Feb 2017, 00:13" Ipstenu Otto42 2699 Add a new role to the forums: plugin/theme support Support Forums enhancement 2017-04-07T14:55:18Z 2023-05-25T14:48:55Z " 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. " TacoVerdo SergeyBiryukov 3954 Support Forums: Add counters to moderation links Support Forums enhancement 2018-11-24T04:23:22Z 2023-03-22T16:20:34Z "@sevlad suggested adding counters to moderation links that require an action, see an example screenshot. For a quick access from any page, it might also be a good idea to add these links under ""My Account"" in admin bar, as a follow-up to [6303]." SergeyBiryukov Otto42 4123 Proposal to improve the main navigation menu accessibility General defect (bug) 2019-01-29T18:14:14Z 2023-06-13T06:25:20Z "Several [https://www.w3.org/TR/wai-aria-practices-1.1/#html5-sectioning-elements HTML5 sectioning elements] automatically create [https://www.w3.org/TR/wai-aria-1.1/#landmark_roles ARIA landmark regions]. Landmark regions are exposed to assistive technologies and allow users to quickly find information in a page. Ideally, all content in a web page should be wrapped within landmark regions. For now, I'd like to propose to focus on the navigation menu. In this specific case it's important to know that `