Even though Drupal 7 core fell short of a proper way of handling its brand new entity system (we currently rely on the great Entity module for that), it did give us EntityFieldQuery. For those of you who don’t know, EntityFieldQuery is a very powerful querying class used to search Drupal entities programatically (nodes, users, etc).
It provides a number of methods that make it easy to query entities based on conditions such as field values or class properties. If you don’t know how it works, feel free to check out this documentation page or this great tutorial on the subject.
In this article I am going to talk about what we have in Drupal 8 for querying entities. There is no more EntityFieldQuery, but there’s an entity.query service that will instantiate a query object for a given entity type (and that implements the \Drupal\Core\Entity\Query\QueryInterface). We can access this service statically through the \Drupal namespace or using dependency injection.
First up, we’ll look at querying node entities and then we’ll see how to load them. The same techniques will work with other content entities as well (users, comments etc), but also with configuration entities, and that’s really cool.The entity query service
As mentioned, there are two ways we can access the entity.query service that we use for querying entities. Statically, we can do this:
Continue reading %The Drupal 8 version of EntityFieldQuery%
Here’s a little history I pieced together about, Drupal, the Views module and the human condition.
It must have been 4 years or so ago that the new Field API for D7 crystallises, requiring modifications to Views. So someone adds lines of code to make this happen. They don’t think much about those lines or the performance impact these may have. They don’t put a “hook” in to allow developers to alter the behaviour of those lines. Why would they? It’s a pretty trivial change. In fact it never crosses their minds to add the CPU cycles spent by that code to the view's performance stats.
4 years go by.
Nobody is aware that if you piled up the seconds collectively wasted in that code across all Drupal sites using Views over a period of 4 years, it would amount to like,…. like higher than the Eiffel tower. So to speak…
Until a couple of weeks ago some RdeBoer employs XHProf to find out why a client’s site is a little sluggish. And he finds those lines of code. And although there’s no hook as such to bypass those lines, he finds a way without hacking the Views module to neutralise those lines, offering a simple switch on the UI. Like a Turbo button, it makes selected Views run faster.
The customer is delighted. Now their site is finally speedy enough to go live! Another client quotes the results as “amazing”.
Encouraged by the happy customers RdeBoer tarts up his module to share it with the Drupal community. Now everyone can enjoy similar speed improvements. He writes a little blog post about it.
In a comment to that post @merlinofchaos confirms that those lines were indeed added with the introduction of the Field API. And that not showing how much time is spent in those lines is an oversight.
RdeBoer smiles. Takes a sip of his wine. 4 years... Isn’t life funny?
@merlinofchase goes back to the garden and throws another shrimp on the barbie. Metaphorically speaking. Might have been chicken. Have you seen Earl’s chicken? The photo above that’s his chicken. He cooked that last week. I would love a bit of that chicken. With its juices dripped over the veggies. Yummo!
Meanwhile @someViewsDude has a not-so-constructive go via Twitter, email and the module’s issue queue ...
My friend and colleague Susan concludes her writings with a beautiful phrase: “Breathe and do the next right thing”.
Maybe we can all sit around Earl's barbie. Try his chicken. It looks delish.