Unhandled match case after D10 upgrade

The docs for isDisplayConfigurable on D10 still say:

   * @param string $display_context
   *   The display context. Either 'view' or 'form'.

Can you debug to see what value is getting passed in, and by who?

@Joachim I tried to manually follow through the code but couldn't figure it out. I don't suppose you know a trick I can try?
The other thing I can try is build a dummy site with nothing but Computed Field on it. Maybe that might show something.

Can you put a breakpoint in Drupal\computed_field\Entity\ComputedField->isDisplayConfigurable?

Or failing that, a dsm(debug_backtrace())?

@Joachim I'm working on setting up a debug on my regular site, but I've never had much luck making those work.

I'm also still using:

        "patches": {
            "drupal/core": {
                "computed base fields to work in Views": "https://git.drupalcode.org/project/drupal/-/merge_requests/4224.diff"
            }
        },

I made a exact same setup on an empty D10 site with the same computed field, the exact same fields, the same custom module, patch, and nothing else. It's working perfectly. No errors. I'll keep working on trying to set up a debug on the regular site.

If I just put a simple echo in the function:

  public function isDisplayConfigurable($context) {
echo $context;
    return match ($context) {
      'view' => TRUE,
      'form' => FALSE,
    };
  }

I got "viewviewviewviewviewview".

I have no idea. We need a backtrace to know what called it.

> I got "viewviewviewviewviewview".

If it's only ever called with 'view', then I don't understand how the match() fails.

@joachim To do a backtrace in D10 is it through the Devel, or the knit modules? I don't see it in that. I installed the Devel module but like I said, I never seen to find it showing the info I want. When I go to a book page it's just a white page with the php error at the top.

Just add 'dsm(debug_backtrace())' at the place where it crashses.

> When I go to a book page it's just a white page with the php error at the top.

Yes -- does it show a backtrace? If not, you need to configure the error level.

What's knit BTW?

@joachim I added it and got only this:

ParseError: syntax error, unexpected identifier "view" in Composer\Autoload\{closure}() (line 298 of /var/www/host/website.com/newsite/web/modules/contrib/computed_field/src/Entity/ComputedField.php)

If I comment out the function:

  public function isDisplayConfigurable($context) {
	  dsm(debug_backtrace());
/*	  
    return match ($context) {
     'view' => TRUE,
     'form' => FALSE,
    };
*/
  }

I get a page of array's :

array:34 [▶]

array:42 [▶]

array:39 [▶]

Each array is composed of a lot of sub arrays. Any idea what I'm looking for in there? I wish I could just leave the function commented out because it works fine like that.

> ParseError: syntax error, unexpected identifier "view" in Composer\Autoload\{closure}() (line 298 of /var/www/host/website.com/newsite/web/modules/contrib/computed_field/src/Entity/ComputedField.php)

You must have put it in the wrong place. It can't go inside the match{}.

> Each array is composed of a lot of sub arrays. Any idea what I'm looking for in there?

You need to read through the array. Each item is a step up the chain of calls that got us here. We need to know who called this with a crappy parameter.

@joachim >You need to read through the array. Each item is a step up the chain of calls that got us here. We need to know who called this with a crappy parameter.

Can you give me a hint what to look for? There are A LOT of arrays!

Ok so that call is ok:

    "args" => array:1 [▼
      0 => "view"
    ]

You need to check the final array before the crash.

@joachim I'm sorry for being inexperienced in this, but would that logically be at the bottom of the long list? There is around 300 of the arrays with more sub arrays.

I found one that the 'view' is missing from the end

  0 => array:7 [▼
    "file" => "/var/www/vhosts/theliterarytimes.com/newsite/web/modules/contrib/field_permissions/field_permissions.module"
    "line" => 36
    "function" => "isDisplayConfigurable"
    "class" => "Drupal\computed_field\Entity\ComputedField"
    "object" => Drupal\computed_field\Entity\ComputedField {#2240 ▼
      #entityTypeId: "computed_field"
      #enforceIsNew: null
      #typedData: null
      #cacheContexts: []
      #cacheTags: []
      #cacheMaxAge: -1
      #_serviceIds: []
      #_entityStorages: []
      #originalId: "node.book_page.computed_buy_amazon"
      #status: true
      #uuid: "794b4003-cd4a-4202-aca5-af1f2588ba57"
      -isUninstalling: false
      #langcode: "en"
      #third_party_settings: []
      #_core: []
      #trustedData: false
      #dependencies: array:2 [▶]
      #isSyncing: false
      #id: "node.book_page.computed_buy_amazon"
      #field_name: "computed_buy_amazon"
      #field_type: null
      #entity_type: "node"
      #bundle: "book_page"
      #label: "Buy Amazon"
      #description: ""
      #settings: []
      #required: false
      #translatable: true
      #default_value: []
      #default_value_callback: ""
      #fieldStorage: null
      #itemDefinition: null
      #constraints: []
      #propertyConstraints: []
      #plugin_id: "buy_amazon_computedbuyamazon"
      #plugin_config: []
      #pluginCollection: Drupal\Core\Plugin\DefaultSingleLazyPluginCollection {#3238 ▼
        #pluginInstances: array:1 [ …1]
        #instanceIds: array:1 [ …1]
        #manager: Drupal\computed_field\ComputedFieldManager {#3243 …16}
        #configuration: []
        #instanceId: "buy_amazon_computedbuyamazon"
        #_serviceIds: []
        #_entityStorages: []
      }
    }
    "type" => "->"
    "args" => array:1 [▼
      0 => "display"
    ]
  ]

Ok so this is a bad value:

    "args" => array:1 [▼
      0 => "display"
    ]

And the bug looks like it's in field_permissions.module. The backtrace tells you the line. Look in there to see what the problem is.

@joachim I posted over in the Field Permissions issues. I can't find where this could be killing it, but it does look like something here doesn't like field permissions. Line #36 in field_permissions.module is:

31  /**
32   * Implements hook_entity_field_access().
33   */
34  function field_permissions_entity_field_access($operation, FieldDefinitionInterface $field_definition, $account, FieldItemListInterface $items = NULL) {
35    $context = ($operation == 'view') ? 'display' : 'edit';
36    if (!$field_definition->isDisplayConfigurable($context) || empty($items)) {
37      return AccessResult::neutral();
38    }
39    $access_field = \Drupal::service('field_permissions.permissions_service')->getFieldAccess($operation, $items, $account, $field_definition);
40  if (!$access_field) {
41      return AccessResult::forbidden();
42    }
43    return AccessResult::neutral();
44  }

This is the bug:

35    $context = ($operation == 'view') ? 'display' : 'edit';
36    if (!$field_definition->isDisplayConfigurable($context) || empty($items)) {

Both these values assigned to $context are wrong! The docs say:

> * The display context. Either 'view' or 'form'.

Great. So this means it's a bug at Field Permissions?

Yeah, because they only fixed half of it.

Unfortunately that was the only issue that sounds like the problem. I posted there but I have no idea how fast they respond. I wish I could do without the module but I kind of need it.

That issue IS the problem but it wasn't fixed properly.

@joachim I installed the DEV version of Field Permissions and Computed Field, and everything else, works with no errors.

Ok so is this issue fixed? Can you close it if that's the case?

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