{5} Accepted, Active Tickets by Owner (Full Description) (35 matches)
List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.
DrewAPicture (1 match)
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#1866 | Add a basic "suggest an edit" workflow to the handbooks plugin | Handbooks | enhancement | 07/29/2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Otto42 (5 matches) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#2699 | Add a new role to the forums: plugin/theme support | Support Forums | enhancement | 04/07/2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4123 | Proposal to improve the main navigation menu accessibility | General | defect (bug) | 01/29/2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Several HTML5 sectioning elements automatically create 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
In the wp.org network, some sections don't use Other sections do use navigation landmarks but not for the main menu. For example, the Themes section has two of them: Same in the Plugin section sub-pages: For clarity, these are respectively:
Besides technical details, the most important navigation (the main one) doesn't use a navigation landmark. Wrapping the main menu in a
Note: when in a page there are multiple landmarks of the same type, it's important to use an Suggested:
Optionally:
Note about the wording:
When screen readers encounter a |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4184 | Add a robots.txt disallow all rule to ps.w.org | Version Control | defect (bug) | 02/18/2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Replace the contents of https://ps.w.org/robots.txt with:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4825 | Add Enterprise content to wordpress.org | General | Q1 | enhancement | 11/05/2019 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The Enterprise Growth council has been working on content geared toward enterprise decision-makers as a companion to the content the Growth Council created in 2018. This is essentially a microsite that will live at wordpress.org/enterprise. All the content and designs required for this is here: https://drive.google.com/open?id=1lRpTt88b5bcdbiClPNZwmVP6w1q1QGFJ and here: https://docs.google.com/spreadsheets/d/1uPa6m2hVb4Oz-qOvTEDn2FUC1-uBRVoDvohc7YNmYRY/edit#gid=0 Any additional coordination with the council can take place in #council-ops https://wordpress.slack.com/archives/C9GG77GRJ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#5343 | SVN: Update precommit hooks to block 'compressed' files. | Plugin Directory | enhancement | 07/29/2020 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Pre-commit hooks should block the following prohibited filetypes:
Those are basically the common ones people make mistakes with. It should apply to themes and plugins SVN. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SergeyBiryukov (4 matches) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#2204 | Forum RSS Feed Issues | Support Forums | defect (bug) | 11/03/2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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.
Minor notes:
In short, RSS updates should contain:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#3954 | Support Forums: Add counters to moderation links | Support Forums | enhancement | 11/24/2018 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
@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]. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4695 | Add FAQPage schema markup to plugin pages | Plugin Directory | defect (bug) | 08/20/2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Plugin pages, like https://wordpress.org/plugins/autoptimize/, often contain FAQ content. When this is the case, we should output FAQ schema markup, with an aim to encourage Google to show FAQ questions+answers in the search results (therefore achieving extra visibility and clickthrough-rates). Approach
Example output{ "@context": "https://schema.org", "@type": "FAQPage", "@id": "{{CANONICAL_URL}}", "url": "{{CANONICAL_URL}}", "mainEntity": [{ "@type": "Question", "name": "What does the plugin do to help speed up my site?", "acceptedAnswer": { "@type": "Answer", "text": "It concatenates all scripts and styles, minifies and compresses them, adds expires headers, caches them, and moves styles to the page head, and scripts (optionally) to the footer. It also minifies the HTML code itself, making your page really lightweight." } }, { "@type": "Question", "name": "But I’m on HTTP/2, so I don’t need Autoptimize?", "acceptedAnswer": { "@type": "Answer", "text": "HTTP/2 is a great step forward for sure, reducing the impact of multiple requests from the same server significantly by using the same connection to perform several concurrent requests. That being said, <a href="http://engineering.khanacademy.org/posts/js-packaging-http2.htm">concatenation of CSS/ JS can still make a lot of sense</a>, as described in <a href="https://css-tricks.com/http2-real-world-performance-test-analysis/">this css-tricks.com article</a> and this <a href="http://calendar.perfplanet.com/2015/packaging-for-performance/">blogpost from one of the Ebay engineers</a>. The conclusion; configure, test, reconfigure, retest, tweak and look what works best in your context. Maybe it’s just HTTP/2, maybe it’s HTTP/2 + aggregation and minification, maybe it’s HTTP/2 + minification (which AO can do as well, simply untick the “aggregate JS-files” and/ or “aggregate CSS-files” options). And Autoptimize can do a lot more then “just” optimizing your JS & CSS off course " } }, { "@type": "Question", "name": "Will this work with my blog?", "acceptedAnswer": { "@type": "Answer", "text": "Although Autoptimize comes without any warranties, it will in general work flawlessly if you configure it correctly. See “Troubleshooting” below for info on how to configure in case of problems." } }, {...} ] } Sanitization concerns
All HTML tags should be stripped from fields, with the exception of the
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#6182 | Create a Components page for Meta Trac | Make (Get Involved) / P2 | task (blessed) | 03/11/2022 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Per discussion in the latest Meta team meeting, we would like to create a Components page for Meta Trac, similar to the Core Components page. This should hopefully encourage more component maintainers to step up, and provide more transparency for contributors on who to contact in order to move tickets forward. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
coffee2code (1 match) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#1424 | Automate meta contributor badge assignment when receiving props | Profiles | defect (bug) | 12/01/2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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]). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
dd32 (7 matches) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4487 | Set the codex to readonly | Codex | task (blessed) | 05/31/2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The codex has, for the most part, been migrated to HelpHub and DevHub now, and it's primarily a matter of setting up redirects, and clearing out spam that requires edits on the codex. In light of this, I'm proposing we look at making the Codex readonly to avoid further edits that may fragment the imports already made, and to prevent spam edits. This doesn't need to be done in a week (although that would be nice ;) ), but setting a clear cutoff date seems reasonable and sets expectations. I don't know how old our MediaWiki setup is so I don't know if we have these features, but my thought was:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4555 | Plugin Directory Administration: Mass Email Tool | Plugin Directory | feature request | 06/26/2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
We need an admin-only tool that will allow us to mass-email plugins. One exists but currently can only be run by a server admin, which limits usability. 1) Provide a list of plugins 2) Provide an email subject and body with basic substitutions 3) The tool would then email everyone with commit access and listed owner the message Substitutions needed: %USER_EMAIL% %USER_DISPLAY_NAME% %PLUGIN_URL% With Helpscout you can pre-fill everything BUT the body: https://docs.helpscout.com/article/119-pre-fill So it doesn't look like we can use that for our bulk-mail tool. If it's secure and has the capability to be given a usable UX, whatever tool is used on the back-end should be fine. Limiting the number of plugins mailed at a time is also fine. Handling more than 50 of those at a stretch is usually pretty annoying anyway :) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#5618 | Require ToS/Privacy at login and record acceptance | Login & Authentication | enhancement | 02/12/2021 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
For legal reasons it is necessary that WordPress.org enforces acceptance of a ToS and Privacy Policy at login, and record the date and version of the policy most recently accepted by each user. This means:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#5637 | Email alert to plugin committer when security scanner triggers a change | Plugin Directory | enhancement | 02/25/2021 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The plugin security scanner output is currently only seen by the plugin review team: https://make.wordpress.org/meta/2021/02/19/reducing-the-plugin-review-teams-workload-through-automation/ In order to get feedback on the scan quality, and also to help plugin developers improve their code, we should email an alert to developers when their commit causes a new error in the scan. Scans should be run with warnings suppressed. I'm not sure whether it's better to only include the new warning, or to simply send the entire output - we probably need to experiment with that. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#5668 | Add an 'empty' robots.txt file to s.w.org | General | defect (bug) | 03/19/2021 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
https://s.w.org/robots.txt currently redirects to wordpress.org. For SEO and performance reasons, we should implement a robots.txt file at this location. The contents should be: User-agent: * Disallow: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#5906 | Returns false instead of theme_information often | Theme Directory | defect (bug) | 09/15/2021 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Dear WordPress-Team We have the problem that the API doesn't return the theme information but just a false often. This is the example link: https://api.wordpress.org/themes/info/1.1/?action=theme_information&request[slug]=kadence |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#5934 | Blocking User from Signup Does not Fully Document in profile | General | defect (bug) | 10/21/2021 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
With the new-ish signup tool that allows us to un-spam registrations, it also lets us block users from that interface. However, while it does log who did the action, it doesn't do so in a trackable way. That is, we only get logged "Changed to blocked by X" but none of the reason. Generally the reason is "Bio and/or registration URLs were spammy" but none of that is recorded. What we need is a change to the notice.
Example of a spammy signup: url: http://10040656... from: metro hispania occ: Security guard interests: sex or: url: https://www.facebook.com/Huge-Market-1234566 from: Main Street Those should be copied into the user notes. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
iandunn (1 match) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#5445 | Make the Planet a hub for fantastic WP community content | Planet (planet.wordpress.org) | enhancement | 09/22/2020 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
planet.w.org feeds the news in Core's Right now it subscribes to a lot of early contributors who don't publish often, and some who are no longer active in the project. Most of the remaining sites don't publish often either. The only ones that do are the Tavern and HeroPress, with the Tavern dominating the majority of the items in the feed. What are some ways to solve that? IIRC, changes to the feed need Matt's sign-off. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
netweb (2 matches) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#2537 | Support Forums: Audit Log for Mod Actions | Support Forums | enhancement | 02/27/2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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:
or
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4894 | Add a BP GraphQL API Handbook to developer.buddypress.org | buddypress.org | enhancement | 12/08/2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
As requested by @espellcaste you'll find attached to this ticket the needed edits to the bporg-developer theme to do so that he can start documenting the BP GraphQL API. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ocean90 (2 matches) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4289 | Delete placeholder pages | International Sites (Rosetta) | defect (bug) | 03/15/2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The following legacy pages should be deleted, and 301'd to a sensible location. May also need removing from nav, if this isn't automatic. Likely going to need to do a few passes of these for ones I miss in the initial sweep... Might also be some duplicates. 'Welcome' flavours (should 301 to site root): https://fuc.wordpress.org/txt-welcome/ https://frp.wordpress.org/txt-welcome/ https://kab.wordpress.org/txt-welcome/ https://tg.wordpress.org/txt-welcome/ https://li.wordpress.org/txt-welcome/ https://nl.wordpress.org/txt-welcome/ https://tt.wordpress.org/txt-welcome/ https://la.wordpress.org/txt-welcome/ https://la.wordpress.org/txt-welcome/ https://si.wordpress.org/txt-welcome/ https://am.wordpress.org/txt-welcome/ https://es-cr.wordpress.org/txt-welcome/ https://lin.wordpress.org/txt-welcome/ https://sq.wordpress.org/txt-welcome/ https://es-ar.wordpress.org/txt-welcome/ https://oci.wordpress.org/txt-welcome/ https://br.wordpress.org/txt-welcome/ https://de-ch.wordpress.org/txt-welcome/ https://cn.wordpress.org/txt-welcome/ https://nb.wordpress.org/txt-welcome/ https://bre.wordpress.org/txt-welcome/ https://gd.wordpress.org/txt-welcome/ https://el.wordpress.org/txt-welcome/ https://hr.wordpress.org/txt-welcome/ https://cs.wordpress.org/txt-welcome/ https://es-mx.wordpress.org/txt-welcome/ https://is.wordpress.org/txt-welcome/ https://bg.wordpress.org/txt-welcome/ https://it.wordpress.org/txt-welcome/ https://it.wordpress.org/txt-welcome/logowordcamp/ https://lv.wordpress.org/txt-welcome/ https://bn.wordpress.org/txt-welcome/ https://ms.wordpress.org/txt-welcome/ https://fy.wordpress.org/txt-welcome/ https://uz.wordpress.org/txt-welcome/ https://ug.wordpress.org/txt-welcome/ https://as.wordpress.org/txt-welcome/ https://mr.wordpress.org/txt-welcome/ https://ky.wordpress.org/txt-welcome/ https://dv.wordpress.org/txt-welcome/ 'Install' flavours (should 301 to the local 'download' page if it exists, and the root if not): https://rhg.wordpress.org/txt-install/ https://en-gb.wordpress.org/txt-install/ https://ku.wordpress.org/txt-install-2/ https://fr.wordpress.org/txt-install/ https://da.wordpress.org/txt-install/ https://li.wordpress.org/txt-install/ https://el.wordpress.org/txt-install/ https://eu.wordpress.org/txt-install/ https://srd.wordpress.org/txt-install/ https://so.wordpress.org/txt-install/ https://so.wordpress.org/txt-install/ https://kab.wordpress.org/txt-install/ https://tw.wordpress.org/txt-install/ https://fi.wordpress.org/txt-install/ https://haz.wordpress.org/txt-install/ https://de-ch.wordpress.org/txt-install/ https://os.wordpress.org/txt-install/ https://es-ar.wordpress.org/txt-install/ https://mr.wordpress.org/txt-install/ https://es-mx.wordpress.org/txt-install/ https://es-co.wordpress.org/txt-install/ https://gl.wordpress.org/txt-install/ https://nn.wordpress.org/txt-install/ https://jv.wordpress.org/txt-install/ https://mk.wordpress.org/txt-install/ https://fy.wordpress.org/txt-install/ https://id.wordpress.org/txt-install/ https://ido.wordpress.org/txt-install/ https://ms.wordpress.org/txt-install/ https://sw.wordpress.org/txt-install/ https://ca.wordpress.org/txt-install/ https://kn.wordpress.org/txt-install/ https://azb.wordpress.org/txt-install/ https://sq.wordpress.org/txt-install/ https://tl.wordpress.org/txt-install/ https://zh-hk.wordpress.org/txt-install/ https://es-cr.wordpress.org/txt-install/ https://pl.wordpress.org/txt-install/ https://ko.wordpress.org/txt-install/ https://oci.wordpress.org/txt-install/ https://ky.wordpress.org/txt-install/ https://fa-af.wordpress.org/txt-install/ https://th.wordpress.org/txt-install/ https://bn.wordpress.org/txt-install/ https://as.wordpress.org/txt-install/ https://pan.wordpress.org/txt-install/ https://az-tr.wordpress.org/txt-install/ https://lin.wordpress.org/txt-install/ https://vi.wordpress.org/txt-install/ https://fr-be.wordpress.org/txt-install/ https://ka.wordpress.org/txt-install/ https://xho.wordpress.org/txt-install/ https://hu.wordpress.org/txt-install/ https://fr-ca.wordpress.org/txt-install/ https://is.wordpress.org/txt-install/ https://dzo.wordpress.org/txt-install/ https://sv.wordpress.org/txt-install/ https://ko.wordpress.org/txt-install/ https://sr.wordpress.org/txt-install/ https://co.wordpress.org/txt-install/ https://bre.wordpress.org/txt-install/ https://hr.wordpress.org/txt-install/ https://hr.wordpress.org/txt-install/clean-install/ https://hr.wordpress.org/txt-install/upgrade/ https://gu.wordpress.org/txt-install/ https://km.wordpress.org/txt-install/ https://ar.wordpress.org/txt-install/ https://fa.wordpress.org/txt-install/ https://it.wordpress.org/txt-install/ https://su.wordpress.org/txt-install/ https://tuk.wordpress.org/txt-install/ https://sa.wordpress.org/txt-install/ https://bs.wordpress.org/txt-install/ https://kir.wordpress.org/txt-install/ https://yor.wordpress.org/txt-install/ https://br.wordpress.org/txt-install/ https://nb.wordpress.org/txt-install/ https://tt.wordpress.org/txt-install/ https://ta.wordpress.org/txt-install/ https://uk.wordpress.org/txt-install/ https://snd.wordpress.org/txt-install/ https://arq.wordpress.org/txt-install/ https://tg.wordpress.org/txt-install/ https://twd.wordpress.org/txt-install/ https://eo.wordpress.org/txt-install/ https://ur.wordpress.org/txt-install/ https://hr.wordpress.org/txt-install/clean-install/ https://ug.wordpress.org/txt-install/ https://bcc.wordpress.org/txt-install/ https://khk.wordpress.org/txt-install/ https://ory.wordpress.org/txt-install/ 'Themes' themes https://ml.wordpress.org/Themes/ 'Sample page' variants https://snd.wordpress.org/sample-page/ https://tzm.wordpress.org/sample-page/ https://rup.wordpress.org/sample-page/ https://az-tr.wordpress.org/sample-page/ https://os.wordpress.org/sample-page/ https://lin.wordpress.org/sample-page/ https://twd.wordpress.org/sample-page/ https://fur.wordpress.org/sample-page/ https://sa.wordpress.org/sample-page/ https://pan.wordpress.org/sample-page/ https://la.wordpress.org/sample-page/ https://as.wordpress.org/sample-page/ https://bre.wordpress.org/sample-page/ https://fuc.wordpress.org/sample-page/ https://tt.wordpress.org/sample-page/ https://azb.wordpress.org/sample-page/ 'Releases' variants https://cs.wordpress.org/releases/ 'Contact' variants https://es-pr.wordpress.org/contact/ https://ur.wordpress.org/contact/ https://kal.wordpress.org/contact/ https://eu.wordpress.org/argitaraketak/ https://dzo.wordpress.org/contact/ https://scn.wordpress.org/contact/ https://ps.wordpress.org/contact/ https://es-mx.wordpress.org/contact/ https://km.wordpress.org/contact/ https://tah.wordpress.org/contact/ https://ta.wordpress.org/contact/ https://snd.wordpress.org/contact/ https://kir.wordpress.org/contact/ https://sna.wordpress.org/contact/ https://dv.wordpress.org/contact/ https://rhg.wordpress.org/contact/ https://mlt.wordpress.org/kuntatt/ https://frp.wordpress.org/contact/ https://yor.wordpress.org/contact/ https://arq.wordpress.org/contact/ https://sa.wordpress.org/contact/ https://oci.wordpress.org/contact/ https://ido.wordpress.org/contact/ https://lo.wordpress.org/contact/ https://rup.wordpress.org/contact/ https://la.wordpress.org/contact/ https://fao.wordpress.org/contact/ https://kn.wordpress.org/contact/ https://me.wordpress.org/contact/ https://os.wordpress.org/contact/ https://li.wordpress.org/contact/ https://twd.wordpress.org/contact/ https://es-ar.wordpress.org/contact/ https://as.wordpress.org/contact/ https://ltz.wordpress.org/contact/ https://pan.wordpress.org/contact/ https://mya.wordpress.org/contact/ https://en-gb.wordpress.org/contact/ https://ory.wordpress.org/contact/ https://az.wordpress.org/contact/ https://tg.wordpress.org/contact/ https://te.wordpress.org/contact/ https://mri.wordpress.org/contact/ https://khk.wordpress.org/contact/ https://kin.wordpress.org/contact/ https://tuk.wordpress.org/contact/ https://az-tr.wordpress.org/contact/ https://mk.wordpress.org/contact/ https://ast.wordpress.org/contact/ https://gu.wordpress.org/contact/ https://bre.wordpress.org/contact/ https://am.wordpress.org/contact/ https://mg.wordpress.org/contact/ https://mr.wordpress.org/contact/ https://lin.wordpress.org/contact/ https://hat.wordpress.org/contact/ https://ary.wordpress.org/contact/ https://co.wordpress.org/contact/ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4535 | Delete "Hello World" posts (and tidy up empty blogs) | International Sites (Rosetta) | defect (bug) | 06/26/2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Various Rosetta sites have a blog with a "Hello World" post. These should be deleted. Because of the incorrect hreflang setup on these sites, these posts cause an absolute SEO nightmare as Google seeks out their (non-existent) siblings across the whole network. E.g., https://tg.wordpress.org/2012/08/23/hello-world/ https://tt.wordpress.org/2014/07/08/hello-world/ https://fao.wordpress.org/2016/07/20/hello-world/ https://dzo.wordpress.org/2015/02/24/hello-world/ https://kab.wordpress.org/2015/02/24/hello-world/ https://sa.wordpress.org/2011/07/26/hello-world/ https://hau.wordpress.org/2016/07/15/hello-world/ https://bre.wordpress.org/2015/07/17/hello-world/ https://ak.wordpress.org/2016/03/05/hello-world/ https://es-pr.wordpress.org/2016/03/05/hello-world/ https://rup.wordpress.org/2016/03/05/hello-world/ I don't have an easy way of finding them all from the outside-in - I'm hoping that these should be easy to round up? It's also worth considering that in many cases, these are the only blog posts on these blogs. E.g., https://dzo.wordpress.org/news/, https://bre.wordpress.org/news/ When that's the case and we're removing them, can we also please:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
renyot (1 match) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#6286 | Update the Meta Handbook with useful info | Handbooks | task (blessed) | 04/20/2022 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The Meta Handbook is almost empty and contains little useful info: https://make.wordpress.org/meta/handbook/ It needs to be updated to add some current info about what the team does, how to get started, and where to find things. Let's discuss and collect ideas for what to add in this ticket. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
tellyworth (10 matches) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#815 | Forums to Support Syntax Highlighting | Support Forums | Q1 | enhancement | 01/15/2015 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#1278 | Plugins Install API: Add ability to order results | API | Improved Search | enhancement | 10/01/2015 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copied over from #wp12696: Replying to apeatling:
Reply from Otto:
Now that the arguments for |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#2107 | Prevent posting 10k lines of logs in replies, recommend Pastebin or GitHub gists | Support Forums | Q1 | enhancement | 10/04/2016 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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:
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#2320 | Global stats for GlotPress to identify possible future GTE | Translate Site & Plugins | enhancement | 12/08/2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4253 | Plugins API `query_plugins` produces wrong number of results | Plugin Directory | defect (bug) | 03/09/2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The
So, if you limit the
We are hitting this issue with the WP-CLI |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4478 | Add an `.editorconfig` file to the root of the meta repo | General | enhancement | 05/27/2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Adding the https://core.trac.wordpress.org/browser/trunk/.editorconfig file to the root of the meta repo should help avoid basic coding standards issues when contributing to the meta team.
Using the same |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#5140 | Can the current day on Meetings show upcoming a little better | WordPress.org Site | enhancement | 04/08/2020 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hello, Not sure if the meetings calendar could support it but I find most of the time the first couple early meetings in the day hide the others out there. It would be nice if the current time would change the view so the next few meetings are displayed with all others hidden in the popup link. This might help expose meetings that are about to occur instead of just displaying stale (past) meetings. *This would only apply to the current day. Thoughts? Thanks |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#5322 | Paginated states of topics should append a trailing slash | Support Forums | defect (bug) | 07/21/2020 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Paginated states of topics, like https://wordpress.org/support/topic/can-you-use-gutenberg-blocks-w-o-the-visual-editor/page/2, should forcibly append a trailing slash via a 301 redirect. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#7687 | Cognitive Accessibility Design issue: An email address should be linked using the “mailto” protocol [[mailto]] with prefilled “to”. | General | defect (bug) | 06/29/2024 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
While I am checking privacy page ( https://wordpress.org/about/privacy/ ) of wordpress.org, found that email id does not have mailto, An email address should be linked using the “mailto” protocol mailto? with prefilled “to” and “subject” fields. The absence of a "mailto" link for an email address can indeed pose cognitive accessibility challenges for users. For users with cognitive disabilities, navigating through tasks can be more challenging. A clickable "mailto" link reduces cognitive load by simplifying the process of initiating an email. Manually copying and pasting an email address can introduce errors. Users relying on assistive technologies such as screen readers benefit from clickable "mailto" links because these links are typically recognized and handled appropriately by assistive tools. They provide a direct method for initiating email communication without requiring complex navigation or additional steps Please let me know how can i add the patch for this not getting any repo for this |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#7761 | Add submitted date in Plugin Controls box | Plugin Directory | enhancement | 08/30/2024 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In the Plugin Controls box, we have different values like status, version, updated date, etc. It would be great if we could add there submitted date also. I believe it will be helpful while plugin is being reviewed. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
tobifjellner (1 match) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#7558 | Swahili /support and /team | International Sites (Rosetta) | enhancement | 04/08/2024 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hello. A few days ago at the WordPress Switzerland Community Day we had the opportunity to speak with @lumiblog about the possibility of empowering Swahili in the WordPress community, and we mentioned the forums and P2 for the team, which in Swahili Rosetta are not activated. Would it be possible to activate the /support and /team, to activate the forums and the possibility of energizing the community? There is a lot of mobile knowledge there, and it is possible to get more contributors to the WordPress Mobile team, but they need the tools for it. Furthermore, considering that @lumiblog is getting involved in the local community, I also propose to make him Locale Manager. Ping: @mrfroasty, @ojagero Props: @patricia70 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||