DrupalEasy Podcast 143: Scheming (Schema.org integration in D8 - Stéphane Corlosquet)

Stéphane Corlosquet, Sachni Herath, Kevin Oleary, Chris Wells, and Kay VanValkenberg join Mike, Ted, and Ryan for a look into Drupal 8's impressive integration with Schema.org. The RDF UI module is really the star of the show, it promises to provide a super-easy way to create a content type based on an existing schema. We also talk about Dries' 2014 Drupal retrospective, Twig syntax vs. tokens, and Mike's bad internet connection causes hijinx. Picks of the week include a font for demos, a lightweight alternative to a popular Drupal module, and Views changes in D8.


DrupalEasy News

Three Stories


Picks of the Week

Upcoming Events

##Follow us on Twitter

Intro Music

Drupal Way by Marcia Buckingham (acmaintainer) (vocals, bass and mandolin) and Charlie Poplees (guitar). The lyrics by Marcia Buckingham, music by Kate Wolfe.


Subscribe to our podcast on iTunes or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or bandwidth suggestions for Mike. If you'd rather just send us an email, please use our contact page.


My complements on your podcast -- easily my favorite Drupal podcast out there!

I was happy to hear you cover Twig in Views rewrites and wanted to touch on a couple of points you made. As you mention, there are a lot of Views plugin out there. But many times you don't want to enable yet-another-module (or write custom code) just to tweak the output of a field. And it's even worse for non-coders who are limited by the features a given plugin provides.

So you use ViewsPHP to add a wee bit of logic here and there and hope the client doesn't have "admin views" permissions. Similarly with PHP in templates -- while you weren't "supposed" to do anything dangerous, it was easy to shoot your foot by accident or because you didn't know any better. Saying "just limit yourself to loops and conditionals, please" didn't work. That's where Twig comes in -- the sandbox is smaller and safer.

An example use case: you want to display taxonomy terms in a view using plain text if there's just one or an unordered list if there are several. My (admittedly brief) search didn't come up with anything in contrib. With Twig, that's easy as along as we have a token that represents all the terms:

{% if field_tags_multiple|length > 1 %}
{% for item in field_tags_multiple %}
<li>{{ item }}</li>
{% endfor %}
{% elseif field_tags_multiple|length == 1 %}
{{ field_tags_multiple|first }}
{% else %}
There are no tags for this item.
{% endif %}

Someone (Ted?) asked why only in Views? Since this was late in coming (beta was announced while the patch was in flight) it was mostly a matter of scope and I got buy-in from the VDC lead at DC Amsterdam. I would love to see all token replacements in core using Twig instead of our home-grown [token] format. Until that point, we're stuck with two formats. Even in Views it's not consistent -- add an "Unfiltered text" header area and you'll see what I mean -- but it'll be easier to get those changes in now that Twig's foot is in the door.

The concern about code in content and about scattering your display logic in dozens of places are valid. But, since it is display logic, in some respects it belongs with the content. Similar to an href or text in italics, just with loops and conditionals! :) My opinion, it's up to the site builder to use Twig wisely.

There was also a comment about tokens in emails, but I don't remember what was said... Anyhow, I'm going on a bit too long for a comment. Feel free to ping me via my d.o contact form if you have other questions or want to discuss further. And thanks again for your awesome podcast!

Submitted by Guest (not verified) on Fri, 01/30/2015 - 05:07

January 28, 2015