Restructure microdata_item() storage

Problem/Motivation

To have more freedom in changing how and where/when microdata is output on the page. This will give us more leeway in fixing related issues and future changes.

Details:

This module uses 'itemrefs' to refer from an item to its properties, because we can't be sure that all fields are 'inside' the HTML structure of the item itself. That's great; with the itemrefs we have a lot of freedom to move things around.

We could even move an item's microdata attributes in 'their own' HTML structure (e.g. the outer div for a node). This is actively being looked at, now it seems that according to the HTML spec, these attributes are not allowed to be stuck into 'meta' tags anyway.

.....except there's an issue which complicates things:

• Items (e.g. nodes) have 'extra' properties (meta tags with 'itemprop' attributes) output, like 'title' and 'url'
• These extra properties still need to be output in page.tpl.php, because... that's the only place that by default has a $variables['content'] to stick generic output into. Node templates don't have such a place.
• Itemrefs for these properties need to be generated before any node is rendered (because otherwise if theme_node() outputs its own itemrefs... they are incomplete)
• hook_page_process() is too late for this, because nodes which e.g. are part of a view in a sidebar block, are rendered before hook_page_process() runs.

Proposed resolution

Generate 'itemref's for those properties in hook_entity_load(). Stick these itemrefs in microdata_item() with all the other itemrefs (for fields). Also stick the 'extra properties' themselves in microdata_item(), with their 'itemid's, so we can retrieve and render them still on hook_page_process().

Details: the patch:

• moves the processing of 'extra properties' from hook_page_process()to hook_entity_load() (hunk #1 & #3)
• changes microdata_item() so it can hold 'extra properties', and also changes other behavior (see 'API changes') (hunk #5-7)
• changes theme_microdata_item_meta_tags() to match the new output from microdata_item(). (hunk #4) This can now be output in one go. Several things here:
  • While I was changing the code anyway. I output 'span' tags for the items, because 'meta' tags are not OK, as per #1920400: Error: Element meta is missing required attribute content. This could have been split out into a separate issue, but meh... only if someone insists.
  • It's likely that this theme function needs to be rehashed, but IMHO that is better left until a followup issue / after #1920400 and #1947266: Microdata for node are embedded incorrectly are handled.
• A change in microdata_field_attach_view_alter, enforcing behavior that the new microdata_item() wants.

'API changes'

I think these are minor and not a 'real' API anyway, but I'll give an overview:

microdata_item() was changed in the following ways, which have almost no impact on current code:

• there's an extra 4th argument (boolean), TRUE to store 'extra properties'
• the output array is different, in that the sub-array for an [TYPE][ITEMID] used to be a one-element array where the key was always '#attributes'. Now there can be multiple other elements; the keys being the property names and the values again a one-element array with an '#attributes' key.
• a subset of items will be returned if the 1st and/or 2nd function argument are filled but the 3rd argument ($input_attributes) is empty. No existing calls needed to be changed for this, and it may come in handy in the future.
• $input_attributes will overwrite currently stored attributes for this item, except 'itemref', which is the only attribute whose previously stored value is merged into the attributes set in the current function call. This is a 'formalization' of how the current code works in practice, which gets rid of loads of duplicate-stored attribute data that
  • ...I needed to work around somehow :)
  • in practice always needs to be the same; I bet there would cause unexpected problems if the stored attributes for consecutive calls for the same ID were different.
  • needed to be 'array_unique'd on every "get" call -- and I have the feeling that there may be multple calls to this function in the future instead of one (potential time waster)

Remaining tasks

• review code
• review hunk #2; the change in microdata_field_attach_view_alter(), for 'item_reference' fields. I don't fully understand its use. It potentially had multiple 'id' fields and I changed it to re-use an existing 'id' instead of creating a new one, so I could keep checks in microdata_item() less bloated. I haven't tested this code and don't fully get it...
  • this change is OK, right?
  • are we sure this needs to be 'id' and not 'itemid'?