The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.There have been a few bugs reported with the "Content item" widget, with regard to the fact that the title field isn't a real reference to a particular node, for example:
#2108821: Problems selecting specific "Content item" when titles are the same or similar
#1971428: add a generic piece of content filter issue
To sum up the problems quickly: it's a title field that has autocomplete. So, if two nodes have the same title, you can't pick one or the other. Or, if the title you want is a subset of another title, it sometimes favors the other, rather than the exact match. Or, if you refer to title, and then later the title is changed, the reference is broken.
It would be great to use a real entity reference field of some kind, rather than a title field!
I haven't dug into this much yet - I'm not sure it's possible with raw Views. I found this project on Drupal.org:
https://www.drupal.org/project/entityreference_filter
But I haven't tested it. We could also probably write a quick Views plugin for our purposes!
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | panopoly_test-content-item-nid-2334439-7.patch | 2.34 KB | dsnopek |
| #7 | panopoly_widgets-content-item-nid-2334439-7.patch | 6.09 KB | dsnopek |
Comments
Comment #1
caschbre commentedJust curious, but why do we we have the "Content item" pane? It seems like the out-of-the-box "Existing node" pane would be better to use. It has a direct reference to the node to display and you can choose which display mode to use. Using the View to display just one item seems odd.
We seem to by trying to hack around the View. Looking at the View you'd want to use a contextual filter instead of an exposed filter. Trying to use the exposed filter on the title is definitely going to lead to issues.
I'd actually argue that it would be better in the long run to change out the "Add content item" with the "Existing node" pane.
Comment #2
dsnopekI don't know the original motivation, but there are a few features the "Content item" widget has that "Existing node" does not:
In any case, at this point we're not going to remove the "Content item" widget, but we could change it's implementation in a backward-compatible way to fix problems.
Comment #3
caschbre commentedYeah, I don't think we should remove the content item widget, but what if we made it a wrapper to the existing node pane?
I'm just wondering if we'll spend more time hacking around making the View work as existing node already does instead of just enhancing existing node (and making our current content item just wrap that).
Comment #4
dsnopekI'd really prefer not to do this. If we change the implementation of "Content item" to be something that isn't a View, we shouldn't be customizing the "Existing node" widget, but creating a totally new widget with a similar implementation.
Many Panopoly users are already using "Existing node" for advanced use cases, but giving general users access to "Content item". If we try to conflate those, then they'll lose their advanced widget, or we'll need to have a way to optionally remove our customizations, and lots of complication will ensue.
But that said, I think the Views-based implementation is fine, and I don't see any reason to switch away from that. Views can take NIDs too! It's just that the current implementation takes a title, rather than a reference. I'd prefer just to fix that bit.
Agreed, but that's totally seperate. I just made a new issue for it: #2334877: Fix live preview with "Existing node" widget
Comment #5
caschbre commentedYeah, I don't mean to suggest that we change the behavior of the "Existing node" widget. That should be left unaltered for it's own use. What I was thinking is we still have a "Content Item" widget that uses existing node as a baseline. The Content Item can add new functionality or hide existing node functionality without altering existing node. This would leave existing node for advanced uses and keep the content item as the more general case... but overall they'll end up fairly consistent.
If we continue with the Views approach, we'll want to add a contextual filter to the View that accepts the NID as opposed to throwing a new module (e.g. entityreference_filter) into the mix. If I remember correctly a contextual argument can be exposed to the panel pane configuration screen, though I'm not sure it's autocomplete out of the box for the nid lookup.
Comment #6
dsnopekAttached is an initial proof-of-concept patch that does this!
I experimented with a bunch of possible approaches:
I ended up going with #2, because it provided the fewest changes to existing functionality. views_autocomplete_filter actually gets us the cool "filter autocomplete by content type" functionality, and Views lets us easily continue to use this for both a "Facebook media item" (ie. image next to title, like you get with "Fields" display type) and node view modes.
These things still need to be done before committing, though:
node_load_multiple()hook_update_N()to get the NID into Pane configuration for widgets that were already placed on existing sitesComment #7
dsnopekAlright! This should be finished, but could use more testing. I'll run on Travis-CI in a moment too.
EDIT: Here's the Travis-CI build: https://travis-ci.org/dsnopek/panopoly/builds/50132238
Comment #8
dsnopekTests on Travis are passing!
Reading through the issue summary, my patch doesn't fix all the problems that I was hoping to fix with this. In particular this one:
But I could definitely imagine a way that the functionality from this patch could be extended to fix that as well! Since this patch already has the big conversion working, I'm going to commit and move solving that to #2108821: Problems selecting specific "Content item" when titles are the same or similar
Committed!