jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
I really like the custom_field module, and adding support for the 'Map' data type is definitely on the roadmap.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
The double nesting is wrong.
The https://schema.org/additionalProperty was previously ignored.
Check 'Ignored Schema.org properties' via /admin/config/schemadotorg/settings/properties and un-ignore the property
It might be worth it to support https://www.drupal.org/project/physical → first.
jrockowitz → created an issue.
You would need to checkout the MR, copy all config, and delete and recreate the field to see the updates.
The latest dev release includes a bunch of improvements.
Please look at the the MR to see how to start improving https://schema.org/Product support.
Below is example of how I would set hasMeasurement using a custom field.
Note: for weight, I would use https://schema.org/weight
hasMeasurement:
schema_type: QuantitativeValue
schema_properties:
value:
data_type: integer
minValue:
data_type: integer
maxValue:
data_type: integer
unitCode:
data_type: string
unitText:
data_type: textjrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
It is a little incomplete. We will need to think about adding default values and more configuration options for custom fields.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
If you are targeting the https://schema.org/hasMeasurement the custom field settings has to be
# SchemaType--schemaProperty
Product--hasMeasurement:
type: QuantitativeValue
properties:
name: string
value: string
This looks and feels like a nice improvement to the Webform form builder UI. There are a few minor issues that probably need to be fixed via Webform.
For example, the form builder uses Ajax to refresh to table when an element is added or updated. The 'Save' button is fine but the status message is not displaying and fading away.
jrockowitz → created an issue.
jrockowitz → created an issue.
I'm still not mastering all the sides of it!
Neither am I, which is why the module is still in alpha with major changes still happening.
My organization is not currently looking into AI integration. Ideally, a good AI project would look at a page's JSON-LD.
#21 also works for me.
jrockowitz → made their first commit to this issue’s fork.
I am pretty sure that for the local setup, the existing additionalType is a multiple-value field, which is fine but triggered the error.
I am inclined to only support additionalType being a simple string value and ignoring it when it is an array.
I am trying to understand when is the additionalType field an array.
Does the additionalType field on your site support multiple values?
The root cause is the augmentor code is looking only for field_* field name and not configurable fields via str_starts_with($field_name, 'field_')
https://git.drupalcode.org/search?search=%22str_starts_with%28%24field_n...
The code could be updated to look for configurable fields, or someone could write a simple patch to also look for schema_* field names
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue. See original summary → .
jrockowitz → created an issue.
I think you might need to enable the schemadotorg_jsonld.module, which adds the <script type="application/ld+json"> to <head> section of the page.
@see https://git.drupalcode.org/project/schemadotorg/-/blob/1.0.x/modules/sch...
dpagini → credited jrockowitz → .