WordPress.org

Making WordPress.org

Opened 2 months ago

Closed 8 weeks ago

#4998 closed defect (fixed)

Improvements to plugin page schema

Reported by: jonoaldersonwp Owned by:
Milestone: Priority: low
Component: Plugin Directory Keywords: seo
Cc:

Description (last modified by SergeyBiryukov)

Plugin pages like https://en-gb.wordpress.org/plugins/wordpress-seo/ include schema.org markup in the form of JSON-LD.

It contains some minor issues, which should be rectified. Specifically:

  • Remove the BreadcrumbList node. This is erroneous in its current format, and will be reintroduced via a future issue.
  • Remove the escaped slashes in the downloadUrl property; e.g., https:\/\/downloads.wordpress.org\/plugin\/wordpress-seo.12.9.1.zip should be https://downloads.wordpress.org/plugin/wordpress-seo.12.9.1.zip.
  • In the AggregateRating property, change the worstRating value to 1.
  • Add a url property, where the value is the canonical URL of the plugin.

Related, #4695

Change History (12)

#1 @SergeyBiryukov
2 months ago

  • Description modified (diff)

#2 follow-up: @dd32
8 weeks ago

I'm fairly certain that the escaped Slashes isn't an issue as it's a JSON literal. But we can pass JSON_UNESCAPED_SLASHES to avoid that happening if 100% absolutely required.. annoyingly it's a JSON blob that's built up using many wp_json_encode()'s so i'd be inclined to leave it as-is.

Rating can technically be 0, which I guess represents an unrated plugin, Just to randomly pick one of the latest plugins as an example: https://en-gb.wordpress.org/plugins/tortoiz-feed/. Shouldn't worstRating therefor be 0?

url

To be clear, that should be added to the "@type": "SoftwareApplication", node correct?
Should it be the global WordPress.org domain or the localised one? I'm assuming the localised one?

For reference, implementation is here: https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/class-template.php?marks=16-128#L16

Edit: Also, https://developers.google.com/structured-data/testing-tool/ seems OK with the syntax at present.

Last edited 8 weeks ago by dd32 (previous) (diff)

#3 in reply to: ↑ 2 ; follow-up: @dufresnesteven
8 weeks ago

Edit: Also, https://developers.google.com/structured-data/testing-tool/ seems OK with the syntax at present.

It isn't okay with the syntax when you run it on the example plugin without reviews (https://en-gb.wordpress.org/plugins/tortoiz-feed/).

Maybe the best route is to move worstRating to 1 (or omit it, which defaults to 1) and conditionally add the aggregateRating prop if reviews are present?

#4 in reply to: ↑ 3 @dd32
8 weeks ago

Replying to dufresnesteven:

It isn't okay with the syntax when you run it on the example plugin without reviews (https://en-gb.wordpress.org/plugins/tortoiz-feed/).

Huh, I must've run it against the same plugin twice..

Maybe the best route is to move worstRating to 1 (or omit it, which defaults to 1) and conditionally add the aggregateRating prop if reviews are present?

That sounds like the best option to me, Drop worstRating and Conditionally add aggregateRating if ratingValue >= 1

Last edited 8 weeks ago by dd32 (previous) (diff)

#5 @jonoaldersonwp
8 weeks ago

  • If un-slashing the url value is a pain, we can live with it for now. Will need to address eventually, but not an urgent problem.
  • Yes, the url should be on the SoftwareApplication piece - and it should indeed reference the 'local' version; sorry for the lack of clarity on that one!
  • We should leave the worstRating value as 1, but omit the aggregateRating piece (which contains the worstRating property) if there are no reviews of the plugin.

#6 @dd32
8 weeks ago

If un-slashing the url value is a pain, we can live with it for now. Will need to address eventually, but not an urgent problem.

Like I said, is there any real reason to? Other than looking prettier? It's valid JSON as it is and parses correctly.

#7 @jonoaldersonwp
8 weeks ago

Yeah, primarily because consistency of values is important.

As we gradually extend the JSON into a full graph, we need to avoid the risk of conflicting or divergent values, otherwise, we're going to send conflicting signals. This is going to get particularly headachey as we start to use proper ID structures (based on URLs), when the URL values then differ from the ID structure.

There are many cases where URL and ID values are used interchangably (e.g., in Google's interpretation of the breadcrumb spec), so we need a standardised approach. We also need to anticipate interoperability with other systems which use/reference nodes by ID or by URL, which means that those values have to be predictable and consistent.

See the example markup here, for example.

#8 @dd32
8 weeks ago

In 9465:

Plugin Directory: Template: Define the Schema in PHP before being output as a JSON literal.

This change also makes the URL escaping consistent by not escaping slashes.

See #4998.

#9 @dd32
8 weeks ago

In 9466:

Plugin Directory: Schema: Set worstRating to 1 in aggregateRating, and skip aggregateRating entirely if there's no reviews.

Props jonoaldersonwp, dufresnesteven.
See #4998.

#10 @dd32
8 weeks ago

In 9467:

Plugin Directory: Schema: Drop the BreadcrumbList node.

Props jonoaldersonwp.
See #4998.

#11 @dd32
8 weeks ago

In 9468:

Plugin Directory: Schema: Add the canonical url for the plugin.

Props jonoaldersonwp.
See #4998.

#12 @dd32
8 weeks ago

  • Resolution set to fixed
  • Status changed from new to closed

Everything listed in this ticket so far is now implemented.

Marking as fixed.

Note: See TracTickets for help on using tickets.