The payload that is sent to the Site Studio API [open] is being replaced with [token.open|_eca_root_token|_eca_root_token]

I'm not familiar with Acquia Site Studio, so when you're talking about "rebuild" and "Base style", is that about css altogether? I wonder why ECA gets involved in that at all. ECA doesn't come with any css at all. However, the modellers do.

Or is this about Acquia Site Studio doing some stuff which calls the token service with some strings from other modules? If the replace function from the token service is being called, ECA gets involved, yes. But I don't see how ECA would replace [open] with [token.open|_eca_root_token|_eca_root_token].

Would like to dig deeper, just don't know how. @mandclu any chance to provide more details?

Maybe we could address this in contrib hours next week at Dev Days?

Actually, just came across 📌 System status report page indicates an ECA token type does not have a token defined Fixed which also mentions _eca_root_token. Not sure if that's related, but I thought it's worth leaving a reference here.

+1 for working on this at Dev Days next week :)

Acquia Site Studio provides a UI to specify markup structures and styles. These in turn get rendered out as twig templates and CSS and JS files. It seems to be during this rendering process that the error is encountered which prevents Site Studio from being able to successfully update the site's styling.

I'm not sure why ECA is at work during this process. I do see that in eca.tokens.inc there is code to define the root token:

  $info['types']['_eca_root_token'] = [
    'name' => t('ECA root-level token'),
    'description' => t('Support for tokens to access data on their root level, for example [list].'),
    'nested' => TRUE,
    'dynamic' => TRUE,
  ];

Based on this, it appears that ECA takes the [open] value to be one of its tokens. I don't see [open] anywhere in the Site Studio codebase, so I suspect it's intended to be a selector. It isn't clear to me that token evaluation should be happening at all there, so it's possible there's a bug in Site Studio as well.

If anyone wants to try out Site Studio on their own, they can request a sandbox or temporary API key on the product page.

This must have to do with tokens, but I can't get the token service to replace [open] with the string above in any way. Leaves me with the assumption that the build process of site studio is scanning the css that contains the [open] substring and therefore finds the token type and then does something with it, for whatever reason. @mandclu do you have a chance to look through the code of site studio to see if and what it does with the token service?

Hiding that token type from the token service on the site of ECA doesn't seem to be possible. So, it seems we have to find a way to handle this in site studio.

I was able to determine that ECA works fine with Site Studio 7.0.x, but with 7.1.x the error is encountered. Unfortunately the Site Studio code for the rebuild command is somewhat scattered across classes and a submodule, so debugging is challenging.

@mandclu as I'm currently triaging the issue queue, I came across this one again and don't feel in a good position to debug site studio. Hope, it's ok to mark this as a task for now.

There may be a potential method in ECA, which decorates the Drupal core token service: \Drupal\eca\Token\TokenDecoratorTrait::generate. We already have some special treatment for other modules, as they sometimes use tokens in an "unexpected way". Maybe you could debug your issue in that method to find out if it alters the token behaviour such that Site Studio breaks? To effectively disable that decoration, you could just remove all of the code in the generate method except the last line, and verify if the problem is then gone away.

The Site Studio team has a patch for Site Studio that should resolve this issue, in case anyone comes else encounters this issue.