hook_views_post_render provides inaccurate information

Yeah, 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.

I applied the patch. It worked for me . Screenshot attached

When 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...

Thanks @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 =)

Also, 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?

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.

Related: 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...

Reading 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.

During a views autocomplete, $output not a render array, it's an array of render arrays.

Moving back to task since this still feels like a documentation that needs updating not an actual bug.

Applied patch #24 and it works fine. The output variable is correctly mentioned in documentation after patch.

unrelated Failure.

+++ b/core/modules/views/views.api.php
@@ -844,8 +844,8 @@ function hook_views_pre_render(ViewExecutable $view) {
+ *   A array of renderable array containing the output of the view.

I 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.

Hi,

Creating a patch as suggested in #29 comment.

Please review the patch.

Thanks.

Just 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.

FWIW, 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. 😉

Opened 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.

https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... ok I guess this is considered a bug, my bad :)

Cool, thanks. 😉 in that case, BSI...

Thanks for the review! 2 threads are still open and waiting for review :)

Thanks 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

Thanks for looking again. We're down to 1 unresolved thread, which is looking for review. 😉

Looks good, just one little thing I think we still need to update

Thanks for the review!

Looks good now, thanks.

Committed and pushed acd7ac969e1 to 10.0.x and cce6f01fed2 to 9.4.x and 23fc2b7d9ee to 9.3.x. Thanks!