🇺🇸United States @bobbysaul

Hello,
Sorry for being some time before getting back to this. With the update to version 4 of the module the checkbox for clearing tokens if they are empty was moved from the module's settings form (/admin/config/inline_formatter_field/settings) into the editor setting (/admin/config/content/formats/manage/iff_ace_editor).

There is a small note in the release notes → , but I guess it is not very clear. Sorry, for the confusion.

Note that `iff_ace_editor` is the machine name for the default editor that this module is set up to use although this could be changed (which is what config your drush command changes). In which case, depending on the editor type the settings could be different. But, for all editors of type Ace Editor (iff_ace_editor), they will have the same configuration settings.

Hopefully this makes sense.

Closing this as it is part of the 4.0.0-rc3 release.

Marking this as duplicate and closing.

The fix has been released in the newest 4.0.0-rc3 release.

Marking this issue as being fixed.

This fix has been confirmed in a duplicated issue:
https://www.drupal.org/project/inline_formatter_field/issues/3414856#com... 🐛 Inline formatter field not show ace editor Active
Marking this issue as fixed.

Good to hear that things are working well.

I am going to mark this issue as closed, and then we can continue working on the other issue 🐛 Inline formatter field not show ace editor Active to make sure everything works properly.

Thanks!

Hello,

This issue looks to be a duplicate of another issue, issue 3414750 🐛 Warning: file_get_contents(modules/contrib/inline_formatter_field/js/IffAceEditor.js): Failed to open stream: No such file or directory Needs review . The issue is currently in the "Needs review" state. I believe it is resolved with the newest 4.x-dev commit. If you could please try using the newest 4.x-dev branch to see if it fixes your issue? If it does work, please, mark that issue as reviewed and tested by the community.

Thanks!

Hello,

Can you provide steps to replicate your error. I am unable to reproduce this. I have tested the 4.x-dev branch with Drupal version 10.0.11 on https://simplytest.me/ and did not run into any issue.

Thank you!

Hello and thank you for submitting your issue.

I am wondering if this is the cause of your other issue 3414856 🐛 Inline formatter field not show ace editor Active . Have you tried the steps I listed in the other issue and also clear the Drupal cache (drush cr). I am not seeing where this error would have originated from the above logs.

Thanks!

I pushed up an update. Please, check to make sure this fixes your issue.

Thank you again!

Hello,

Thank you for reporting this issue. I can confirm that this is indeed the issue. It looks like I named some files with the upper case for the first character, but did not fix all yaml in libraries.yml. I think the best way forward will be to make sure it is lower case for both. I will get this pushed up soon.

Hello,

Thank you for reporting this issue. I want to check first if you ran the database update? There was an update hook with version 4 of this module, inline_formatter_field_update_8005, which should create the a text editor that uses the Ace Editor.

Can you verify the following:

1. the hook ran ([site url]/update.php or drush updb)
2. the text editor iff_ace_editor was created ([site url]/admin/config/content/formats)
3. the module's configuration is set to use that new editor ([site url]/config/inline_formatter_field/settings)

If all of those are correct, can you see if there is any errors logged?

Thanks!

Changed this page status to deprecated and added a deprecated note at the top of this page.

Updated the Formatted text field section to use the .processed value instead of the .value, and added a note under it to explain why.

I have reviewed and tested out the 4.x branch and can confirm that the issue is resolved. The 4.0.0-rc releases have this fix.

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!

Marking this issue as closed.

Hello @Nelo_Drup. Did the above suggestions work for you? Is there any work that needs to be done for this issue?

The same can also be done with the Twig Tweak view filter → as such:

{{ paragraph.field_image | view({settings: {image_style: 'medium'}}) }}

Using the token [paragraph:field_tipparr_tipbloq_reshom_img:[image style machine name here]] will return the url to the image with the image style specified on it. For example if your image style is "medium" something like this would render the image:

<img src="[paragraph:field_tipparr_tipbloq_reshom_img:medium]" alt="[paragraph:field_tipparr_tipbloq_reshom_img:alt]" />

You can see your image styles at /admin/config/media/image-styles assuming the image style module is installed.

If you want to do the same thing but with twig instead of tokens you can do something like this:

<img src="{{ paragraph.field_tipparr_tipbloq_reshom_img|file_uri|image_style('medium') }}" alt="{{ paragraph.field_tipparr_tipbloq_reshom_img.alt }}" />

Hello,

I guess it would depend on how you are rendering the image. I would recommend the Twig Tweak module and use one of the filters provided with that module, drupal_image → or image_style filter → .

Something like one of the following should work:

<img src="{{ node.field_media.entity.field_media_image|file_uri|image_style('thumbnail') }}" />

{{ drupal_image(node.field_media.entity.field_media_image|file_uri, 'thumbnail') }}

Moving this into the 4.x-dev branch.

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

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.

This should be fixed in the newest 4.0.0-rc1 release.

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,

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>

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 created a new 4.x dev branch that will replaces jquery and jquery.once with core.once. Since core/once was released in core 9.2 the module's core requirement was changed to "^9.2 || ^10". Please, review to see if this fixes the issue. Thanks!

Thank you for reporting this!

I believe the jquery.once library was removed in Drupal 10. I believe it should be replaced with a core once function. I can update the js. This will more than likely cause a major update to this module if the once function is not backwards compatible. I can update the code shortly!

Yes, I think that adding a feature for using a CKEditor editor is a reasonable request. Can you create another issue to track this feature?

I can also point you towards the Twig Tweak → module for embedding entities such as media with the "drupal_entity" twig function. For example:

{{ drupal_entity('media', 1) }}

And also if this issue for the tokens in the view field is working, can you mark this issue as reviewed and tested?

Thanks you!

Is the title field nested above the inline formatter field?
The inline formatter view field is set up similarly to the core custom text view field. The replacement patterns drop down should list which fields are available.

I added a commit to the dev branch that I believe gives the feature requested, replace tokens in the InlineFormatterViewsField.

I am reviewing your issue and just realized you are talking about the sub-module inline_formatter_views_field. I can verify that normal site tokens do not work as the module is currently. I will start working on this feature requests and hope to have it fixed soon. Sorry for the confusion.

bobbysaul → created an issue.

I've added a commit 1c3a46a1. Can you install the latest dev version → or apply the patch for the commit and verify if this fixes your issue?

After looking at the code, I see that there is a couple of unnecessary conditionals that are checking if the Tokens module is enabled. These are unnecessary because the token service was added in Drupal 8.9. I believe I can remove these conditionals and update the minimum supported version to 8.9.

Hello,

The tug boat test site has expired, but I was able to test out the functionality on my own local development site. I want to see if you have the Token Module → module enabled? The tokens do not work without this module enabled.

Hopefully, this helps you!

Hello, Does the previous comment help? Is this task ready to be closed?

Hello,
Here is a link to common twig patterns I've used when working with twig:
https://www.drupal.org/docs/contributed-modules/inline-formatter-field/c... →

The answer to your questions depends on where you are writing the twig. For example, if I am writing the twig from a node that has a reference field to a paragraph which contains a link field the twig could look something like:

{% for paragraph in node.field_paragraph %}
    {{ paragraph.entity.field_link|view }}
{% endfor %}

if you have the Twig Tweak module. Or, for more granule output it could be something like:

{% for paragraph in node.field_paragraph %}
    {% if paragraph.entity.field_link %}
        <a href="{{ paragraph.entity.field_link.0.url }}">{{ paragraph.entity.field_link.title }}</a>
    {% endif %}
{% endfor %}

If you are writing the twig from the paragraph types display then it would look more like:

{{ paragraph.field_link|view }}

if you are using the Twig Tweak module. Or for a more granule output something like:

{% if paragraph.field_link %}
    <a href="{{ paragraph.field_link.0.url }}">{{ paragraph.field_link.title }}</a>
{% endif %}

Notice that in the paragraph entity type we can access the current entity with the context "paragraph" whereas in the node content type the entity was referenced with the context "node". The entity type will determine the context. And chaining into entities referenced in an entity reference field can be done by using ".entity" after nesting into the field (see the example from the node entity).

Hopefully, this will help out!