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.

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

The RSS feeds generated by the new Plugin Directory platform have a number of drawbacks/defects compared to the feeds that were generated by the old platform.

1. When a new reply is posted to a topic:

• The "forum-level" feed (e.g. ​https://wordpress.org/support/plugin/media-library-assistant/feed) generates a copy of the initial post for the topic, with the initial date/time and author. This is almost useless; you have to go back to the forum to access the text of the update and see who posted it.

• The "topic-level" feed (e.g. ​https://wordpress.org/support/topic/importing-photoshop-iptc-data-into-wordpress/feed ) generates an update with the correct text, date/time and author.

• The email message generated for "subscribers" to the topic also has the correct information, but the message comes as plain-text so markup for code blocks, lists, etc. is lost.

2. When the original post in a topic was modified, the feed generates and ongoing stream of "updates" identical to the original except for the "This topic was modified 2 weeks, 6 days ago by ..." text. This makes it hard to identify topics with genuine updates.

3. When updates are posted to old topics (e.g. started 8 months ago), no RSS feed update is generated. It is hard to know when new activity occurs in an old topic.

Minor notes:

1. The subject line no longer includes the plugin name, which makes it harder to organize an archive by plugin.

2. The subject line no longer includes the post author, which would be fine if the actual author value was set correctly.

3. The subject line now identifies "[Resolved]" topics, but not any other status value.

In short, RSS updates should contain:

• The actual text of the update, with HTML markup
• The actual date/time of the update
• The actual author of the update
• A subject line that includes the plugin name and perhaps the current status in addition to the topic title.

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

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]).

When I try to accept a membership request to the WP-CLI Contributor group, I see a "User not found" error.

​https://profiles.wordpress.org/associations/cli-contributor/admin/membership-requests/

I'm trying to accept @madjax.

Can you help sort this out? Thanks!

Particularly for Trac newbies, "invalid" can feel like a bit of a put-down, even with an explanation of why the ticket is being closed.

Maybe not-a-bug, not-a-core-bug, or something of that nature would be better?

Bikeshedding welcome on this ticket.

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.

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.

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

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

These pages: ​https://profiles.wordpress.org/associations/community-team/ and ​https://profiles.wordpress.org/associations/community-contributor/

don't display any content, they return just a blank page.

checked on Ubuntu desktop Firefox (85.0) browser and android chrome browser. Both the times blank page.

If a user adds an emoji in a "blockified" forum, then this creates some spurious IMG tags. This problem is tracked in ​https://github.com/Automattic/blocks-everywhere/issues/135

However, until that gets solved, we have a situation with unclear communication, as a dependency: It would be good to add a note in the following two strings about this:

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/support-forums/inc/class-ratings-compat.php?marks=365#L365

__( '<strong>Error:</strong> Please <a href="%s">do not add links to your review</a>, keep the review about your experience in text only.', 'wporg-forums' ),

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/support-forums/inc/class-ratings-compat.php?marks=499#L499

__( 'Please <a href="%s">do not add links to your review</a>, keep the review about your experience in text only.', 'wporg-forums' ),

Something along the lines: "In some cases, you may get a false report of this problem if you've been using emojis in your text."

Reported in Slack by abitofmind

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

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

After hovering the mouse over the collapsible element, the mouse icon turns into a cursor. Since the element is clickable and has some information inside, it would be great if the mouse icon turns into a pointer when a reader hovers the mouse over a collapsible element.

Screenshot :

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

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.

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.

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

Now that the WordPress Playground has made it possible to safely test any plugin, we should add a button or link to the Plugin Directory so that users can preview a plugin with a single click.

Clicking the button/link would open a new window with a target URL similar to ​https://playground.wordpress.net/?plugin=hello-dolly (with the plugin's slug of course).

The button/link could go near the existing Download button, or it could even replace it. I'll defer to design feedback on the appearance and UX considerations.

Other decisions and considerations:

• Should it simply open a new tab with the playground preview, or something else (popup?)
• Does it need any logic for selecting the WP/PHP version or can we go with the default?
• Should it be available on all plugins, or selectively (eg only those actively maintained, or supporting a recent WP version?)
• What should the landing page of the preview be? (Perhaps /wp-admin/plugins.php?)

Note that this proposal is for a very simple Playground preview, a MVP. There are many additional ideas that we can discuss and add later.