[4.1] [RFC] Use schema.org for metadata #25117
Conversation
wilsonge
changed the title
|
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. |
| }) | ||
| ); | ||
| }) | ||
| // TODO: Should we expose the raw email like this? |
There was a problem hiding this comment.
we do in the vcard download
| } | ||
| } | ||
|
|
||
| // TODO: This requires a publisher to pass google structured data checker |
There was a problem hiding this comment.
Looks like it needs an image as well although the error messages are conflicting
There was a problem hiding this comment.
Yeah I saw that - but I'm not sure the best way of achieving this as its mandated for the image to be above 700px width - which clearly may not be the case in an article :/
|
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 |
|
|
||
| // TODO: This requires a publisher to pass google structured data checker | ||
| $schema = Schema::article() | ||
| ->articleBody($this->item->text) |
There was a problem hiding this comment.
Duplicating the entire article text into JSON?
There was a problem hiding this comment.
yup. that's apparently how it should be
There was a problem hiding this comment.
Are you sure about that @wilsonge ? I am looking at some pages from the site of another cms that dont
There was a problem hiding this comment.
If true, I stand by my deleted comment - this is probably unsuitable for content. How does one insert this into article and tie it up to specific pieces of content? With Microdata it's simple by using editor button that inserts the tags around selected content.
There was a problem hiding this comment.
You can paste your entire post in here, and yes it can get really really long
There was a problem hiding this comment.
That looks counter-productive to me. Would not want to bloat up the page like this.
How about the other question? Microdata is not just for automatically generated content. It can be used inside actual content, e.g. inside articles.
|
I think this would be a big step forward:
Just a suggestion to reduce page output: Output only if search bots are indexing the page. Simple |
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 |
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. |
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) |
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 |
Which is why i have |
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. |
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 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. |
I hope there is no doubt about the use of only Json-LD. But Microdata mixed with HTML, no thanks! |
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? |
ghost
added
|
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/ |
rdeutz
changed the title
|
@wilsonge J4.1 ? This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25117. |
| * @package Joomla.Administrator | ||
| * @subpackage com_config | ||
| * | ||
| * @copyright Copyright (C) 2005 - 2019 Open Source Matters, Inc. All rights reserved. |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
|
||
| /** | ||
| * Prepares the document. | ||
| * |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
| * Prepares the document. | ||
| * | ||
| * @param CMSApplicationInterface $app The application object | ||
| * |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
| /** | ||
| * Joomla! Content Management System | ||
| * | ||
| * @copyright Copyright (C) 2005 - 2019 Open Source Matters, Inc. All rights reserved. |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
| /** | ||
| * Event class for representing the application's `onBeforeExecute` event | ||
| * | ||
| * @since 4.0.0 |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
| * | ||
| * @return Schema | ||
| * | ||
| * @since 4.0.0 |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
| * | ||
| * @return mixed | ||
| * | ||
| * @since 4.0.0 |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
| * | ||
| * @return mixed | ||
| * | ||
| * @since 4.0.0 |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
| * | ||
| * @return Schema | ||
| * | ||
| * @since 4.0.0 |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
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. |
|
Always ahead of me :) Obviously feel free to use this as a starting point |
|
We already do |
Why Schema.org
Why JSON Over inline
Why the
Spatie\SchemaOrglibraryWhy remove the microdata library?
Things that need to be done
inLanguageQuestions