🇺🇸United States @rosemarystanley

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

Creating 3.1.9 release shortly

Patch applied and merged to dev branch.

Thank you for submitting the bug report and patch. I'll be reviewing as soon as I can.

Thanks all for your patches & commits. I'm in the process of releasing 3.1.8 that will have this bug fix in. I did go ahead and remove the token config save (it was outdated code and should have been removed before... and should have been changed to the saveTokens method)

Thanks I'll take a look and review as soon as I can.

Closing. This doesn't seem to be an issue anymore.

Merge request committed. New release 3.1.7 has been created and documentation is updated to include quotes. Thanks!

Thanks so much joel for the merge request. I'll review as soon as I can. Thanks.

Fix is available in v 3.1.5 or higher

Code change has been made of dev branch 3.x as well as will have a new release 3.1.6 shortly.

Hey. The module will automatically crop based on the crop type settings. But if the default/automatic crop is not how you prefer you can go in and manually adjust it.

Currently there is no AI functionality or complex analysis unfortunately. It just defaults to the most available space based on the crop settings starting from the center. The automatic crop is a plugin so in theory someone could come in and create a AI based plugin to add more complexity to it-- I would love to eventually add more complex options.

Let me know if you have other questions.

Yes, great point. I'll work on this.

Goodness, good catch. I've merged the PR and will create a new release shortly

rosemaryreilman → created an issue.

closing this out

Thanks so much for the patch for this!
It has been a crazy couple of weeks for me. Merging the PR in and made a release 3.0.2

rosemarystanley → created an issue.

Closing due to inactivity. Please reopen or create a new issue if need be.

Marking as fixed due to inactivity. Please reopen if need be. Thanks!

Rolled this into 3.1.4 release.

Thanks for reporting and patching! This is rolled into 3.1.4 release.

Closing due to inactivity and no response. Feel free to reopen if need be. Thanks!

Merged and in 5.1.4 release! Thanks

Merged and in 5.1.4 release! Thanks

Hello! I'm taking a look at this and I'm a little confused. Where are you seeing the geolocation / geocoder module requirement? I'm not seeing any requirement for those modules. There are some APIs that help with getting a user's geolocation from the IP address but that does not require any additional module. I thought I had hard coded something from those modules but I'm not finding anything that requires it. Are you getting an error message or something?

Hello! So when the module was originally created it was for a client who wanted to target audiences for specific modals by geographic region/state...we decided to publish it for others to use and I guess we never went back to adjust this to only require the geolocation module if you have the geolocation settings enabled. So I'm marking this as a minor bug to fix and conditionally require the module if you want to use geolocation targeting for modals.

Hrm, possibly. Do you have any deployment/workflow hooks that runs config:import?

I would try the newest patch in #3215168 → and try and move the tokens into the database.

Thanks for the update! Feel free to reopen or create a new issue if something changes.

So strange. I have been a bit swamped so I haven't had a chance to look into this further but thanks for updating and providing all the additional information.

So by default constant contact expires the access tokens "Access tokens automatically expire 1440 minutes (86,400 seconds). Making an API call with an expired access token returns a 401 unauthorized status code." so it should be saying 24 hours.. So that 2 hours is odd it may be a typo HOWEVER I don't think that would cause your tokens to need to be reauthorized manually. That time/date is what flags the cron to get a new token so that it doesn't expire.

Some other questions that may help... Is it the production environment that is always needing reauthorizations? Or the dev/staging environments?
We use pantheon, and I know the dev instances (non-live) stop auto-running cron sometimes if it has been inactive for awhile. But it shouldn't happen in the production (live) environment since that doesn't happen.

Are you using configuration sync? If so, when you go to the sync screen /admin/config/development/configuration is ik_constant_contact.tokens listed in the changed group?

Do you have the ik_constant_contact_tokens table in your database? If not, perhaps you need to run database updates? If you have recently done the update where tokens were moved to the database, it could potentially have cause a need to manually re-authorize the app.. but it shouldn't repeat.

I'm gonna keep trying to figure out what's going on, but I'm not sure because I haven't been able to recreate it in my environments that are using the module.

Hrm, I have a couple of questions to follow up:

do you have Long Lived Tokens set up on the Application(s)? See screenshot:

What version of the module do you have installed?

Ok rerolled the patch. Let's see how this does.

Thanks, that helps! I'll take a look as soon as I can. Moving back to needs work status.

Do you have any additional information via drupal logs?

New patch

Thanks! That's not a bad idea. I'll reopen this for consideration. (Updating the version as well)

patch has been rolled into 3.1.3

Closing due to inactivity. We can reopen or create a new issue if there is more to fix.

Marking as fixed. We can reopen or create new issue if there is more to fix.

Thanks so much for submitting a patch. Sorry it's taking me a bit to get to this. Been a bit swamped at work. But I'll take a look and hopefully merge in when I have a chance.

Finding more errors popping up. Will need to do a better check

Re-roll patch.