🇺🇸United States @rosemarystanley

Merged into 4.x-dev branch. queuing for release with a few other issues.

On 4.x-dev. Queued for a new release with a couple of other issues.

I created a PR to see if just adding an empty options array will suffice. It may not since the default value = NULL if there's no other config set. It may error but I'm unable to test it at the moment. Marking as needing review. If you have a chance and can use the patch from the PR, let me know if that clears the error for you. Thank you!

This warning is outdated and was part of an upgrade process (moving tokens from config storage to a database table) that should not be relevant at this point. (New installs will automatically create the database table we need) However, I did go ahead and change that warning to only show if the database table doesn't exist. On 4.x-dev

Thanks for reporting. Can you let me know what version of Drupal you're using (just in case). Thanks! I will review this as soon as I can

This is great, thank you for this. I will review when I can!

Thanks everyone.
@quietone thank you I'll try the other support methods as well.
@ishani patel I tried all of your suggestions and nothing came up.
@tushar5211 Thank you! I've tried all of your suggestions as well. (The drush entity:updates my install didn't recognize the command. I'm on Drush 13.6)

I did some more digging. The old field still has field_deleted_data_*** tables. I tried outputting devel info and found the Field Config storage somehow still fields the field. I tried to load the field_config_storage entity manually (to then try and delete it) but it returns null. When I try and delete a field via the UI i get the same field exception and if I devel dump the info the config loads as if it exists. So odd.

rosemaryreilman → made their first commit to this issue’s fork.

rosemaryreilman → created an issue. See original summary → .

Please check out 4.2.2 → . It seems I never bundled one of the changes from #3513890 🐛 AssertionError: "Constant Contact" must be defined in .... Active and likely is causing your issue. Let me know. Sorry about that.

Thanks all. I'll be looking into this as soon as I can. There were some annotation changes in Drupal 11 so it is likely something else has changed that was missed.

Fix is in new release 4.2.1

I created a new MR. I forgot to change the category value in the FieldType file. Let me know if that helps.

Created 4.2.0 → for this and a few other bug fixes

Created 4.2.0 → for this and a few other bug fixes

Created 4.2.0 → for this and a few other bug fixes

New Drupal API Changes: New API for defining field type categories →

I added a new MR that you can use the changes to see if that fixes your issue.

New Drupal API Changes: New API for defining field type categories →

Whoops sorry this was an issue introduced with a typo in your other bug report #3513508 ArgumentCountError: Too few arguments to function Drupal\Core\Form\ConfigFormBase 🐛 ArgumentCountError: Too few arguments to function Drupal\Core\Form\ConfigFormBase Active

I have updated the merge request there. If you reapply the changes and try again. Please see if that resolves your issue

Thanks for the report. please see the MR I created and give it a try. let me know if that solves your issue. Thanks!

rosemaryreilman → made their first commit to this issue’s fork.

Ok created release 4.0.2 that has this fixed. Closing this issue. Please feel free to reopen if you need!

I have confirmed that the automatic crop image effect is not working and have committed a fix on the dev branch. The issue was there was a missing event type in the dispatch of the automatic crop provider list.

$this->eventDispatcher->dispatch($event); should have been
$this->eventDispatcher->dispatch($event, Events::AUTOMATIC_CROP_PROVIDERS);

Creating version 4.1.1 for release to fix this

Thanks so much for providing a patch. I will plan on reviewing early next week.

Ok so there may still be a bug with the Automated Crop style effect. But yeah the automated crop effect, likely would not show in the IWC because it skips over the ability to manually set the crop. However, the generated image should be created so I'll look into that.

As for your question about the Manual crop changes... yes they should change right away in a normal file storage setup but I'm not sure how your S3 is set up. Does it upload/fetch files on cron? Maybe try checking there? Or try clearing cache for it to fetch something new just to test.

Ok couple of questions

• Did you set any hard or soft limits on the crop?
• Are you using the Automated Crop Effect or the Manual Crop effect with an automated crop provider?
• In the widget settings, do you have "Show default crop area" checked? I have noticed that this helps to see what the automatic crop will look like. Otherwise it won't show the crop box in the Image Widget Crop until you manually set/change the default.
• Is it just not showing in the IWC view or have you tried looking at the generated image style?

Fixed in 4.0.1

Fixed in 4.0.1

Fixed in 4.0.1

rosemaryreilman → made their first commit to this issue’s fork.

Thanks for this!

rosemaryreilman → made their first commit to this issue’s fork.

Thanks so much for the fix. Merging in!

rosemaryreilman → made their first commit to this issue’s fork.

Issue has been inactive for 4 months. I'm going to merge the code into 4.x branch and create an alpha2 release.

Code has been merged and ticket has been inactive. Closing as fixed.

All changes have been merged and D11 is released

New release 4.0.0 has updates

Went ahead and added this to new release 4.0.0 after testing on a couple of our sites. Please reopen if necessary.

Please see the merge request I created..and patch the module with it. I was able to recreate the issue you are seeing and I believe I resolved it. Thanks!

Thanks for reopening and reporting. We will take a look as soon as we can.

Ok I reviewed the other issues and created a PR to review and try out to see if that resolves your issue.

rosemaryreilman → made their first commit to this issue’s fork.

Ok created a merge request with some changes to integrate the entity save and mapping of other CC fields. I have no added custom field support yet but thought this might be a good start. Feel free to give it a try.

That's great. I am going to keep this open for now as a feature request because I'd like to integrate this as an option with the User registration form.

The line should actually should be

$body->street_address = (object) [
    'street' => $data['street'],  
    'city' => $data['city'], 
    'state' => $data['state'], 
    'postal_code' => $data['postal_code'], 
    'country' => $data['country'],
  ];

I think that's the issue

Hello and thanks for reaching out. I will try to take a closer look as soon as I can.

A couple of suggestions on what you can look at in the meantime:

There are hooks that fire before sending user data to constant contact. This one could be helpful:
hook_ik_constant_contact_contact_data_alter details can be found in ik_constant_contact.api.php

That may be a little more complicated but could be useful.

The email address from an entity is mapped via field settings in Drupal\ik_constant_contact\Plugin\Field\FieldType\ConstantContactListItem
Likely this file may need to be modified to map the other user/entity fields.

I'll take a look as soon as I am able.
Thanks!

Added a pre-release for testing
https://www.drupal.org/project/ik_constant_contact/releases/3.1.10-rc1 →

Added a pre-release for testing
https://www.drupal.org/project/ik_constant_contact/releases/3.1.10-rc1 →

Taking a look, thanks for adding a patch

Changes up to this point applied to 4.x-dev branch

Fixed in →

Fixed in →

Fixed with →

Reapplied patch and will be releasing 3.0.3 with the correction. It must've gotten lost in the merge from the another issue.

rosemaryreilman → made their first commit to this issue’s fork.

Closing due to intactivity

My goodnes! thanks for catching that @ddiestra