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 <nav> elements are mapped to an ARIA role=navigation. Therefore, <nav> elements are perceived by screen readers and users can jump to them using dedicated keyboard shortcuts.

In the wp.org network, some sections don't use <nav> elements at all. For example, the home page (screenshot from Safari and VoiceOver):

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:

• a <nav> element with a role="navigation": it was common practice to repeat the role even if redundant, to support old browsers assistive technologies
• a <div> element with a role="navigation", which is equivalent to a <nav>

Besides technical details, the most important navigation (the main one) doesn't use a navigation landmark. Wrapping the main menu in a <nav> element would be a good, simple, improvement.

Note: when in a page there are multiple landmarks of the same type, it's important to use an aria-label to help users to distinguish them. This is also what WordPress core and the bundled themes do.

Suggested:

• wrap the existing main menu markup in a <nav aria-label="Main menu">
• where present, add to the secondary navigation an aria-label="Secondary menu" (or any better wording)
• the toolbar already uses an aria-label="Toolbar", no need for any change

Optionally:

• modernize the markup: remove role="navigation" and just use a <nav> element

Note about the wording: When screen readers encounter a <nav> element or a role="navigation", they already announce "navigation": it's recommended to not use this word in the aria-label because it would be announced twice.

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.

Pre-commit hooks should block the following prohibited filetypes:

• .phar
• .zip
• .7z
• .tar.[whatever]
• .rar
• .dmg

Those are basically the common ones people make mistakes with. It should apply to themes and plugins SVN.

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

• Add an additional node to the existing schema markup on plugin pages, for "@type": "FAQPage".

• Add a mainEntity property to house the questions.
  • Loop through each question/answer, and construct a Question node with an acceptedAnswer property.

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 &amp; 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 text property of an acceptedAnswer, which should:

• Accept <a>, <strong> and <em> tags.
• Disallow/remove any values/properties/attributes of these tags (other than the href attribute on <a> tags).
• Remove invalid markup (e.g., an <a> without a closing </a>).

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.

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

​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:

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.

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:

• Set it to readonly
• Use the moderation feature to add users doing migration so they can keep adding redirects and removing the spam that's already there spread within the pages as it's discovered.

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

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:

• Remove the entire blog
• Remove menu links to the (removed) blog
• 301 redirect requests to the blog root URL (e.g., ​https://bre.wordpress.org/news/) to the local site root (e.g., ​https://bre.wordpress.org/)

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.

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

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.

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 .editorconfig from core should not cause any issues with the current meta projects.

​https://editorconfig.org/

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.

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.