Problem/Motivation
Original report:
The documentation at http://api.drupal.org says the following about this function's parameters:
string $output: A flat string with the the rendered output of the view.This is incorrect.
$output
is a nested array of arrays and classes. If there's some string therein that can be manipulated, I haven't found it.
Additional things to consider:
#11:
Seems like this doc comment hasn't been updated since D7, and now I have no idea where to manipulate the rendered output.
#12:
I think more important is indeed to describe here that you should use the usual render API functionality to change the output, like #post_render.
#21:
During a views autocomplete, $output not a render array, it's an array of render arrays
Proposed resolution
1) Update the description of $output
variable;
2) Get rid of legacy documentation that was relevant for D7 version and describe what can be done in this hook;
Remaining tasks
Review and commit.
Comment | File | Size | Author |
---|
Issue fork drupal-2793169
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 2793169-hook-views-post-render-documentation changes, plain diff MR !300
Comments
Comment #2
zalak.addweb CreditAttribution: zalak.addweb commentedComment #3
LendudeYeah, it's probably a render array nowadays. Didn't check though. It's the contents of $this->display_handler->output that's being passed.
Moving to the right queue.
Comment #4
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer and at Appnovation commentedComment #5
lomasr CreditAttribution: lomasr at gai Technologies Pvt Ltd commentedComment #6
lomasr CreditAttribution: lomasr at gai Technologies Pvt Ltd for gai Technologies Pvt Ltd commentedI applied the patch. It worked for me . Screenshot attached
Comment #9
ron-g CreditAttribution: ron-g commentedWhen editing a node it pass $output = '' as an empty string instead of an empty array.
TypeError: Argument 2 passed to hook_views_post_render() must be of the type array, string given...
Comment #10
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer and at Appnovation commentedThanks @lomasr for checking the patch, but just so you know, the test bot already checks that the patch applies cleanly, so no need to do that manually =)
Comment #11
AaronBaumanAlso, perhaps more importantly, this array doesn't actually contain the final renderable output of the view.
e.g. if the view contains a field with "rewrite" enabled, the rewriting has not been done at this point.
And the array doesn't contain the rendered values of fields.
Seems like this doc comment hasn't been updated since D7, and now I have no idea where to manipulate the rendered output.
@Lendude, any particular reason this should not be considered a documentation bug?
Comment #12
dawehnerI think more important is indeed to describe here that you should use the usual render API functionality to change the output, like
#post_render
.Comment #15
quironRelated: the lines before in the same doc coment: https://github.com/drupal/drupal/blob/8.6.x/core/modules/views/views.api... are not properly rendered in api.drupal.org: https://api.drupal.org/api/drupal/core%21modules%21views%21views.api.php...
Comment #16
tea.time CreditAttribution: tea.time commentedReading this incorrect api doc cost me a few hours... :( I was hunting every which way for how to alter the renderable array for the view, wondering why there was no hook provided to do so.
Seeing as now this hook does not operate on the markup string, the
hook_views_post_render()
naming is confusing next to core's#post_render
hooks. But changing the Views hook name, or the point at which it is invoked, would be an api-breaking change. So I'm in favor of the documentation update.As mentioned in #12, this hook can be implemented to add a
#post_render
hook into the render array, and use that to operate on the markup string.Comment #21
simeDuring a views autocomplete, $output not a render array, it's an array of render arrays.
Comment #22
LendudeMoving back to task since this still feels like a documentation that needs updating not an actual bug.
Comment #23
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer and at Appnovation commentedComment #24
anmolgoyal74 CreditAttribution: anmolgoyal74 at OpenSense Labs for DrupalFit commentedComment #25
Abhijith S CreditAttribution: Abhijith S as a volunteer and at Zyxware Technologies commentedApplied patch #24 and it works fine. The output variable is correctly mentioned in documentation after patch.
Comment #26
Abhijith S CreditAttribution: Abhijith S as a volunteer and at Zyxware Technologies commentedComment #28
anmolgoyal74 CreditAttribution: anmolgoyal74 at OpenSense Labs for DrupalFit commentedunrelated Failure.
Comment #29
quietone CreditAttribution: quietone as a volunteer commentedI don't know if this is description is accurate but, if it is, the sentence should be 'An array of renderable arrays containing the output of the view'. Although that has problems too because 'renderable' is in the list of mis-spelled words at core/misc/dictionary.txt.
Comment #30
Pooja Ganjage CreditAttribution: Pooja Ganjage at Asentech LLC commentedHi,
Creating a patch as suggested in #29 comment.
Please review the patch.
Thanks.
Comment #31
Pooja Ganjage CreditAttribution: Pooja Ganjage at Asentech LLC commentedComment #34
MatroskeenJust trying to help to move some Views issues forward :)
At first, the last patch looked very simple and straightforward, so I wanted to give it RTBC. However, after reviewing the comments I think we should expand the scope a little bit.
As for me, the current documentation is no longer relevant (or at least it looks overcomplicated), so I tried to make it simple.
I can also confirm that remark in comment #21 is correct - the structure can be different and depends on the style plugin (see attached screenshots).
(the 2nd screenshot was taken with "Entity Reference" display enabled)
The merge request is looking for a review.
Comment #35
MatroskeenComment #37
dwwFWIW, I still think documentation bugs are bugs. "Make the documentation more clear and helpful" would be task. "Fix lies in the documentation" seems like a bug. But I won't override @Lendude as an official Views subsystem maintainer on this. 😉
Comment #38
dwwOpened some threads in the MR, back to NW.
Saving credits for some of the folks who've materially contributed so far. Haven't fully processed the history, so that task is incomplete.
Comment #39
Lendudehttps://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... ok I guess this is considered a bug, my bad :)
Comment #40
dwwCool, thanks. 😉 in that case, BSI...
Comment #41
MatroskeenThanks for the review! 2 threads are still open and waiting for review :)
Comment #42
dwwThanks for moving this forward (and the Slack ping to remind me to circle back).
Yup, the 2 unresolved threads look good. But I opened 2 more. Sorry and you're welcome. 😉
Cheers,
-Derek
Comment #43
MatroskeenThanks for looking again. We're down to 1 unresolved thread, which is looking for review. 😉
Comment #44
LendudeLooks good, just one little thing I think we still need to update
Comment #45
MatroskeenThanks for the review!
Comment #46
LendudeLooks good now, thanks.
Comment #47
alexpottCommitted and pushed acd7ac969e1 to 10.0.x and cce6f01fed2 to 9.4.x and 23fc2b7d9ee to 9.3.x. Thanks!