Perhaps stating the obvious but surely we cant remove a library without it first being marked as deprecated? Just because we dont use it in core doesnt mean its not being used.

For the publisher part I would add two new fields to Global Config in the Metadata section - publisher name and publisher logo and then in the code you could also have a fallback of ->name($app->get('sitename')) if the name is empty

I think this would be a big step forward:

• as long customization of the ld+JSON output will be fully possible by custom plugins.
  e.g. use case: Use a global fall back image if no image found.
  Use another publisher than found.

• as long ld+JSON output can be deactivated globally or per component(?)
  e.g. use case: Custom plugins that use their own "logic" when, how, what and where to show ld+JSON. And are providing their data since years for search engines.
  And are providing more informations for other systems than search engines.

Just a suggestion to reduce page output: Output only if search bots are indexing the page. Simple
if $app->client->robot
should be sufficient.

Perhaps stating the obvious but surely we cant remove a library without it first being marked as deprecated? Just because we dont use it in core doesnt mean its not being used.

Yup - i'll do a PR to deprecate in 3.10 if we do. In this case given it's very outdated I think it's justified

Perhaps stating the obvious but surely we cant remove a library without it first being marked as deprecated? Just because we dont use it in core doesnt mean its not being used.

Yup - i'll do a PR to deprecate in 3.10 if we do. In this case given it's very outdated I think it's justified

There has already been a conversation elsewhere on the tracker that deprecating in 3.10 is not acceptable because 3.10 and 4.0 are released on the same day so there is no notice

Duplicating the entire article text into JSON?

In the past articleBody (= entire article text; but normally with strip_tags, removed newlines and so on) inside ld+JSON was required by Google but then they removed the required and it's optional now. On the other hand: If a page markup is not perfect and it's not easy to identify the main content articleBody can be helpful. Also for other readers than search engines. But, yes, it can become a overhead.

See my comment concerning customization possibilities via custom plugins.

There has already been a conversation elsewhere on the tracker that deprecating in 3.10 is not acceptable because 3.10 and 4.0 are released on the same day so there is no notice

Short notice deprecations without strong reasoning (i.e. security issues). Something that's outdated, while not ideal, doesn't necessarily mean that's a good candidate for a short notice deprecation. Yes, I'm fully aware there is no documented requirement for number of versions an API element must be deprecated before it can be removed, but this is about ecosystem relations. I get the intentions here and with the PR's from Hannes that I completely tore apart, and I get the argument a lot of people are going to throw around about support overlap and "oh you have 2 years to get your code updated", but I don't think it's very ecosystem friendly to introduce new deprecations in 3.10 for things to be completely removed in 4.0 (and let's be real here, a lot of the ecosystem doesn't keep up with this repo so when the stable release comes around, that will be their first alert about the deprecation).

Thinking about this PR over lunch and realised there is one major issue between this approach and the previous one. Before you could customise the metadata in your template override as it was all in the tmpl/ but now its all in the /View so you can't (at least I dont know how to)

Before you could customise the metadata in your template override as it was all in the tmpl/ but now its all in the /View so you can't (at least I dont know how to)

It needs a plugin event after the Schema object is finished being built and before it gets added to the document. Otherwise trying to manipulate the JSON string attached to the document in something like onAfterDispatch defeats the point of using the underlying library if anyone trying to further customize the schema doesn't even have access to it.

It needs a plugin event after the Schema object is finished being built and before it gets added to the document. Otherwise trying to manipulate the JSON string attached to the document in something like onAfterDispatch defeats the point of using the underlying library if anyone trying to further customize the schema doesn't even have access to it.

Which is why i have Plugin events listed in my todo section :) that's exactly the intention. I also explained why plugin events over template overrides in the Why the Spatie\SchemaOrg library section :)

@wilsonge

I don't think that people are template overriding these things much

That's not true, I had to override it all the times, e.g. to change the item type from article to blog posing for articles which appear in a category blog, or to add the missing "name" property, which Google validator claims to be mandatory.

Although the json-ld VS Microdata is a bit more modern approach to deal with Schema.org, probably from a user perspective with average skills it's much more easy to override them now than having to write a plugin and manage Plugin Events.
So definitely there are pros and cons... maybe more cons?
Maybe a possible solution would be a parameter to switch between Microdata and Json-LD? Or something to have Json-LD easily overridable?

from a user perspective with average skills it's much more easy to override them now than having to write a plugin and manage Plugin Events

The admin UI, and the template files as a result, are already overly convoluted. The "right" way to do it and be the most user friendly practical would be adding all this stuff on metadata tabs on all the content types (articles, contacts, categories, etc.). Otherwise you're putting too many conditionals in a default.php template file to decide if something is an Article or BlogPost or some other "root" type. Even supporting this PHP library's API, to have options for the key bits that need flexibility is adding a lot of fields to the admin UI.

A plugin has the benefit of having access to all of the data needed (well, let's be real here, thanks to the lack of separation of concerns in the Joomla API a template file does too). It has the ability to programmatically make decisions that cannot be configured in the existing com_content UI (or any other core component). There shouldn't be a fear of using plugins for altering the system behavior, that's exactly how an event driven system should work, except Joomla really isn't an event driven system (the events that exist are really crippled IMO and mostly restricted to MVC contexts, very few of the library APIs have event support and that's a major issue). The only "problem" with them is they require you to be good at Joomla's version of PHP, being able to do everything in template files requires you to mostly understand HTML and to a lesser degree have an understanding of Joomla's version of PHP to decipher the over-engineered template file you're trying to edit because there are way too many PHP statements within them.

Although the json-ld VS Microdata is a bit more modern approach to deal with Schema.org, probably from a user perspective with average skills it's much more easy to override them now than having to write a plugin and manage Plugin Events.
So definitely there are pros and cons... maybe more cons?
Maybe a possible solution would be a parameter to switch between Microdata and Json-LD? Or something to have Json-LD easily overridable?

I hope there is no doubt about the use of only Json-LD. But Microdata mixed with HTML, no thanks!
It would be nice to have the opportunity to decide where and how to activate structured data. For example, then will I be able to do a FAQPage? Or will the superimposed "article" microdata prevent me from adding the structured data I want?
At the moment I do well on J3 with the excellent Tassos plugin (Google Structured Data).
The JCE editor also allows the use of structured data, but uses the logic of microdata mixed with html, which is a horrible and disused thing.
But actually I feel the lack of something at the core level ... well done and configurable.
This PR, however, is a turning point !!! Thank you guys!

At the moment I do well on J3 with the excellent Tassos plugin (Google Structured Data).

So definitely would not be better to clean up the HTML code from all mixed Microdata and leave this feature to third-party extensions that fully cover all types of schema.org and configurations?

At the moment I do well on J3 with the excellent Tassos plugin (Google Structured Data).

So definitely would not be better to clean up the HTML code from all mixed Microdata and leave this feature to third-party extensions that fully cover all types of schema.org and configurations?

I cannot comment on this. If I could decide I would add these and many other things to the core. But in this way the developer community would die and the main team should follow every evolution working incessantly only to act on the news ... for example just a few weeks ago Google accepted in the SERP the FAQPage, who should work on the structured Joomla data in that case? The main team or third-party developer?
I really can't answer!

Well, I don't want to vote pro or con. My knowledge on Joomla architecture how it is and how it should be is too little. I only wanted to say that there is at least 1 person doing overrides for modifying the microdata stuff in J3. Would be less comfortable for me having to write a plugin, but if that's the better way, then go for it.

The underlying library (something I'm using on a number of projects) has the benefit of being a fully documented PHP library, and is pretty self-documenting as far as what you can do and where. It's going to add the benefit of having some basic validation in place because it's a collection of PHP classes, whereas the current solution is basically "plug some stuff into a layout, upload it, put it through Google's parser, lather, rinse, repeat". Yes, it's "harder" to be expected to write some PHP code, but in the long run you're getting a standards compliant library that can help guide users over the current solution of hope for the best, and you're opening the door to allow developers to more fluently integrate with this aspect of the page rendering process instead of resorting to the hacks you have to use now because as a plugin developer you can't "force" a template layout file (as one example).

It's this one, right? https://github.com/spatie/schema-org

Reads not bad and looks well maintained.

Correct.

Not important yet! Just a hint because I use the Spaty library in Joomla 3 in a plugin:

$this->document->addScriptDeclaration(json_encode($schema, JDEBUG ? JSON_PRETTY_PRINT : 0), 'application/ld+json');

addScriptDeclaration results in an invalid JSON structure in <script> tag if you output several schemas.

E.g. Organization and Article

<script type="application/ld+json">
{
    "@context": "https:\/\/schema.org",
    "@type": "Organization",
--- AND SO ON ---
}
// ! MISSING COMMA HERE !
{
    "@context": "https:\/\/schema.org",
    "@type": "Article",
--- AND SO ON ---
}
</script>

Was this abandoned? I see J4 is still using microdata instead of JSON-LD

I never got time to do anymore work on it. And likely won't before 4.0 ships - just too many things to work on and my personal life means I have limited time for Joomla right now (I'm buying my first house which needs quite a lot of builders arranged). So yes it's not going to hit 4.0 for sure.

Congrats on the first house @wilsonge!

I guess in the meanwhile we'll have to keep using this :) https://www.tassos.gr/joomla-extensions/google-structured-data-markup/

@wilsonge J4.1 ?
I'dd love to help on this implementation. Looks great!

I don't have the time right now to keep this going. It's a huge change because it needs extra site metadata (per my comments in the main PR description) we don't currently have and without it thing can get worse from an SEO perspective than better - which is obviously a major upgrade issue. @HLeithner / @bembelimen might be one to pick up as a gsoc project for v5.

https://docs.joomla.org/GSoC_2022_Project_Ideas#Project_V:_Schema.org :)

Always ahead of me :) Obviously feel free to use this as a starting point

We already do