I use the view "Taxonomy term" that emulates the Drupal core's handling of taxonomy/term.
I want to display a term image and a term description for each term of "Brand" vocabulary.
Using "Rendered entity" in Views Header I can specify only an exact Entity ID.

It would be nice if you could put %1 or %2 into Entity ID to get the name or ID from URL (or rather - from contextual filters).
For now I can only use static Entity IDs and get only a single entity in header: http://puu.sh/2r1V1

views header - rendered entity

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Ace Cooper’s picture

Project: Views (for Drupal 7) » Entity API
Issue summary: View changes

spelling

Ace Cooper’s picture

Issue summary: View changes

image size changed

Ace Cooper’s picture

Issue summary: View changes

markup changes

Ace Cooper’s picture

Issue summary: View changes

a little more

Ace Cooper’s picture

Issue summary: View changes

results

Ace Cooper’s picture

Version: 7.x-3.x-dev » 7.x-1.x-dev
Component: Code » Views integration

I looked into the code and found out, that the Rendered Entity option comes from Entity API module.
Moving the topic over there. Found no similar issue yet, will try to come up with a patch myself.

UPD. Made a dirty hack for only my use-case. But it's a start...
In /sites/all/modules/entity/views/handlers/entity_views_handler_area_entity.inc replaced:

return $this->render_entity($this->options['entity_type'], $this->options['entity_id'], $this->options['view_mode']);

with the following code:

$brand_arg = arg(2);
return $this->render_entity($this->options['entity_type'], $brand_arg, $this->options['view_mode']);

It works for me, but a more permanent solutions with %1, %2, etc would be much more useful for everybody.

RogerB’s picture

Very odd that this got overlooked, it seems the most likey thing one would want to do.

Here is a more complete fix. You will then be able to use %0, %1 ... to reference a path argument.

public function render($empty = FALSE) {
  if (!$empty || !empty($this->options['empty'])) {
    if ($this->options['entity_id'][0] == '%') {
      $this->options['entity_id'] = arg((integer)substr($this->options['entity_id'], 1));
    }
    return $this->render_entity($this->options['entity_type'], $this->options['entity_id'], $this->options['view_mode']);
  }
  return '';
}

No it needs to be rolled into a patch.

stBorchert’s picture

Status: Active » Needs review
FileSize
2.41 KB

Attached patch uses the default "render tokens" method of views core to substitute argument tokens in field "Entity id".

legolasbo’s picture

The patch from #3 applied cleanly, works like a charm and the code looks simple and efficient to me. I'd say a perfect fix, but since I don't have much experience reviewing Drupal code I'm reluctant to mark it RBTC.

leex’s picture

Does this patch only allow use of URL arguments? I have contextual filters but no argument and I cannot get it to pull the filter using !1 or %1. I have a contextual filter which gets the UID of the currently logged in user. This patch doesn't help with that.
Edit: The above does seem to work in a normal display but isn't working when generating a views_pdf display. That's a fault of views_pdf module because it doesn't pass the arguments correctly.

It would be great if it worked like 'replacement patterns' when you add a header textarea so you can 'Use replacement tokens from the first row' which includes field tokens and filters.

arx-e’s picture

I came here while searching how I could possibly achieve this functionality.

But from what I see this has not been committed.
I tried to apply the patch in #3 to the latest version 7.x-1.2 but it failed.
After trying and failing to adapt the patch to 7.x-1.2 (I have never done it again), I entered the changes manually and I can confirm it works - at least in one instance and with contextual filters.

I have not tested with tokens but seems to me as significant functionality.

The attached file is my failed attempt at amending the patch.
The error message I kept getting is "Hunk #2 FAILED at 106."

Status: Needs review » Needs work

The last submitted patch, views_area_handler_arguments-1957266-3-for1-2-fails-at-106.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

making things even more clear

mtmaxwell’s picture

Just tried applying the code from #3, no longer seems to work. Would be awfully helpful, any ideas?

arx-e’s picture

Hi, I was able to make it work by manually copy/pasting the patch code in the new entity_views_handler_area_entity.inc file but my attempt at creating a patch was not successful.

I am attaching the file that works for me.
(as in this page http://www.kuwaitbirds.org/birds/conservation-status/near-threatened )

arx-e’s picture

This is the 7.x-1.2 entity_views_handler_area_entity.inc file manually patched with #3.

webel’s picture

Drupal 7.23
Entity API 7.x-1.2
Views 7.x-3.7

I have tried both solutions offered at:

#2 by RogerB

#3 (via #10 manual patch from arx-e)

I can't get any of them to work, as soon as I put any argument in (say %0, %1 for the #2 approach and/or [term:tid] token for #3 approach) I get the following error on previewing a term view:

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /admin/structure/views/view/taxonomy_term/preview/page/ajax
StatusText: Service unavailable (with message)
ResponseText: EntityMalformedException: Missing bundle property on entity of type taxonomy_term. in entity_extract_ids() (line 7693 of .../drupal7/includes/common.inc).
arx-e’s picture

FileSize
70.14 KB

I am using !1 (as you can see in the attachment).

Deciphered’s picture

Status: Needs work » Needs review
FileSize
2.48 KB

Re-rolled patch from #3 as it doesn't apply to current HEAD.

No interdiff for that exact reason.

I did make one change, which is I changed the token format from '!1' to '%1' because that is an existing standard in views and it makes little sense to change it. Happy to reconsider this if there is a valid reason it was used.

webel’s picture

Patch by Deciphered at #13 worked fine against 7.x-1.x-dev 2013-Nov-15, thanks.

I am using %1 ok with a taxonomy term as rendered entity.

However, I can only see the header in the Views UI admin preview, I can't see the header in the view served to other users when using Taxonomy Views Integrator (TVI). It may of course be a separate problem, will investigate more ..

I tried switching themes just in case, header still only appears in Views admin UI preview.

Then tried setting Bypass access checks on, header still only appears in Views admin UI preview.

Maybe should fork as separate issue.

arx-e’s picture

Just reapplied the patch over Entity 7.x-1.5 and it seems OK.
Any chance this getting committed?

diegodf’s picture

Applied patch # 13 and working properly. I hope that in upcoming updates entity module to be added.

phenaproxima’s picture

Status: Needs review » Reviewed & tested by the community

The patch in #13 works well for me too against Entity API 1.5. Marking RTBC.

phenaproxima’s picture

Status: Reviewed & tested by the community » Needs work

Found a little problem with patch #13 -- if you use it with a taxonomy term ID argument that converts term name to term ID, you get an EntityMalformedException because the handler is using the raw argument (term name) as an entity ID.

The problem disappears if I change line 147 of entity_views_handler_area_entity.inc from this:

$tokens['%' . $count] = isset($this->view->args[$count - 1]) ? strip_tags(decode_entities($this->view->args[$count - 1])) : '';

...to this:

$tokens['%' . $count] = $handler->argument;

Not sure if this will break other implementations, but it's worth noting as a potential gotcha.

kopeboy’s picture

I really need this feature.. any chance it will be included in a stable release soon?

What are the other options to create a taxonomy term page showing data from the taxonomy term itself at the top and other content related to the term at the bottom (the core handling isn't good cause of course I want to filter at least by content type..)?

IMHO this is a major issue!

Jelle_S’s picture

Status: Needs work » Needs review
FileSize
2.36 KB
1.35 KB

Added change from #18 & fixed a bug where the argument was optional.

attiks’s picture

Status: Needs review » Reviewed & tested by the community

Great job, thanks

arx-e’s picture

Applied patch in #20 over 7.x-1.5+7-dev and this one works OK for me too (I didn't have any issue with previous patch).

@kopeboy: I have been using this feature (via the above patches) in a production site for more than a year now and I didn't have any problems.

ckaotik’s picture

Status: Reviewed & tested by the community » Needs work

I just ran into an issue with the patch from #20: filter_harmonizer reset the argument filter value to "all" which caused EntityMalformedExceptions. It worked like a charm once I added is_numeric($entity_id) to the render_entity function.

stephesk8s’s picture

Patch in #20 worked for me with 7.x-1.5+7-dev. Thanks!

Anybody’s picture

Status: Needs work » Needs review
FileSize
2.38 KB

I created a new patch based on #20 that only adds the final guess from #23 as condition.

Please review. Works like a charm for me and it would be great to get this RTBC and into dev soon :)

Status: Needs review » Needs work

The last submitted patch, 25: entity_id_token-1957266-25.patch, failed testing.

Anybody’s picture

Patches do not work agains the latest .dev version. This needs work.

Anybody’s picture

Status: Needs work » Needs review
FileSize
2.46 KB

Fixed patch attached. Let's get this RTBC :)
Reviews please!

Status: Needs review » Needs work

The last submitted patch, 28: entity_id_token-1957266-26.patch, failed testing.

scott859’s picture

Patch in #20 worked for me in 7.x-1.5 - thank you.

This feature is something that I really need and would like to see this included in a stable release as well.

bohemier’s picture

Patch #28 gave me a malformed patch error at line 25. Patch #20 works well for me although the comment in #23 should be addressed I think... Thanks everyone

marcoscano’s picture

Patch in #20 worked for me as well, rendering a contextual filter (node) with %1.

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 28: entity_id_token-1957266-26.patch, failed testing.

Anybody’s picture

The patch seems to have a little problem...

Output: [fatal: corrupt patch at line 25].
[05:24:47] Encountered error on [apply], details:
array (
'@filename' => 'entity_id_token-1957266-26.patch',
'@reason' => 'Unable to apply patch. See the log in the details link for more information',
)

Could someone recreate it perhaps? I'm very busy currently and could have a look in a few weeks first.

But based on your positive feedback: Is there an active module maintainer who is willing to apply the (fixed) patch on the dev branch?

awolfey’s picture

Status: Needs work » Needs review
FileSize
2.36 KB

Here's a patch against the latest dev.

Anybody’s picture

+1 for RTBC. Works good for me. Lets have some more feedback!

attiks’s picture

Status: Needs review » Reviewed & tested by the community

Patch is working, we're running it already on a couple of sites, what else needs to be done to get this committed?

martin_klima’s picture

+1 for RTBC. I can confirm the patch #36 works.

arx-e’s picture

+1 for RTBC.
I was working with patch #20 but I re-applied #36 on the latest dev and it still works the same (as it has been for 2 years now).

Honza Pobořil’s picture

Patch #36 works.

ben van den broeck’s picture

#36 also works for me!

fago’s picture

Status: Reviewed & tested by the community » Closed (won't fix)

Interesting approach, but I must say I'm really not fond of re-implementing panels like passing context as part of views. I think the better option is to just use panels for use-cases like that, thus I do not want to promote or maintain this option. -> Won't fix.

But if you want to use it like that it should be simple to add it as part of some small module that extends the class from entity module.

attiks’s picture

#44Adding panels to a site to only accomplish this sounds like overkill, I'm leaving it closed, but would appreciate if you could reconsider this. I know it can be done in a separate module, but it only a couple of lines.

arx-e’s picture

I agree with attiks!
This is a very nice feature and it is already working!
I am currently using it only in one project but it would be a pain to replace if it stops working in one of the next updates.
Plus I am designing a new site where I will probably need the same functionality and I hate the idea of having to add panels for this.

Please, reconsider!

Anybody’s picture

I also agree. The feature is very helpful in many projects! I'd really appreciate to see this in a future release instead of canceling it.

attiks’s picture

Status: Closed (won't fix) » Needs review

Given #46 and #47 marking as NR

arx-e’s picture

Just updated Entity API to version 7.x-1.7 and applied again the patch in #36.
I can confirm it applies without reporting any problems and it works as with the previous version.

Without the patch the relevant pages were broken.

akalam’s picture

Status: Needs review » Reviewed & tested by the community

It works for me too. Let's mark this as RTBC

Hanno’s picture

Worked for me as well.

DuaelFr’s picture

It works like a charm.
+1 RTBC
Thanks

Honza Pobořil’s picture

Works with 7.x-1.7.

attiks’s picture

@fago any change to get this committed?

Rudi Teschner’s picture

I would love to see this patch being included in one of the next releases as well.

I use it to pass fieldable panel panes entity ids via global:null from the pane config to the view to render an independently configurable element as header for a view pane (for example dynamic Title & Subtitle depending on the pane config).

One of the advantages is that it helps me to throw aside a whole bunch of poorly maintainable js modifications made by my project's predecessor to hide fieldable panel panes above empty views.

a.milkovsky’s picture

I also like the approach. I've already used patch from #3 some time ago.
+1 from me.

Anybody’s picture

Please please please commit this. It would safe a lot of time, custom coding and problems in many cases. :)

attiks’s picture

Does anybody knows if this exists for Drupal 8? If so we can stay on par with the features.

Jelle_S’s picture

FileSize
8.36 KB

It does. Import the attached view and go to /views-header-test/[nid]. The node [nid] will be rendered in the header in teaser view mode. Basic D8 site with standard profile.

attiks’s picture

#59 Thanks @Jelle_S

@fago can we add it to D7 as well so both D7 and D8 are similar?

nimek’s picture

patch works great +1 for commit.

arx-e’s picture

Another release goes by without committing this little change and we have to check whether the previous patch still works or how and where to manually paste the code.

It is a very useful feature and it is more than 3 years that it is being used in several sites, why can't it be integrated?

  • fago committed 79d7dbe on 7.x-1.x authored by Anybody
    Issue #1957266 by Anybody, arx-e, Jelle_S, stBorchert, Deciphered,...
fago’s picture

Status: Reviewed & tested by the community » Fixed

It is a very useful feature and it is more than 3 years that it is being used in several sites, why can't it be integrated?

Why do you ask this question, instead of reading my comment on that? ..

@fago can we add it to D7 as well so both D7 and D8 are similar?

ok, that's actually a good reason. Committed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

d70rr3s’s picture

Hi, I see in the patch that you're using query substitutions too, but that is not working, at least I can't get it to work. I'm implementing some query tokens on my own but although debugging shows they are loaded before the handler gets to work in the get_render_tokens() method the views shows no substitutions at all.

attiks’s picture

#66 best to open a new issue and link to it