To support microdata, field formatters need to add the attributes directly. I will upload a patch that works for the current microdata API.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

FileSize
8.05 KB
Damien Tournoud’s picture

Thanks for this! But which version of this module has you used as the basis of this patch? We don't have any template anymore in the module since the big refactoring that happened back in June.

Anonymous’s picture

oh whoops.... I hadn't updated my code since early June.

I'll have to do a git pull and get it working again. Thanks!

scor’s picture

is there any way we can make the default mappings more generic so that they can not only be used for microdata for also for RDFa and RDF in general?

Anonymous’s picture

That's not so much an issue with AddressField as it is with microdata's hooks. I'd suggest posting it on the MD queue.

scor’s picture

I'm not sure I expressed myself properly. the actual default mappings are good and make sense for the addressfield module. What I was talking about is the hook in which they are defined. what I'd rather see is something like hook_rdf_field_defaults() where these mappings are defined, so that any module interested in these mappings such as microdata and RDFx (RDF UI) can leverage these. but in any case I'll bring up this in the MD queue which is more appropriate to discuss this. thanks for working on this Lin!

Anonymous’s picture

Title: microdata support » Support microdata in addressfield
Status: Active » Needs review
FileSize
10.26 KB

This patch:

  • Enables microdata for the field in hook_field_info and for the properties in the property callback. This results in a microdata configuration form being attached to the field instance settings form.
  • Takes the resultant microdata attributes array that is attached to the entity and in addressfield_field_formatter_view passes it to the format plugins using the context variable.
  • In the format plugins, uses a new helper function (_addressfield_get_attributes) to process the class attributes and microdata attributes into a single attributes array for each property.
    Note: in the original name_oneline formatter, the class name-block was used instead of name-oneline, which makes it the only class that doesn't match the property name. I'm not sure if that was intentional or not. This patch changes it to name-oneline.
  • It also defines a default mapping for schema.org that users can choose to use on the field instance settings page.

In order to test this:

  • Enable microdata module
  • Add an address field
  • On the field instance settings form, click the radio button for schema.org at the bottom of the page and "Use default mapping"
  • Save the field
  • Add a node with an address
  • Copy the source code to http://foolip.org/microdatajs/live/ and click on the JSON tab. You should see a JSON object that has the properties from your content.

The way I insert the microdata into context and then use it in the format plugins might not be the best. Also, open to suggestions for the microdata API if you have any thoughts on how to make it easier for field formatter developers.

Anonymous’s picture

FileSize
10.55 KB

I updated the patch due to #1278200: Add hook_microdata_value_type_alter.

This patch does everything in #8. It also:

  • Sets the microdata type for the 'addressfield' property type to 'item' by implementing hook_microdata_value_type_alter().
klonos’s picture

Using latest dev versions of core, Address Field, Microdata and required modules, when I edit a "Postal address" field (provided by Address Field) I get this error:

Notice: Undefined index: #value_type in microdata_get_instance_mapping_form() (line 174 of /var/www/my-site/sites/all/modules/microdata/microdata.admin.inc).

I have applied the patch in #8

rbayliss’s picture

FileSize
10.85 KB

It looks like hook_microdata_value_type_alter has been renamed to hook_microdata_value_types_alter(). Also, the previous patch doesn't alter the administrative area field. Note that this patch changes the class of this field from state to administrative-area.

Anonymous’s picture

FileSize
10.86 KB

This brings the patch up to date, and I will likely be moving into RC soon.

Any thoughts from the maintainers on how likely a commit is?

gittosj’s picture

Tested and works perfectly - thank you and great work!

pinkonomy’s picture

Does this patch also support schema.org ?

randallknutson’s picture

FileSize
10.89 KB

Updating so it will apply to latest 1.0-beta4

dr.user’s picture

Patch #14 works for me.

johnv’s picture

Issue summary: View changes
Related issues: +#797912: Rich Snippets integration

It seems this pach is now outdated, since the last months some patches/modules have been published:
Schema_org module supports Addressfield
#797912: Rich Snippets integration

bojanz’s picture

@linclark
Given #16, is the patch in this issue still relevant?

Mac_Weber’s picture

Status: Needs review » Closed (won't fix)

@bojanz I think you maintainers could recommend the Schema_org module at the AddressField main page and close both this issue and also:
#797912: Rich Snippets integration

Anonymous’s picture

Status: Closed (won't fix) » Needs review

Here is a patch which applies against the latest dev & successfully adds Microdata support to Addressfield. It validates at https://developers.google.com/structured-data/testing-tool/ . Please review.

This allows those of us who use the Microdata module rather than the Schema.org module to have microdata on our address fields. Reasons to run Microdata include handling of certain Panels issues & a preference for microdata over RDFa 1.0 (used by Schema.org); microdata is the format recommended by Google.

Anonymous’s picture

And here is the patch.

Anonymous’s picture

Disregard the last patch, it had a typo that broke this: $format['locality_block']['#attached']['css'][] = drupal_get_path('module', 'addressfield') . '/addressfield.css';

The version attached here corrects that.

Manuel Garcia’s picture

Status: Needs review » Needs work

Hey, thanks for taking this on! Here is a quick review:

  1. +++ b/addressfield.info
    @@ -8,3 +8,10 @@ dependencies[] = ctools
    +
    +; Information added by Drupal.org packaging script on 2015-04-23
    +version = "7.x-1.0+10-dev"
    +core = "7.x"
    +project = "addressfield"
    +datestamp = "1429817894"
    +
    

    This shouldnt be here... it looks like you built the patch on the dev tarball? Please checkout the repo using git to build the patch.

  2. +++ b/example/addressfield_example.info
    @@ -6,3 +6,10 @@ hidden = TRUE
    +
    +; Information added by Drupal.org packaging script on 2015-04-23
    +version = "7.x-1.0+10-dev"
    +core = "7.x"
    +project = "addressfield"
    +datestamp = "1429817894"
    +
    

    Same as above.

Anonymous’s picture

Status: Needs work » Needs review
FileSize
13.85 KB

Good catch, that is what happened. New patch minus the tarball packaging info. Also one further change: In the Microdata module, hook_microdata_field_defaults was replaced with hook_microdata_suggestions, so this patch makes that change as well (the previous one didn't).

JayShoe’s picture

Hello,

I wanted to post to say that this patch has worked for me. I am using core, Panels, Microdata, and addressfield and have it working and configured to validate through the Structured Data Testing Tool.

I hope this gets committed. It's been 3 months since this patch has been here, and the microdata module looks a little stale as well. I tried both microdata and schemaorg and the microdata/addressfield combination is by far superior. Especially since the schemaorg implementation doesn't support panels.

How I made it work.
I will note that the Use Suggested Microdata Mappings option towards the bottom of the field edit page did not work for me. I'm building a www.schema.org/LocalBusiness with an Address and I had to configure it as the following.

- Address Microdata Mapping>Field property(s) = "address"
- Check off the option to Handle as an item in microdata> Item Type = http://schema.org/PostalAddress
- Then the properties of the address need to be matched accordingly.

I used the http://www.microdatagenerator.com/ tool to create a valid schema.org/LocalBusiness listing and then copied the properties from that.

JayShoe’s picture

I just wanted to update that this configuration works.

- ctools-7.x-1.7+18-dev
- panels-7.x.3.5
- addressfield-7.x-1.1+3-dev + patch #23
- microdata-7.x-1.0-beta2

I was unable to get it to work with ctools-7.x-1.7 (non dev version) and microdata-7.x-1.0-beta2 is the recommended version as of today because they won't go official release until there is enough support. Get this patch committed to move this support along.

daemonchrist’s picture

This is almost, but not quite working. The field edit page now shows boxes to map Country, Administrative area, Locality, etc., but not the boxes for Field property(s), Handle as an item, or Item Type.

jenlampton’s picture

Status: Needs review » Needs work

Looks like @daemonchrist meant to set this to NW.

Summit’s picture

FileSize
130.16 KB

Hi,
I added this patch, thanks!
And it only worked when I changed my own content type to a http://schema.org/Address type. Within the Microdata TAB on /admin/structure/types/manage/[CONTENTTYPE] In my case Weblinks contenttype.

Now on admin/structure/types/manage/[CONTENTTYPE]/fields/field_adresI see the Microdata form arising, Yes.
But what to fill in (It is dutch)? And how to get it validated by Google Structured Data?

Thanks for your reply in advance,
Greetings, Martijn

nonAlgebraic’s picture

Just making patch #23 work on the latest release (7.x-1.2).

Summit’s picture

Hi, trying this patch, and I think it needs something like this added: https://www.drupal.org/files/issues/microdata_non_existent_identifier-24...

While I got all kinds of MD1, MD2 errors like on that issue https://www.drupal.org/project/microdata/issues/2449861

greetings, Martijn