I think I understand what you're describing, and it is theoretically possible to handle in the hook as you've started, with something like this:
/**
* Implements hook_preprocess_views_view_unformatted().
*/
function mymodule_preprocess_views_view_unformatted(&$variables) {
if (isset($variables['view'])) {
$view = $variables['view'];
// You'll want to check the ID && possibly the current_display so as not to fire on every View!
// In this example, my View is called "test", and I have a page display called "page_1".
if ($view->id() == "test" && $view->current_display == "page_1") {
$result = $view->result;
// You mentioned doing something regarding the user, so you could grab that here.
$current_user = $variables['user']->account;
// The $result will be an array of ResultRow entities.
foreach ($result as $key => $resultRowEntity) {
// Do some customized logic on each row.
// You can access the entire entity here if needed like this:
$row_entity = $resultRowEntity->_entity;
// In my case this is a Node, so can do something to get a term field from it.
// In this example, getting the "some_field" and the first delta of it as a string value.
$some_field_on_the_node = $row_entity->get('field_some_field')->getValue();
// You could do some sort of logic here to determine whether or not to unset this row.
// In this example, I'll say if the field doesn't equal 2, OR the user ID is not equal to 1, unset the row.
// This would remove it from the result.
if ($some_field_on_the_node != "2" || $current_user->uid != 1) {
// You'll want to unset it from 'rows' to not display it.
unset($variables['rows'][$key]);
}
}
}
}
}
I think the takeaway is to use "isset" to avoid those nasty PHP errors, and I highly recommend using XDebug, or at the least the devel
&& kint
modules, so that in your code, you can put things like ksm($variables['view'])
to get some insight into what variables you have available to use. PHP can be very finicky when you try and reference things that don't exist!
Even though this might technically work, it's worth noting that a better approach would be to implement a relationship in Views to bring in the taxonomy term entity being referenced on your node, and that would allow you to add View filters in the UI to massage out the data that way. You could also add a role that could be associated with viewing your particular content type, and this would automatically exclude it from Views results regarding the user if they didn't have this role.
Of course, I may me misunderstanding the complexity of your use case. Another "better practice" approach would be to implement a custom Views filter, which could then be added via the Views UI and maintained separately in a custom module, and would possibly allow for a cleaner implementation - It's somewhat of a broad topic, but I think this is a great intro to the topic: https://www.webomelette.com/creating-custom-views-filter-drupal-8.
I hope this helps point you in the right direction!