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.

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.

Replace the contents of ​https://ps.w.org/robots.txt with:

User-agent: * Disallow: /

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.

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:

• The login form will need to include a checkbox such as [ ] I have read and accept the terms of service and privacy policy with appropriate links.
• Failure to check the box will prevent login.
• Login sessions should remain capped at 2 weeks to ensure all active users regularly accept new terms.
• On successful login, a usermeta or similar value should be set recording the timestamp and version of the ToS and Privacy policy documents (perhaps the currently deployed svn rev# for each?)
• It should probably also record the rev # of the login form and theme, since that may be relevant info.

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.

1. Where was the account spammed/blocked from? This can be "Banned by X via ..."

2. A COPY of the bio and URLs (recommend truncation since some bios are 5000 word porn stories, not kidding). That way it's obvious to everyone else "Oh, yeah, the person with the bio about their casino is probably spam"

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.

#core-build-test-tools has been created in Slack to serve as a home for discussions around our related tooling to bring some of these conversations out of DMs. New tickets, commits, and announce privileges need to be configured.

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.

​planet.w.org feeds the news in Core's Events & News dashboard widget.

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.

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.

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/

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.

The per_page argument for the Plugins API query_plugins action seems to return the wrong number of results in some cases.

So, if you limit the per_page to 20, you only get 19 items back event though that there are more than 20 results available.

We are hitting this issue with the WP-CLI plugin search command, which shows the exact count of elements returned. See ​https://github.com/wp-cli/extension-command/issues/156 for the related issue.

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.

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

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.