3

We are using Schema.org Metatag module to display meta tag attributes to the Article content type. We have a field that we using as an ImageObject using the field_image field. The field_image is setup so that if an image is not selected, then a default image will be displayed in the twig templates.

We had to add a [node:field_image:large:url] into the url field under ImageObject. When an image is selected, the correct url is added to the page. However, when the image is not selected (a default image should be used), the url field is displaying empty.

How to get the token to display the default value is the image is not added through the node edit process?

Current behavior:

"image" : {
  "@type" : "ImageObject",
   "representativeOfPage": "True",
}

Expected behavior (when image is not selected)

"image": {
  "@type": "ImageObject",
  "representativeOfPage": "True",
  "url": "https://path/to/default-image/large/cloud.jpg",
  "width": "400",
  "height": "260"
},
  • For reference, the bug report: Image URL not using default value – unor Jun 5 '18 at 10:15
  • Hey, I updated my answer and added a working module as proof of concept. – leymannx Jun 12 '18 at 10:47
  • @leymannx the module is a great starting point. If you decide to extend it further as a contributed module, I can try to offer any help I can. – usernameabc Jun 12 '18 at 16:33
1
+50

Seems the default image procedure as it is now doesn't store a file ID or something more useful in that image field. Means the image field doesn't get populated properly.

What I'd try is to create a custom module that adds a config page with a form and a '#type' => 'file_managed'field. The resulting file ID on upload now becomes variable via \Drupal::configFactory()->getEditable()->set() (and together with the right config/install and settings YML files).

Then I'd alter the node form via hook_form_BASE_FORM_ID_alter (see comments) and add a custom validate and/or submit function. Maybe just an element validate callback on the image field. And then check on submit if this field is empty, and if so then retrieve the file ID from the config page via \Drupal::config()->get(), load the file and save it into the image field (maybe the file ID is just enough).

Now the image field should be populated properly and everything else should work as expected.


Proof of Concept

OK I just tried what I wrote above and it's working quite fine. Except I didn't use the node form but hook_entity_presave instead to check if the image field is empty before setting the file ID retrieved from the settings value of the uploaded file on said config page.

  1. Download or clone https://gitlab.com/leymannx/tdi
  2. into /modules/custom.
  3. Enable the module.
  4. Go to /admin/config/media/tdi and upload a default image, save.
  5. Now in your IDE or code editor open /modules/custom/tdi/tdi.module and
    1. update the bundle if ($entity->bundle() == 'XX-YOUR-NODE-TYPE-HERE-XX') {
    2. and the field name $entity->get('field_XX-YOUR-FIELD-NAME-HERE-XX')->setValue([['target_id' => $fid]]);
  6. Save the module file.
  7. Go to a node with an empty image field, edit and resave it, done.

On every node creation or update this module will check if the image field is empty and add a real managed image with a real file ID then. Now the metatag module should work just fine. If updating all nodes manually is too fiddly I'd recommend you let some code do that instead :)

I'm thinking about extending this approach to let admins choose content types and field names this default image should be set automatically. Maybe tomorrow ;)


Alternatively

If this doesn't work or if it's just too messy, the next thing I'd try is to hook into hook_page_attachments_alter same as schema_metatag_page_attachments_alter does to actually attach its values to the HTML head, and try to alter the values there. Which might become messy as well, depending on what methods you have available when you get there or if all you get is just a string to be manipulated quick and dirty.

  • the proof of concept approach worked for me and appears to be quite extendible. I can already see ways on how I can extend it to be per content type and fields as you suggested. – usernameabc Jun 12 '18 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.