Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Inline Formatter Field related feature and filter processing order
1.I like this module, because it is one of the few using the token in the views field, But it hasn't filter processing order, This is one of the feature request.
2.Add an inline_formatter_block.
Similar modules: text_block, token_block
Thank you!
Comment | File | Size | Author |
---|---|---|---|
#13 | Snipaste_2023-04-24_12-35-07.png | 20.74 KB | msn5158 |
Issue fork inline_formatter_field-3350061
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
msn5158 CreditAttribution: msn5158 commentedComment #3
msn5158 CreditAttribution: msn5158 commentedComment #4
bobbysaul CreditAttribution: bobbysaul commentedAfter 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.
Comment #5
bobbysaul CreditAttribution: bobbysaul commentedHello,
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:
Comment #6
msn5158 CreditAttribution: msn5158 commentedHello,
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 data 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!
Comment #7
msn5158 CreditAttribution: msn5158 commentedComment #8
msn5158 CreditAttribution: msn5158 commentedInfinite imagination
Comment #9
msn5158 CreditAttribution: msn5158 commentedComment #10
bobbysaul CreditAttribution: bobbysaul commentedHello 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.
Comment #11
msn5158 CreditAttribution: msn5158 commentedHello,
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.
Comment #12
msn5158 CreditAttribution: msn5158 commentedOh, 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.
Comment #13
msn5158 CreditAttribution: msn5158 commentedHello,
Is it possible to use as a Text editor in Text formats and editors? Then, can 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 are no new features development now, whether can consider to do it.
Comment #14
bobbysaul CreditAttribution: bobbysaul commentedI 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.
Comment #15
msn5158 CreditAttribution: msn5158 commentedLooking forward to it become a text editor, I'm still follow it.
Comment #16
bobbysaul CreditAttribution: bobbysaul commentedThank you for being patient! I will create a feature branch for this to be tested since this will likely require multiple commits.
Comment #17
bobbysaul CreditAttribution: bobbysaul commentedMoving this into the 4.x-dev branch.
Comment #20
bobbysaul CreditAttribution: bobbysaul commentedHello,
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!
Comment #21
msn5158 CreditAttribution: msn5158 commentedA great editor, currently in use. Thank you.
Comment #22
msn5158 CreditAttribution: msn5158 commentedComment #23
msn5158 CreditAttribution: msn5158 commentedComment #24
msn5158 CreditAttribution: msn5158 commented