🇺🇸United States @chucksimply

The token output behaves as expected, whether or not the token_or module is installed.

For example, with this field: [easy_email:field_report:entity:field_photos]
• If the field contains an image, the value displays correctly.
• If the field is empty, no value is produced—there’s nothing returned (no space, extra character, or anything).

However, the token_or module still treats it as if it has a value, even when nothing is returned.

Could this issue be related to the token’s depth? Even using just
[easy_email:field_report:entity:field_photos]
isn’t recognized as empty, and the process stops.

chucksimply → created an issue.

The Custom Field → module handles this effectively, and generally could be considered a replacement for this module.

Applied merge patch from #19 and removed --strip, now autorotating as it should in 1.5.

new patch for views_ef_fieldset 1.10.0

#260 is the correct patch. This is what should be up for MR.

Now if you are leveraging this patch 🐛 Entity reference field View output is not used for selected entity display Needs work first from this issue 🐛 Entity reference field View output is not used for selected entity display Needs work , the attached patch works.

Probably makes things more confusing. Sorry... just figured it was worth mentioning. Not sure how these two major issues will collide in the future.

Disregard... this was due to another patch.

chucksimply → created an issue.

Wondering the same thing as #40

Want to keep this thread alive. ECA integration is pretty essential to the future of this module, with ECA becoming such a foundational piece of Drupal.

Yup, ready as well.

I'm on 2.0-beta10...

#59 broke arguments entirely.
#60 MR works perfectly.

Thanks!

chucksimply → created an issue.

Okay awesome. Reimporting that config fixed it for me.

The the problem was immediate upon a fresh install of 4.0.0. I'm on core 10.2. Don't have any other info beyond that. 10.2 was not a fresh install though, so maybe its conflicting with another module?

Wondering if this issue should be closed or remain open to further explore the underlying cause?

Would this patch apply to other entities as well? Taxonomy, Node, etc?

Looking forward to this feature!

Updated working patch for 10.3.6

#260 didn't apply on 10.3

Assuming this is fixed in 10.3? The original commit in #132 plus the related issue in #135 was committed as well. Good to go?

Worked on 1.2. doesn't apply on 1.4.

#4 works great on 2.1 - thanks!

Yup, same here

Looks like this module is unusable for anything beyond 10.1. This is a major issue to say the least. Can the maintainer or anyone provide updates? Or is there another recommended module? Can we expect a working version at some point? Thanks!

chucksimply → created an issue.

Perfect, thanks for the module suggestion and quick reply!

chucksimply → created an issue.

Removed unnecessary line breaks in html format

Erroring out... updated patch.

New patch. #5 was stripping line breaks from plain text emails. Fixed.

Really needs a true module developer to review and fix this code though. That I am not :)

Yes, looks to be working as expected. Thanks!

First stab at a patch. This patch must be applied after the merge request patch is applied from this issue ✨ Define the Senders display name Needs review . Seems to be working so far. Definitely needs review.

Thanks for the response. This is also applicable to the SimpleNews → module. Any HTML within an email sent with SimpleNews is stripped. This prevents the overall functionality of the Simple News module, as line breaks and formatted newsletters can't be used. Upgrading this to major, as it hinders usage in multiple areas.

chucksimply → created an issue.

chucksimply → created an issue.

I see the commit, but this doesn't directly address the support of rewriting fields correct? Would still be nice to manipulate the data source of the Leaflet map with respecting the field rewrite.

chucksimply → created an issue.

Screenshot attached showing where the sender name is set in the webform email config.

The patch doesn't play nice with Webform. If you set the "Sender From Name" in a webform email, the following errors occur.

Drupal\Core\Entity\EntityStorageException: Email ""WEBFORMSENDERNAME" <support@sitename.com>" does not comply with addr-spec of RFC 2822. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 817 of /web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

and

Symfony\Component\Mime\Exception\RfcComplianceException: Email ""WEBFORMSENDERNAME" <support@sitename.com>" does not comply with addr-spec of RFC 2822. in Symfony\Component\Mime\Address->__construct() (line 54 of /vendor/symfony/mime/Address.php).

I'm seeing a double quote "" before the sender name, not sure if this is relevant.

Hey @davisben... I appreciate you working on this. Patched with the merge and working perfectly! Thanks again!

chucksimply → created an issue.

This patch add the feature and works in my use case. Although it obviously needs review to determine if it's production ready.

chucksimply → created an issue.

Looks like this is related to the S3FS module. In my settings.php, I have the below S3 settings...

$settings['s3fs.upload_as_private'] = TRUE;
$settings['s3fs.use_s3_for_public'] = TRUE;
$settings['s3fs.use_s3_for_private'] = TRUE;

But keeping these settings triggers the error noted in the original issue. If I comment these lines out, image uploads and manifest saves without issue. Sounds like this is directly related to the duplicate issue.

Should I create a new issue for this or include it in the related issue? Open to recommendations.

Still getting this same error. Fresh install with core 10.2.2. Should this have been solved on the duplicate issue?

Patch works great for 2.0.0. Push!

chucksimply → created an issue.

Any further updates on this. Would be a great addition. Patch doesn't work on 1.4 on core 10.2

Running into an issue on both #8 and #9. If the View has a Page display, token gets completely dismissed when visiting that page. Thought it was a module bug, but removing this patch fixed it. See this dedicated issue for more detail.

https://www.drupal.org/project/views_argument_token/issues/3440035 💬 Views "Page" display ignores any argument token value. Closed: works as designed

Issue is due to patch #8 or #9 in the related issue.

chucksimply → created an issue.

patch fixes the issue for me

chucksimply → created an issue.

The issue looks to be with this module's Pager option. It says "Enter 0 for no limit", this isn't true. Enter 0 results in no links. Changing to a positive number does populate the sitemap as expected.

chucksimply → created an issue.

Any updates here? Allowing individual entities to be indexed even if the bundle is excluded is quite a common need. Seems like the latest patch breaks module functionality.

10.2.4 - Patch #11 Fixed it

Thanks all for the quick work. New release tested and works great!

Circling back on this issue... found a resolution.

This issue here 🐛 Orientation is no longer fixed if a maximum image resolution is set on the field RTBC fixes an issue where EXIF data was removed if Max Image Size constraints were defined and executed for an image upload.

Solution:
- Apply the patch from the related issue
- Add -strip to Execution > Prepend arguments, just like in comments #5, #6, #7.

Now ImageMagick and this module work as expected.

This is a major issue. Banging my head for weeks, unable to figure out why this module works with some images but fails on others. The failures had maximum size constraints implemented on uploaded.

Patch applied to 1.4 and fixed the problem. Should be pushed asap.

chucksimply → created an issue.

So it's not 100% solved. I originally had the -strip option under the Prepend arguments on the Image Toolkit page. Orientation remained incorrect.

I then removed the -strip option, and now all my image styles that convert to WEBP have the correct orientation. But without the convert, they still are incorrect.

This isn't really a solution, and I'm not sure what's going on. Still confused.

-strip was the reason why images weren't being rotated correctly. Removed it, now working as it should. Drupal 10.2

Patch applied. Works just as expected. Let's merge!

Very interested in this

New patching working flawlessly.

Try this one

Here's a patch addressing this.

chucksimply → created an issue.

Updated new patch to account for the above.

Needed the use statement

use Symfony\Component\DependencyInjection\ContainerInterface;

added to the top of src/Plugin/Field/FieldFormatter/ShortScaleFormatter.php

I'll try uploading a new patch here shortly. Once this statement was added, seems to be working as expected!

Thanks for the patch! Installed, but when visiting the fields page... received this error.

Fatal error: Could not check compatibility between Drupal\short_scale_formatter\Plugin\Field\FieldFormatter\ShortScaleFormatter::create(Drupal\short_scale_formatter\Plugin\Field\FieldFormatter\ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) and Drupal\Core\Field\FormatterBase::create(Symfony\Component\DependencyInjection\ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition), because class Drupal\short_scale_formatter\Plugin\Field\FieldFormatter\ContainerInterface is not available in /web/modules/contrib/short_scale_formatter/src/Plugin/Field/FieldFormatter/ShortScaleFormatter.php on line 58

Would it be possible to declare the D10 compatibility in the info file on a new dev release? This way I don't have to do workarounds getting it installed with composer.

chucksimply → created an issue.

Okay... I see the selector .bpmn-io > .action set to z-index: 101.

And .gin-secondary-toolbar is set to z-index: 102

This is the culprit. I guess the question is should we patch css for the gin theme or the BPMN.IO module? Or is there another more recommended approach?

Thanks for the reply. Everything is up to the latest version, although it's been this way for quite a while with other versions as well.
Gin - 8.x-3.0-rc8
ECA - 1.1.4
BPMN.OI - 1.1.3

And I'm just using the theme... not the Gin Toolbar module. Checkout the attached screenshot.

New issue here...

chucksimply → created an issue.

chucksimply → created an issue.

#68 doesn't apply to 10.2, and #71 applies to 10.2 but doesn't show progress correctly (bar just goes straight to 100%).

Here is a new working patch based on #68 for 10.2.

Looks good. Thanks!

Where are we at with this latest merge request? Can we get a new D10 release?!

I'm using this approach for displaying profile fields on my user.html.twig template.

Create or Add this to a custom module.

function custom_mods_preprocess_user(&$variables) {
    $user = $variables['user'];

    $profile_storage = \Drupal::entityTypeManager()->getStorage('profile');

    // Load 'profile type'.
    $business_profiles = $profile_storage->loadByProperties([
        'uid' => $user->id(),
        'type' => 'business_profile',
    ]);
    if (!empty($business_profiles)) {
        $business_profile = reset($business_profiles);

        if ($business_profile->hasField('field_profile_first_name') && !$business_profile->get('field_profile_first_name')->isEmpty()) {
            $variables['biz_profile_first_name'] = $business_profile->get('field_profile_first_name')->value;
        }
    }
  }

Now you can call biz_profile_first_name in your user.html.twig template

{% if biz_profile_first_name %}
    {{ biz_profile_first_name }}
{% endif %}

And add all subsequent fields in if statements like the above field_profile_first_name code.

Not a perfect solution, but hopefully helps some folks.

Also interested!

Same question, does this work with layout builder?

I'm using the module Views Entity Form Fields → to display form fields in a view. Any form fields in a fieldset (on their own) don't display (same behavior as img).

@smustgrave is right, there needs to be support for more tags.

chucksimply → created an issue.

#8 Applied to 1.7, and fixes the error. I tried the merge patch on #15 first, but it failed to apply.

for 10.1.6, #247 failed. #254 applied and works as needed.

Merge patch works great. New release please!

Merge it!