Inline Formatter Field related feature and filter processing order

After doing some investigation, I see the issue is located in mustache_templates/modules/mustache_token/src/MustacheTokenDecoratorTrait.php render method. The decorator is replacing the core token service because there is either mustache syntax or twig syntax, which could match the mustache syntax. The Mustache Logic-less Tokens module tokens replacement seems to strip away any twig because of similar syntax and also changes some of the global tokens. I am not sure if there is something that this module can do outside of the Mustache module and its sub modules.

I think what would work best is if the Mustache module added an option into their token replace function call which would prevent stripping twig syntax and switching global tokens. As far as I know, this option does not exist now. This issue looks like it could be related:
https://www.drupal.org/project/mustache_templates/issues/3282935 →

My best suggestion at the moment would be to avoid using the Mustache module when also using global tokens and twig as there seems to be incompatibilities with their syntaxes.

Hello,

I believe I have found a good work around for this issue. The process order will first process the mustache first since it is involved in the token replacement. Because of this you can change the delimiter of the mustache first using https://mustache.github.io/mustache.5.html#Set-Delimiter. This will allow you to keep the `{{` and `}}` for the twig only.
For example:

{{=<% %>=}}
<p>With twig: {{ title }}</p>

[site:name]
<p>With mustache: <% site.name %></p>
<hr>

Hello,

This is a good solution, So, I can be installed this module(Mustache Logic-less Tokens) in inline_formatter_field to use {{=<% %>=}} at the beginning, and use twig at the below.

Three modules do well (view field, view mode, and the entity field) to use token and twig in inline_formatter_field, But I think it should also include a important sub module (inline_formatter_block) to use token and twig for block, use twig conditions ({%if %}) on different pages, output different content,(like Main page content of system block, just a block to output different data for different content types)

It should also have a custom variant concept to use for twig, Like this module ( snippet_manager → )

I still have some advices about the module, but my English is not good, difficult to describe.

If possible, consider how to build a convenient extension feature like building blocks, a configuration page? or in each inline_formatter editor additional configuration options, wow ideal some far. :)

But now, the main is filter processing order and inline_formatter_block.

Thank you!

I think filter processing order should be attached to each inline_formatter editor, Use different processing order for each editor, provide a configuration page, set the default filter processing order, then user can custom filter processing order on the basis of the default Settings in each editor.

Hello again! Sorry, for the long time between responses.

I am still not sure about your request for filter processing order as this module does not doing anything outside of the core twig processing. Unless you count the token replacements, which needs to be done before the normal twig processing. I am not sure of what other options there would be. A lot of things can be done within the twig itself, and even more can be done with the Twig Tweak module → .

For the block feature request, I believe what you are asking for can be achieved by using a combination of the core Custom Block (block_content) module and the Inline Formatter Display module. You can create a custom block type and check the "Use Inline Formatter Display" checkbox on the manage display form. Edit the HTML/Twig as you wish and save. Now you should be able to create a custom block using the block type you created and place the block in the layout or reference it as with any other block.

Hello,

Yes, for the block feature request, there are many alternatives, you said that the scheme is feasible, but, I think, in the block layout using a text editor will be more convenient and flexible, I prefer to use text editor, I now use text_block and twig → filter to implement this feature, by the token and the twig loading data, if inline_formatter_block can do, I will not install twig this module.

About the filter processing order, it is really important.
I want to get the entity data of current page in many cases, I use this module bamboo_twig → to load the entity data.

{% set node = bamboo_load_entity('node', '[node:nid]') %} >> I don't know Twig Tweak whether can do this, it only rendering entity, no loading entity.
then {{ node.title.value }} to print data.

If there is no filter processing order, the above syntax doesn't work, I also tried through bamboo_token() method, and doesn't work, it seems to be processing twig first, and then execute the token.

In addition, there are said like this:

{% set nodeX = bamboo_load_entity('node', node.id) %}
{{ node.id }} This is only used in the twig template of core file, cannot be used directly in the editor, i don't know how to write the hook.

Another, I want to ask, how to only use twig to load the entity data of current page without tokens?

Thanks for the response.

Oh, sorry, after the test, I found that can be used {{ node.id }} to get the current page entity data in inline_formatter_field editor, in the past, I test it on the snippet_manager and does't work so I think it's the same on inline_formatter_field, for filter processing order, if found necessary in the future, then come to request agian.

But for inline_formatter_block is still need, if you need it too, consider to add one, I now use the alternatives.

Thank you.

Hello,

Is it possible to use as a Text editor in Text formats and editors? Then, can be use a text editor in all places to use inline_formatter_field, In this way, can use the text_block to use inline_formatter_field, and also solves the Filter processing order and the block issues.

If there is no new feature development now, whether can consider to do it.

I like this idea. It makes sense to move the current editor into the core text formats and editors. Then update the existing fields to use the core text formatted fields with configuration for setting which editor to use. This might take a bit, but seems like a good path forward.

Looking forward to it become a text editor, I'm still follow it.

Thank you for being patient! I will create a feature branch for this to be tested since this will likely require multiple commits.

Moving this into the 4.x-dev branch.

Hello,

I have merged a large amount of work into the 4.x branch.

The update creates a new editor type for ace editor, and allows you to choose which editor the inline formatter should use. With the editor normal process filters can be attached as with any other Drupal editor.

I created some update hooks to try to make the transition easier in the upgrade.

Hopefully, this works as your request asked.

Thanks!

Thank you for your effort. As I am currently busy with other tasks, I have no time to manage the website. However, this is a great module that I will use as the main editor when I come back.

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