Jump to content
daniels

Subscribe To Mailchimp

Recommended Posts

Hi @daniels, on a site, where I had installed and used the module since its first release, the subscribe method doesn't work anymore.
To clarify: The module is upgraded to the last master version.

Could it be, that there was a change introduced by MC, maybe two months ago? Since then it seems not to work anymore.
I setup a logger at these two points:
A) https://github.com/danielstieber/SubscribeToMailchimp/blob/fd5039ec94e2b4ad49458ce090a240ba2d3979d6/SubscribeToMailchimp.module#L53
and
B) https://github.com/danielstieber/SubscribeToMailchimp/blob/fd5039ec94e2b4ad49458ce090a240ba2d3979d6/SubscribeToMailchimp.module#L62

The responses are now all the time:

A) (status) 401
B)

{
  "type":"http://developer.mailchimp.com/documentation/mailchimp/guides/error-glossary/",
  "title":"Resource Not Found","status":404,"detail":"The requested resource could not be found.",
  "instance":"c31XXX66-XXXX-XXXX-XXXX-47c61XXX89eb"
}

Do you know about any changes?

EDIT:
This only happens when I try to subscribe a NEW user. When I send a already known user, I get back correct responses, like before:
A) (status): unsubscribed or subscribed
B)

{
   "id":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
   "email_address":"mctest13@xxxxxxxxxxx.xxx",
   "unique_email_id":"xxxxxxxxxxx",
   "email_type":"html",
   "status":"pending",
   "merge_fields":{"FNAME":"","LNAME":""},
   "stats":{"avg_open_rate":0,"avg_click_rate":0},
   "ip_signup":"xxx.xxx.xxx.xxx",
   "timestamp_signup":"2018-04-25T14:56:05+00:00",
   "ip_opt":"xxx.xxx.xxx.xxx",
   "timestamp_opt":"2018-04-25T15:11:24+00:00",
   "member_rating":2,
   "last_changed":"2019-04-04T08:15:30+00:00",
   "language":"",
   "vip":false,
   "email_client":"",
   "location":{"latitude":0,"longitude":0,"gmtoff":0,"dstoff":0,"country_code":"","timezone":""},
   "marketing_permissions":[],
   "source":"Unknown",
   "tags_count":0,
   "tags":[],
   "list_id":"xxxxxxxxxx",
}

 

Share this post


Link to post
Share on other sites

Hey @horst,

thanks for reaching out. I have to check the details, but just on first sight:

I think error B is just because of a problem at A. Line 62 is not supposed to be executed for new user.

I'm very sorry, but I won't be able to look into it before Friday/Saturday due to a business trip. I made a todo and will do some testing and refactoring when I'm back.

Maybe a quick and dirty fix for you meanwhile:

With an if, check If you get the 404 in line 62 (patch), and if yes, execute the post request which is supposed to be executed for new users:
$response = $http->send($api, json_encode($param), 'POST');
 

 

Share this post


Link to post
Share on other sites

Hi @daniels,

thanks for the quick response! Now, when so say it, maybe I have added a bug by myself when editing the module to add the logger. I've also wonder why not the other send method was invoked. I will check / resolve that and post here again with the new results before friday!

Share this post


Link to post
Share on other sites

Hi @daniels,

I'm using your module and I have to thank you a lot, it is saving me hours of time.

However I'm facing a problem: if I subscribe a user (goes fine), unsuscribe him (goes fine too) and then try to subscribe him again there goes nothing. He stays with the "Unsubscribed" status inside my Audience section of the Dashboard.

How could I try to solve this issue?

Thanks!

 

Share this post


Link to post
Share on other sites

If I remember correctly that has to be enabled in Mailchimp first. Allow someone to re-subscribe again. 

Share this post


Link to post
Share on other sites
On 4/7/2019 at 8:17 PM, horst said:

Hi @daniels,

thanks for the quick response! Now, when so say it, maybe I have added a bug by myself when editing the module to add the logger. I've also wonder why not the other send method was invoked. I will check / resolve that and post here again with the new results before friday!

Hi @horst,

I'm facing similar problems with subscribing a new user to my list, here is my code: (an hook for the LoginRegister module by ryan)

wire()->addHookAfter('LoginRegister::processRegisterForm', function($event) {
    $form = $event->arguments[0];
    foreach($form->getAll() as $f) {
        $name = $f->attr('name');
        if(strpos($name, 'register_') !== 0) continue;
        if($name == 'register_subscribe_newsletter' && wire('input')->post->register_subscribe_newsletter == 1) {
            $mc = wire('modules')->get("SubscribeToMailchimp");
            $email_dirty = wire('input')->post->register_email;
            $email = wire('sanitizer')->email($email_dirty);
            $subscriber = [
                'FNAME' => wire('input')->post->register_nome_iscritto,
                'LNAME' => wire('input')->post->register_cognome_iscritto
            ];
            $mc->subscribe($email, $subscriber);
        }
    }
});

And here is what the mailchimp console said about the request:

Cattura.thumb.JPG.005781d18809040f419525c754e4f0b6.JPG

I've tested everything I can imagine (list_id, api key, etc...) but nothing.

I've also tried to edit the line 62 of the module with

$response = $http->send($api, json_encode($param), 'POST');

but the error still remain....

Did you solved it somehow?

Thanks!

 

EDIT:

I've solved changing line 54 of the module from:

if($status !== false) {
//...
}

to

if($status !== 404) {
//...
}

Basically Mailchimp returns a status of 404 (and not false) when the module tries to insert a new user. This is correct because the user is not there in the list at first.

Share this post


Link to post
Share on other sites

Hey @horst, @3fingers,

I'm very sorry for the late response. I finally found some time to look into this.

@horst at the beginning, you mentioned a 401 error. I think this could be caused by a wrong audience id. But seems like this was no problem later?

- Regarding 404: you get a 404 for every new user, because the "getStatus" method simply can't find a status for that user. This is absolutely correct behaviour and the check itself is suggested by the API documentation. I guess it is not a good idea to log this as a warning, as it is part of the normal process. I removed that.

- @3fingers do you have double opt-in enabled or disabled? there was an extra 'if' on line 55 that has caused problems with resubscription when double opt-in was disabled. This should be fixed in 0.0.5. Thanks to jliebermann for posting this issue on github. (Note, that after a 'resubscribe', the user has to confirm his email adress again and will disappear in your "contacts" list until he does that!) 

- @3fingers your solution with updating line 54 can not really work, because the $status you are checking is not the HTTP_STATUS. It is supposed to be the subscription status, and it will be false, when you (correctly) get a 404 during the API call. So there should never be a 404 in $status 🤔.

Besides that, I changed the wording in the readme and comments from 'list' to 'audience', since this is the new wording by Mailchimp. Version 0.0.5 is live in a minute. Appreciate your feedback.

Thanks a lot for posting your issues and for your patience! Trying to answer you faster next time. Let me know if you still have problems.

  • Like 5

Share this post


Link to post
Share on other sites

hello, I need some help with a strange error:

Raw data option with CURL not supported for PATCH 

I checked all parameters and they are ok, any idea? I'm using PW 3.0.141 dev

Share this post


Link to post
Share on other sites

Hey @Sevarf2,

the module is using WireHttp. It seems like wirehttp introduced a curl fallback as mentioned here

You could try to play around with the options of the send methods in the mailchimp module e.g. trying socket instead of auto (=curl?) as a fallback  (here are the options of the send method of http wire https://github.com/processwire/processwire/blob/dev/wire/core/WireHttp.php#L434). Let me know if this makes a difference!

Another possibility:
Have you made the module work on that same server already? Maybe there are some serversided settings that make problems with curl.

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, daniels said:

Hey @Sevarf2,

the module is using WireHttp. It seems like wirehttp introduced a curl fallback as mentioned here

You could try to play around with the options of the send methods in the mailchimp module e.g. trying socket instead of auto (=curl?) as a fallback  (here are the options of the send method of http wire https://github.com/processwire/processwire/blob/dev/wire/core/WireHttp.php#L434). Let me know if this makes a difference!

Another possibility:
Have you made the module work on that same server already? Maybe there are some serversided settings that make problems with curl.

I added a parameters array to the send command using socket as fallback as suggested, don't see the error anymore but neither the user subscribed 😞

$params = array(
   'fallback' => 'socket',
);
$response = $http->send($api . '/' . md5($email), json_encode($param), 'PATCH', $params);

Share this post


Link to post
Share on other sites

 @Sevarf2 thanks for giving it a try. I'll try to reproduce your error in the next days, maybe I can find a solution. sorry for your troubles.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
12 hours ago, daniels said:

 @Sevarf2 thanks for giving it a try. I'll try to reproduce your error in the next days, maybe I can find a solution. sorry for your troubles.

thanks, I appreciate.

Share this post


Link to post
Share on other sites
Posted (edited)

Did anyone figure out the issue with error:

Raw data option with CURL not supported for PATCH

I'm having the same issue, and digging around can't see where the issue is...

Any help would be greatly appreciated.

UPDATE: Thought I'd sorted it but it turns out I haven't. I've added a log to output the parameter to make sure that data is set and not empty and it appears to be correct: {"email_address":"someemail@here.com"} yet I'm getting the PATCH error.

Hoping someone has figured this out 🙏

Edited by alexmercenary
NOT SOLVED

Share this post


Link to post
Share on other sites
On 4/28/2020 at 2:22 PM, alexmercenary said:

Did anyone figure out the issue with error:

Raw data option with CURL not supported for PATCH

I'm having the same issue, and digging around can't see where the issue is...

Any help would be greatly appreciated.

UPDATE: Thought I'd sorted it but it turns out I haven't. I've added a log to output the parameter to make sure that data is set and not empty and it appears to be correct: {"email_address":"someemail@here.com"} yet I'm getting the PATCH error.

Hoping someone has figured this out 🙏

@alexmercenary, Maybe the fix here will help you: https://github.com/danielstieber/SubscribeToMailchimp/issues/9

 

I am also having troubles using this module. 

The test for the api settings works but when i try to subscribe a user it does not work. I dumped the response text and I get 

"{"type":"http://developer.mailchimp.com/documentation/mailchimp/guides/error-glossary/","title":"Resource Not Found","status":404,"detail":"The reques ...

I am on localhost at the moment but I guess that should not matter? Anybody had this problem so far?

 

 

EDIT: Problem fixed with 0.0.6 dev branch on github. 

Share this post


Link to post
Share on other sites

Hey all,

open issues are fixed in 0.0.6 (changelog), you can update it now. I would strongly recommend to update it, as there were major issues regarding subscription of new users.

Thanks for your help and patience! Keep me updated if you run into errors ❤️

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By bernhard
      --- Please use RockFinder3 ---
    • By MoritzLost
      Cacheable Placeholders
      This module allows you to have pieces of dynamic content inside cached output. This aims to solve the common problem of having a mostly cacheable site, but with pieces of dynamic output here and there.  Consider this simple example, where you want to output a custom greeting to the current user:
      <h1>Good morning, <?= ucfirst($user->name) ?></h1> This snippet means you can't use the template cache (at least for logged-in users), because each user has a different name. Even if 99% of your output is static, you can only cache the pieces that you know won't include this personal greeting. A more common example would be CSRF tokens for HTML forms - those need to be unique by definition, so you can't cache the form wholesale.
      This module solves this problem by introducing cacheable placeholders - small placeholder tokens that get replaced during every request. The replacement is done inside a Page::render hook so it runs during every request, even if the response is served from the template cache. So you can use something like this:
      <h1>Good morning, {{{greeting}}}</h1> Replacement tokens are defined with a callback function that produces the appropriate output and added to the module through a simple hook:
      // site/ready.php wire()->addHookAfter('CachePlaceholders::getTokens', function (HookEvent $e) { $tokens = $e->return; $tokens['greeting'] = [ 'callback' => function (array $tokenData) { return ucfirst(wire('user')->name); } ]; $e->return = $tokens; }); Tokens can also include parameters that are parsed and passed to the callback function. There are more fully annotated examples and step-by-step instructions in the README on Github!
      Features
      A simple and fast token parser that calls the appropriate callback and runs automatically. Tokens may include multiple named or positional parameters, as well as multi-value parameters. A manual mode that allows you to replace tokens in custom pieces of cached content (useful if you're using the $cache API). Some built-in tokens for common use-cases: CSRF-Tokens, replacing values from superglobals and producing random hexadecimal strings. The token format is completely customizable, all delimiters can be changed to avoid collisions with existing tag parsers or template languages. Links
      Github Repository & documentation Module directory (pending approval) If you are interested in learning more, the README is very extensive, with more usage examples, code samples and usage instructions!
    • By Craig
      I've been using Fathom Analytics for a while now and on a growing number of sites, so thought it was about time there was a PW module for it.
      WayFathomAnalytics
      WayFathomAnalytics is a group of modules which will allow you to view your Fathom Analytics dashboard in the PW admin panel and (optionally) automatically add and configure the tracking code on front-end pages.
      Links
      GitHub Readme & documentation Download Zip Modules directory Module settings screenshot What is Fathom Analytics?
      Fathom Analytics is a simple, privacy-focused website analytics tool for bloggers and businesses.

      Stop scrolling through pages of reports and collecting gobs of personal data about your visitors, both of which you probably don't need. Fathom is a simple and private website analytics platform that lets you focus on what's important: your business.
      Privacy focused Fast-loading dashboards, all data is on a single screen Easy to get what you need, no training required Unlimited email reports Private or public dashboard sharing Cookie notices not required (it doesn't use cookies or collect personal data) Displays: top content, top referrers, top goals and more
    • By MoritzLost
      Sorry for the convoluted title. I have a problem with Process modules that define a custom page using the page key through getModuleInfo (as demonstrated in this excellent tutorial by @bernhard). Those pages are created automatically when the module is installed. The problem is that the title of the page only gets set in the current language. That's not a problem if the current language (language of the superuser who is installing the module) is the default language; if it isn't, the Process page is missing a title in the default language. This has the very awkward effect that a user using the backend in the default language (or any other language) will see an empty entry in the setup menu:

      This screenshot comes from my Cache Control module which includes a Process page. Now I realize the description sounds obscure, but for us it's a common setup: We a multiple bilingual sites where the default language is German and the second language is English. While the clients use the CMS in German, as a developer I prefer the English interface, so whenever I install a Process module I get this problem.
      As a module author, is there a way to handle this situation? I guess it would be possible to use post-installation hooks or create the pages manually, but I very much prefer the declarative approach. The page title is already translatable (through the __ function), but of course at the time of installation there is no translation, and as far as I'm aware it's not possible to ship translations with a module so they are used automatically. Could this situation be handled better in the core? I would prefer if the module installation process would always set the title of the Process page in the default language, instead of the language of the current user.
    • By joshua
      This module is (yet another) way for implementing a cookie management solution.
      Of course there are several other possibilities:
      - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/
      - https://github.com/webmanufaktur/CookieManagementBanner
      - https://github.com/johannesdachsel/cookiemonster
      - https://www.oiljs.org/
      - ... and so on ...
      In this module you can configure which kind of cookie categories you want to manage:

      You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience.
      Currently there are four possible cookie groups:
      - Necessary (always enabled)
      - Statistics
      - Marketing
      - External Media
      All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ...
      When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax:
      <script type="text/plain" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The type has to be "optin" to get recognized by PrivacyWire, the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision.
      If you want to give the users the possibility to change their consent, you can use the following Textformatter:
      [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie.
      You can also add a custom link to output the banner again with a link / button with following class:
      <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> This module is still in development, but we already use it on several production websites.
      You find it here: PrivacyWire Git Repo
      Download as .zip
      I would love to hear your feedback 🙂
      CHANGELOG
      0.1.0 Added new detection of async scripts for W3C Validation 0.0.6 CSS-Debugging for hiding unused buttons, added ProCache support for the JavaScript tag 0.0.5 Multi-language support included completely (also in TextFormatter). Added possibility to async load other assets (e.g. <img type="optin" data-category="marketing" data-src="https://via.placeholder.com/300x300">) 0.0.4 Added possibility to add an imprint link to the banner 0.0.3 Multi-language support for module config (still in development) 0.0.2 First release 0.0.1 Early development
×
×
  • Create New...