It'd help to understand what's complete and incomplete if we had a table of all of the schema.org attributes for each object currently supported.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DamienMcKenna created an issue. See original summary.

KarenS’s picture

Thinking out loud. Rather than a manually-maintained table in a documentation page, which will probably be wrong and out of date as soon as it's posted, I'd like to see some sort of self-documentation, where you use the plugin system to discover a list of groups and tags that are provided and spit out a list. That list could be generated by any site that has all the modules enabled and copied or linked to in some way. I'm open to ideas.

ChristophWeber’s picture

I like that idea. It would not need to be a site with all schema_metatag modules enabled, just the code base installed and daily updates via cronjobs running git, composer or drush. Then have a small custom module crawl through the schemas and tags and list what's found. In fact. said site could contain the current stable releases of 8.x-1.x and 7.x-1.x, and HEAD for both from git, and list supported schemas and tags for all of them.

However, documenting what is complete or not is a fool's errand, as schema.org and Google's validator are both moving targets.

DamienMcKenna’s picture

I love it.

If we could add something to crawl schema.org too we could also build a giant todo list of what's left to be done =)

thejimbirch’s picture

I like the idea of automating the list of supported and not-yet-supported schemas.

KarenS’s picture

The source data is available at https://github.com/schemaorg/schemaorg/blob/master/data/releases/3.3/sch.... You can get the attributes for a class at a url like http://schema.org/Person.jsonld.

KarenS’s picture

I have a module (not yet committed) that can retrieve all the Schema.org info. So I've figured that part out.

Trying to identify which of those items is supported is more complicated than you might think. If the modules aren't enabled they won't be discovered. Even if enabled, we have modules that support some of the Schema.org objects but we also have base classes that support objects. Both have objects and properties but they don't look the same, and they're different in D7 and D8. So I see no easy way to identify them.

On top of that I can't decide how to display the results, it will be a gigantic list or a gigantic table that might have to be paged. If I could figure all that out it might be a matter of creating the table in a working site and then copy/pasting it into the documentation, then updating it periodically.

KarenS’s picture

Status: Active » Needs review
FileSize
791.01 KB

Got something working. The Schema Audit module creates a custom page where you can see the table at admin/config/development/schema-metatag.

Status: Needs review » Needs work

The last submitted patch, 8: schema-audit-2937846.patch, failed testing. View results

KarenS’s picture

Status: Needs work » Needs review
FileSize
791.02 KB

Oops, left a typo in that.

  • KarenS committed 873d49b on 8.x-1.x
    Issue #2937846 by KarenS: Build a table of supported objects...
KarenS’s picture

Status: Needs review » Fixed

This includes three clients, once to process Schema.org data, one to process Google's data, and one to process Drupal data. I gave up on the Google one, there is no easy way to collect a list of their requirements. All you can do is scrape their pages and the pages aren't even organized in a consistent way.

I collect Drupal data from the Drupal.org repository, so it will be the same and current no matter what is in your repository and what is enabled. I use DomDocument to navigate the repository pages and pull the data in.

For Schema.org, there are rest endpoints for each object but none that give you a list of all possible objects to start with. Their Github repository has a jsonld download page that has all the data for all objects and properties, so I copied that into the module and I process that file. That file can be replaced periodically to stay current with changes on Schema.org.

This table tells you which objects and properties are created by Drupal 8 modules. There are more if you look at the base classes, but I ignored that for now. I also tried to put in place a way this could be tweaked to get Drupal 7 data, but I didn't try to get that working for now.

Enable Schema Audit (in the Development section), they there is a link to the audit page under config > development.

ChristophWeber’s picture

Nice! I have updated https://www.drupal.org/docs/8/modules/schemaorg-metatag/schemaorg-coverage
I think the report page would have a better home under /admin/reports, but that's just me.

KarenS’s picture

I picked dev to indicate this is something you would only enable on dev, not prod.

KarenS’s picture

Just a note for anyone following this issue, I added in coverage for the base classes as well. I had to hard-code that part but at least the report now reflects all the objects that are covered.

  • KarenS committed c992a15 on 8.x-1.x
    Issue #2937846 by KarenS: Build a table of supported objects...
KarenS’s picture

And now I've added in a comparison for the items that Google wants/uses. It's rough but gets some of that data into the table.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.