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.

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.

If you use the search bar on ​https://wordpress.org/support, you will see that it neither includes HelpHub articles nor excludes Codex ones.

I feel that we should well be

1. including HelpHub in it and
2. adding a tab for specific search
3. removing Codex indexing

Also, search bar should say "Search documentation and forums" or something along those lines and not just forums?

Releated discussion in Slack ​https://wordpress.slack.com/archives/C02RP4WU5/p1543850975111100

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

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

When subscribed to a Make blog, the email sent when a post is published has a link called "See all comments", and it has a fragment ID of #comments. But there is no ID in the post named comments, so the link just takes you to the top of the post. The other link, for commenting, is to #respond, which does exist and works fine.

Here is an example from the email ​https://make.wordpress.org/core/2019/04/25/site-health-check-in-5-2/#comments

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",
  "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>).

• Change the <title> content to: {{Full Name}} ({{Username}}) - WordPress user profile | WordPress.org. E.g., Joost de Valk (joostdevalk) - WordPress user profile | WordPress.org.

• Add and populate a meta description tag with the (sanitized) content of the Bio field, up to 160 characters (cutting off gracefully with an ellipses character).

• Add and populate open graph tags as follows:

<meta property="og:type" content="profile" />
<meta property="og:title" content="{{Full Name}} - WordPress user profile" />
<meta property="og:description" content="{{Meta description}}" />
<meta property="og:url" content="{{URL}}" />
<meta property="og:site_name" content="WordPress" />
<meta property="og:image" content="{{Gravatar Large Image}}" />
<meta property="profile:username" content="{{Username}}" />

The following code should be adapted and added to profile templates (values from ​https://profiles.wordpress.org/jonoaldersonwp/ used for reference).

<script type="application/ld+json">
{
    "@context":"https://schema.org",
    "@graph":[
        {
            "@type":"Organization",
            "@id":"https://wordpress.org/#organization",
            "url":"https://wordpress.org/",
            "name":"WordPress",
            "logo":{
                "@type":"ImageObject",
                "@id":"https://wordpress.org/#logo",
                "url":"https://s.w.org/style/images/about/WordPress-logotype-wmark.png"
            },
            "sameAs":[
                "https://www.facebook.com/WordPress/",
                "https://twitter.com/WordPress",
                "https://en.wikipedia.org/wiki/WordPress"
            ]
        },
        {
            "@type":"WebSite",
            "@id":"https://wordpress.org/#website",
            "url":"https://wordpress.org/",
            "name":"WordPress.org",
            "publisher":{
                "@id":"https://wordpress.org/#organization"
            }
        },
        {
            "@type":"ProfilePage",
            "@id":"https://profiles.wordpress.org/jonoaldersonwp/#webpage",
            "url":"https://profiles.wordpress.org/jonoaldersonwp/",
            "inLanguage":"en",
            "name":"{{Page title}}",
            "description":"{{Meta description}}",
            "isPartOf":{
                "@id":"https://wordpress.org/#website"
            }
        },
          {
            "@type":"Person",
            "@id":"https://profiles.wordpress.org/jonoaldersonwp/#profile",
            "name":"Jono Alderson",
            "image":"https://secure.gravatar.com/avatar/beed0f5ca54ae221655b9f30a1f6fe66?s=200&#038;d=mm&#038;r=g",
            "jobTitle":"Special Ops",
            "worksFor": {
             "@type":"Organization",
             "name":"Yoast"
            },
            "sameAs": [
                "https://www.facebook.com/jonathan.alderson",
                "https://www.linkedin.com/in/jonoalderson/",
                "https://twitter.com/jonoalderson"
            ],
            "mainEntityOfPage": { "@id" : "https://profiles.wordpress.org/jonoaldersonwp/#webpage" }
        }
    ]
}
</script>

NOTE: Optional nodes (like worksFor) should only be included when the relevant profile fields are populated.

NOTE: https://meta.trac.wordpress.org/ticket/4277 changes the title and description contents; values here should also change and use the new values specified in #4277.

NOTE: https://meta.trac.wordpress.org/ticket/4278 is required to retrieve/set social profiles in the sameAs array.

NOTE: If name is not set, fall back to username.

The option "None" for Tickets >> Setup >> Predefined Account is unclear - this seems like there would be no payment gateway if that setting is chosen, which makes it unclear how you can access the custom gateway settings.

Changing this label to "Custom Account" or "Local Payment Account" would be clearer.

Hi guy's,

This is the first time I write a ticket here. Do not hesitate to give me advice if it is not the usual way to fill a ticket.

I would like to bring to your attention that there are problems about the layout on the website ​https://central.wordcamp.org/ for Opera users on Android.

Here is an example on this screenshot, but there are probably others :

I posted this info on slack yesterday and @coreymckrill recommended me filling a ticket here.

Regards, Jason

To save time and avoid typos, it would be great to support a means of that prefilling the coupon field.

For example: city.wordcamp.org/tickets?coupon=2017volunteer

Volunteers, sponsors, speakers, organizers, scholarship recipients, and others rely on coupon codes, and this would enable organizers to ensure they get the coupon code right on the first try.

Current page ​https://wordpress.org/themes/upload/ is a mix of content from the admin and page template.

This makes the site non-translatable, which can be a problem as presented here ​https://sv.wordpress.org/themes/upload/

The patch I've created will add all the content in the page template.

Another bug this fixes is the fact that the wporg-themes-upload shortcode echoed the content out instead of returning it, which caused errors on page update from the admin (plus the shortcode was literally present in the admin area).

I'll submit a patch that covers page-upload.php in the wporg-themes theme and upload.php in the theme-directory plugin.

When this will be applied, the content on the page should be removed (aside from the shortcode which should remain).

If a ticket on bbPress or Meta Trac is closed with a particular resolution the resolution cannot be changed without reopening the ticket:

eg: bbPress Trac (Meta is identical):

BuddyPress and Core Tracs can change resolution withot reopening the ticket:

Taking a punt that the following code needs to be added to bbPress and Meta Trac "workflow-*.ini" files. I know bbPress and BuddyPress "workflow-*.ini" files are yet to be open sourced, presuming the same for meta:

Via: https://meta.trac.wordpress.org/browser/sites/trunk/trac.wordpress.org/conf/workflow-core.ini#L64

# Once the ticket is closed
# - reopen
# - change the resolution to something else
...
...

change_resolution = closed -> closed
change_resolution.name = change the resolution, set
change_resolution.operations = set_resolution
change_resolution.permissions = TICKET_EDIT_DESCRIPTION
change_resolution.default = -31

Aside: It wouldn't hurt to add the "mark as duplicate" section also ;)

E.g.,

​http://pingomatic.com/ should redirect to ​https://pingomatic.com/ ​http://pingomatic.com/stats/?cat=dog should redirect to ​https://pingomatic.com/stats/?cat=dog

Hello,

With ui-feedback/ux-feedback now merged as needs-design-feedback it's report name should be updated from Tickets requesting UI or UX feedback to Tickets requesting design feedback.

The link for the page goes here - ​https://core.trac.wordpress.org/tickets/ux-feedback *Am wondering if the URL should also change.

I couldn't find the string in the meta repo but am happy to write a patch if someone can poitn me in the right direction.

Thanks

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

This consumes huge amounts of crawl budget, for relatively little return. We'd like to block crawling of it entirely, via robots.txt.

At the moment, it shares a robots.txt with other wordpress.org domains, which makes this impossible.

Can we give it a dedicated robots.txt file, which is separate from other sites, with the following contents:

User-agent: *
Disallow: /*
Noindex: /*
Allow: /$

NB: We'll need to be absolutely certain that this is a standalone file, and doesn't bleed through to any other WP domains/contexts, or we'll cause the end of the world.

If/when this is complete, the ?filter rule can be removed from the shared/global robots.txt file.

I'm having an design issue with a screenshot of a plugin ​WP Two Factor Authentication with Telegram. I just update the screenshots and captions and saw that the captions stay behind the thumbnails when overflow the 600px limit given to the CSS class .plugin-screenshots .image-gallery-slides, wouldn't it be better if the text pushes down to avoid this defect? Here's the defect:

I changed the value to 650px just for testing purposses and works great:

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/)

Not sure if this is a Meta issue, nevertheless, it could be related to the plugins directory. I was doing a plugin search on plugin-install screen of a 4.7.2 site and got a strange behaviour: the search didn't return all the items available. The number is right – 5 items –, but I can only see 4 items on te screen: ​http://g.recordit.co/yMeHcCzUSY.gif

"Skip links" are one of the most simple and better known ways to improve accessibility for keyboard users and assistive technologies users. They allow to bypass blocks of content that are repeated on multiple pages, typically: navigation menus.

They're implemented since years in WordPress core and the bundled themes. They're also part of the WCAG recommendation:

Success Criterion 2.4.1 Bypass Blocks ​https://www.w3.org/TR/WCAG21/#bypass-blocks

In order to be effective, a skip link used to bypass the top navigation needs to:

• be the first focusable element in a page
• be revealed on focus
• point to the main content in the page

Far from pretending to be a complete analysis of all the .org network pages, I've gone through the main pages linked in the main navigation menus. To recap:

• Home: no skip link
• Showcase: no skip link
• Themes: no skip link
• Plugins: skip link is not the first focusable element
• Mobile: no skip link
• Support: skip link is not the first focusable element
• Get involved (Make): no skip link
• About: skip link is not the first focusable element and it doesn't appear on focus (conflicts with clip-path: inset(50%); inherited by social-icons.css)
• Blog: no skip link
• Hosting: no skip link

I realize the .org network is made of different templates coming from different sources and I guess it's a complicated setup. However, it would be great to make sure the skip to content link is actually present in all pages and works properly.

Hello,

There's no Twitter Card found for ​https://developer.wordpress.org/ on sub-pages.

INFO:  Page fetched successfully
INFO:  6 metatags were found
ERROR: No card found (Card error)

​https://cards-dev.twitter.com/validator

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/

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.