As far as I understand this issue: #1784580-3: Add a schema:url option to bundles The schema url should point to a unique location of the entity (bundle).
But as jorgeaguero points out there returning relative paths can lead to strange, non unique, paths.
Use url() to ensure the returned path is a proper one. To keep consistent paths even in the case an url alias is changed the flag alias can be set to true to prevent url() from returning the alias.
Attached patch implemets this.
reviews needed.
Clarify if we could use url aliases.
Clarify the impact of url language prefixes (added by url())
none
none
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 1854352-3.png | 29.23 KB | roderik |
| #3 | 1854352-3.patch | 452 bytes | roderik |
| microdata-fix-relative-schema-url.patch | 452 bytes | das-peter |
Comments
Comment #1
eule commentedThanks das-peter for helping on the microdata module!
this is a urgend patch in any seo eyes
works for me!
again thx das-peter
Comment #2
fenstratSo the end result of the patch in #0 is /node/nid vs node/nid, i.e. adding the leading slash. This fixes the relative URL.
As to if url alias' should be used instead, perhaps the schema url could use the token value set for itemid? Using the default [node:url] would result in the alias being used. Because right now having the schema url (i.e. itemprop="url") using the non aliased path and the itemid using the alias path seems like an inconsistency. This could be a follow up issue, but for now this is RTBC.
Comment #3
roderikSince this sitting here anyway, I'd like to not open a 'followup issue', and go into das-peter's request for clarifications here.
1)
As fenstrat says, the default 'itemid' for the object is "[node:url]". This is the aliased URL. So it would make sense for the schema URL to also be the aliased one, IMHO.
It's just 'more canonical' in most cases. (Google uses the Schema URL for its Snippets... and obviously Google usually indexes that page with an aliased URL.)
See screenshot. If not, the 2nd (relative) URL in there would be "/node/NN", and I don't see the sense in that.
About using the the token value set for itemid: I'm not an expert, but The Internet (e.g. html5doctor.com) Suggests That an 'itemid' does not always need to be a URL, as long as it's unique. I don't think in that case the Schema URL should be the same as the itemid.
2)
IMHO, the language prefix added by url(), if any, is exactly what should be added, IMHO:
* The items / fields / etc. of the property displayed on the web page, could be translated into another language, so adding a language prefix would be right.
* The language prefix added by
url()is based on the global$language_url. That's good.===========
As an extra: the return value of
entity_uri()always has an 'options' element, which is meant to be passed to url(). Let's use it. (See https://api.drupal.org/api/drupal/includes%21common.inc/function/entity_... and https://api.drupal.org/api/drupal/modules%21system%21system.api.php/func....)Comment #4
Anonymous (not verified) commentedThanks for your contributions.
The microdata spec says that the itemid must be a URL (by which, they actually mean URI since you can use things like URNs).
However, since your patch still uses a URI, I don't see a problem with the change.
Fixed with http://drupalcode.org/project/microdata.git/commit/f78d7f2