Update for Drupal 6

Any update on 6.x compatibility?

Try using webform and then add some code into the "Additional Processing" box on your form to send the details to CC.

The code to add can be found here: http://www.jamesbenson.net/projects/ConstantContact/

That code looks like the Site Visitor API, is there any code using the REST API?

This module only uses the Site Visitor API, as it relies on James Benson's class. A module that used the REST API would be superior, but I've ported the 5.x version to 6.x using Deadwood and went over the remaining bugs, and it appears to work acceptably, though I have not tested it completely. The only hitch I've noticed is that status messages are not displayed after actions - can anyone give this code a look and explain what's going on? Or perhaps let me know if the messages, such as 'You have been added to our list.', are visible in your install. (This does not appear to be a theming issue, as I have tested with Garland.)

In addition to porting to 6.x, I added a requirements hook to constant_contact.install that makes it obvious that you haven't downloaded the class from James Benson's site.

This module probably needs some attention. Some messages and titles are hard-coded, and it's likely users will want control over these things. Additionally, unsubscribing only works if you're logged in to the Drupal install, which seems a severe shortcoming. I'll try to give attention to these issues.

I've attached the (in progress) 6.x module here, as I don't have a CVS account, and I don't really relish the idea of wrangling with CVS anyhow.

Need this for a new site -- will give your attachment a try but would love to see a real release! I'd even be willing to be your CVS monkey if that's all that's standing in the way...

Thanks

For those of you requiring this to work on your site, you can use the Webform module with additional processing like sampeckham mentioned. I've worked it out and I'll post the processing code for those of you that need it.

Form components: First Name (becomes first_name), Last Name (becomes last_name), Email Address (becomes email), Confirm Email Address(becomes confirm_email_address). Once you have those components, save the form, and place this code into the "Additional Validation" field under "Webform advanced settings":

<?php
$email = $form_values['submitted_tree']['email'];
$first_name = $form_values['submitted_tree']['first_name'];
$last_name = $form_values['submitted_tree']['last_name'];
$confirm = $form_values['submitted_tree']['confirm_email_address'];

if ($confirm !== $email) {
  form_set_error('', 'Emails do not match.', $reset = FALSE);
}
?>

Then place this code in the "Additional Processing" field under "Webform advanced settings":

<?php
class ConstantContact {
  var $add_subscriber_url = "http://ui.constantcontact.com/roving/wdk/API_AddSiteVisitor.jsp";
  var $remove_subscriber_url = 'http://ui.constantcontact.com/roving/wdk/API_UnsubscribeSiteVisitor.jsp';
  function setUsername($username) {
    $this->username = $username;
  }
  function setPassword($password) {
    $this->password = $password;
  }
  function setCategory($category) {
    $this->category = $category;
  }
  function getUsername() {
    return urlencode($this->username);
  }
  function getPassword() {
    return urlencode($this->password);
  }
  function getCategory() {
    return urlencode($this->category);
  }
  function add($email, $extra_fields = array()) {
    $email = urlencode(strip_tags($email));
    $data = 'loginName=' . $this->getUsername();
    $data .= '&loginPassword=' . $this->getPassword();
    $data .= '&ea=' . $email;
    $data .= '&ic=' . $this->getCategory();
    if(is_array($extra_fields)):
      foreach($extra_fields as $k => $v):
        $data .= "&" . urlencode(strip_tags($k)) . "=" . urlencode(strip_tags($v));
      endforeach;
    endif;
    return $this->_send($data, $this->add_subscriber_url);
  }
  function remove($email) {
    $email = urlencode(strip_tags($email));
    $data = 'loginName=' . $this->getUsername();
    $data .= '&loginPassword=' . $this->getPassword();
    $data .= '&ea=' . $email;
    return $this->_send($data, $this->remove_subscriber_url);
  }
  function _send($data, $url) {
    if(!function_exists('fopen')):
      exit("fopen function does not exist");
    endif;
    if(!ini_get('allow_url_fopen')):
      exit("allow_url_fopen is not enabled in your php config file");
    endif;
    $handle = fopen("$url?$data", "rb");
    $contents = '';
    while (!feof($handle)) {
      $contents .= fread($handle, 192);
    }
    fclose($handle);
    if(trim($contents) == 0):
      return true;
    endif;
    return false;
  }
}

$email = $form_values['submitted_tree']['email'];
$first_name = $form_values['submitted_tree']['first_name'];
$last_name = $form_values['submitted_tree']['last_name'];
$confirm = $form_values['submitted_tree']['confirm_email_address'];
$extra_fields = array('First_Name' => $first_name, 'Last_Name' => $last_name);

$ConstantContact = new ConstantContact();
$ConstantContact->setUsername('My CC Username'); /* set your constant contact username */
$ConstantContact->setPassword('My CC password'); /* set your constant contact password */
$ConstantContact->setCategory('CC Interest Category'); /* set your constant contact interest category */

$ConstantContact->add($email, $extra_fields);
if($ConstantContact->add($email)):
  drupal_set_message('New subscriber successfully added.', $type = 'status', $repeat = FALSE);
else:
  drupal_set_message('Failed to add new subscriber.', $type = 'status', $repeat = FALSE);
endif;
?>

This code will include the ConstantContact class, which sets up the object and URLs to pass the form information to. It then sets up variables and brings in the information from the webform. Next it creates the ConstantContact object and then adds the user and sets a message.

You'll have to modify this code slightly (setUsername, setPassword, setCategory) to work with your CC account, but it should add the user beautifully.

Any thoughts on what it would take to make a custom Action that would update or add or remove users from one or more contact lists based on checkboxes in the user's profile, so that action could be triggered whenever a user registered on the site or updated their profile?

Actually for anyone looking to do this at registration, check out the Rules module. I just used the code posted here but in an Action to execute PHP code on registration and it worked like a charm!

here's michaek code as a patch.

I was unable to enable allow_url_fopen. Here is an alternate version using cURL. Also added support for subscribing to multiple email lists. You will need to create a select field called Mailing Lists. The value for each select option should be the name of a Contact Contact contact list.

<?php
class ConstantContact {
  var $add_subscriber_url = "http://ui.constantcontact.com/roving/wdk/API_AddSiteVisitor.jsp";
  var $remove_subscriber_url = 'http://ui.constantcontact.com/roving/wdk/API_UnsubscribeSiteVisitor.jsp';
  function setUsername($username) {
    $this->username = $username;
  }
  function setPassword($password) {
    $this->password = $password;
  }
  function setCategory($category) {
    $this->category = $category;
  }
  function getUsername() {
    return urlencode($this->username);
  }
  function getPassword() {
    return urlencode($this->password);
  }
  function getCategory() {
    return urlencode($this->category);
  }
  function add($email, $extra_fields = array()) {
    $email = urlencode(strip_tags($email));
    $data = 'loginName=' . $this->getUsername();
    $data .= '&loginPassword=' . $this->getPassword();
    $data .= '&ea=' . $email;
    $data .= '&ic=' . $this->getCategory();
    if(is_array($extra_fields)):
      foreach($extra_fields as $k => $v):
        $data .= "&" . urlencode(strip_tags($k)) . "=" . urlencode(strip_tags($v));
      endforeach;
    endif;
    return $this->_send($data, $this->add_subscriber_url);
  }
  function remove($email) {
    $email = urlencode(strip_tags($email));
    $data = 'loginName=' . $this->getUsername();
    $data .= '&loginPassword=' . $this->getPassword();
    $data .= '&ea=' . $email;
    return $this->_send($data, $this->remove_subscriber_url);
  }
  function _send($data, $url) {
   
    if($fp = tmpfile()){
        $ch = curl_init($url."?".$data);
        curl_setopt($ch, CURLOPT_STDERR, $fp);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
        $output = curl_exec($ch);
    }
    
    $contents = '';    
    $contents .= $output;
    curl_close($ch);
    
    if(trim($contents) == 0):
      return true;
    endif;
    return false;
  }
}

$email = $form_values['submitted_tree']['email_address'];
$first_name = $form_values['submitted_tree']['first_name'];
$last_name = $form_values['submitted_tree']['last_name'];
$confirm = $form_values['submitted_tree']['confirm_email_address'];
$extra_fields = array('First_Name' => $first_name, 'Last_Name' => $last_name);
$lists = $form_values['submitted_tree']['mailing_lists'];


$ConstantContact = new ConstantContact();
$ConstantContact->setUsername('CC Username'); /* set your constant contact username */
$ConstantContact->setPassword('CC Password'); /* set your constant contact password */

foreach($lists as $list => $label){
	$ConstantContact->setCategory($list); /* set your constant contact interest category */	
	$ConstantContact->add($email, $extra_fields);	
	if($ConstantContact->add($email)):
	  drupal_set_message("New subscriber successfully added to <strong>$list</strong>.", $type = 'status', $repeat = True);
	else:
	  drupal_set_message("Failed to add new subscriber to <strong>$list</strong>.", $type = 'status', $repeat = True);
	endif;
}
?>

http://www.jamesbenson.net/projects/ConstantContact/ redirects to http://justphp.co.uk/projects/ConstantContact/ and says:

Unfortunately the Constant Contact PHP code has been discontinued and is no longer available from this website. Given enough time I plan to re-code everything to use the new Constant Contact API however I do not know when this will be.

In the meantime you can get it here: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/constant_co...

Also, http://developer.constantcontact.com/doc/siteVisitorAPI says:

THE SITE VISITOR APIs, while still functional, ARE BEING DEPRECATED. Support for the Site Visitor APIs will be withdrawn by the end of 2009. The functionality of the SITE VISITOR APIs has been subsumed by the REST APIs available on this site.

You ROCK! This code worked perfectly for me. Thank you.

I've developed a Constant Contact module for Drupal version 6 or above.

See here for more info:
http://cc.justphpsoftware.com/

Where you can find that it is sold for £29.99 and but you won't find info on the licensing.

This is, in my opinion, not an acceptable resolution, unless, of course, you're planning on releasing it here. If this is not part of your plans, perhaps you'd be looking at finding a new maintainer for this project?

With respect to solution #10:

I am getting a webform log message that has an error within this line (75)

(Invalid argument supplied for foreach() in /.../webform.module(1742) : eval()'d code on line 75.)

foreach($lists as $list => $label){
$ConstantContact->setCategory($list); /* set your constant contact interest category */

I was thinking that the variables from my added "mailing_lists" field were passed along to $list, but perhaps they are not.

My question is then: how do I "set [my] constant contact interest category" (which I am guessing are my list names)

thanks for the code!

@fp, re:#15...

For code that is not in Drupal's CVS repository, however, the GPL still applies. Drupal modules and themes are a derivative work of Drupal itself. That means any code in them that "links" with Drupal code is covered by the GPL and if distributed must be distributed under the GPL as well. For PHP code, that effectively means that it is called from Drupal or it calls Drupal, so any module or theme is included, including template files.

There is no requirement that you distribute a theme you develop; however, if you do so, even if you are selling it commercially, then the PHP and Javascript portions of it must be distributed under the GPL. Images and CSS files are data, not code, so the requirements of the GPL on Drupal do not apply to them.

-- Drupal Licensing FAQ

Just sayin.

Good to know. Thanks jeffschuler.

Yep, agree with #17 and #18. I hope to find a real, GPL'd solution to this before the end of the year, as I am responsible for a site that currently uses #6.

Also, with #6, I'm having a problem: even though the contact is successfully added to the Constant Contact list, I am still getting the "Failed to add new subscriber" message. Does this have anything to do with the fact that $ConstantContact->add(...) is called twice, the second time seemingly only to determine which message to display?

/* set your constant contact interest category */
$ConstantContact->add($email, $extra_fields);
if($ConstantContact->add($email)):
  drupal_set_message('New subscriber successfully added.', $type = 'status', $repeat = FALSE);
else:
  drupal_set_message('Failed to add new subscriber.', $type = 'status', $repeat = FALSE);
endif;

I wrote that code long ago, and it's probably very broken. From what I can tell the ->add() function doesn't return anything we can check against to make sure the contact was added properly, so I'm not sure how to better check for errors in that script.

Charging a small fee for the module is allowed and I'm not violating the drupal license in any way.
I simply could not have developed and supported this module for free given that it took 3 weeks for the rest api code and 2 weeks for the initial module development.

justphp, there are a few things you need to know.

First of all, modules, as derivatives of Drupal's GPL'ed code, also are automatically under the GPL licence.

Secondly, it is allowable to charge a fee for GPL'ed code. However, by distributing it, you give others the right to redistribute and modify your code.

In short, it would be perfectly within their rights for someone to purchase your module, and adding it to the contrib archive here on d.org.

Charging a fee for a module distributed from another site is fine, provided that the module is still licensed under the GPL. As long as you are distributing it under the GPL, you can charge whatever you want. You just cannot (per the terms of the GPL) prevent anyone that buys a copy from you from redistributing it themselves for whatever cost they want, including zero, with or without their own modifications.

So as long as the license people are buying from you is the GPL, that's fine.

@Crell

Just FYI, it doesn't appear that the code is being offered under the GPL, since he is offering single- and multi-use licenses. I don't think that capacity exists under the GPL.

Also see:

http://drupal.org/licensing/faq (see 6, 7, 8, 9)

So it seems there is a quandary here for any would-be Drupal module developer looking to make money in a development venture. The bottom line is that it's not really a good model to charge for something that can possibly be obtained for free elsewhere. Heck, if it really worked that way, I could just sell installations of Drupal 6 and contrib modules to poor unsuspecting newbies. I might even make a few bucks doing this for a while. Of course no one could say I am violating licensing agreements, but on the other hand, it's not a sustainable business model, doesn't help me build a great reputation in the community, and doesn't embrace the open-source nature of Drupal.

It has been noted that doing customization and implementation work for Drupal is a hard business to make money at as well, although this is debatable, as I seem to see signs that some people have done pretty well for themselves in this regard; like anything else I would say it just takes time to build up a reputation. For myself, I have seen lots of offers for work for Drupal developers if that's something you are good at and want to do. Offering and maintaining a high-quality module in the Drupal community seems like it would be a great way to build up that clout.

So, JustPHP, you seem to have a great module there (and if there are any current users of this ConstantContact Drupal 6 module out there, please write a review in this thread!). And there is lots of interest in this module among the community. I am sure that releasing the module to the public would be a better solution than finding out that it's been hijacked and posted by someone else (and no, I am not suggesting that I would do that -- I would not, and I will not -- but if brianV and Crell are correct, this is an implicit risk in selling GPL code). My guess is that you could do quite well for yourself (maybe even better than you currently are) by repackaging the support services you are providing with the purchase and selling that and/or charging for customization and implementation work. (Look at Acquia, they seem to be doing pretty well!)

That said, do you think you would be open to releasing your module to the Drupal community under the right circumstances?

Respectfully,
Paul

A limit on the number of sites you can install a module on would, I believe, be a violation of the GPL. So that's a no-go.

I never said that selling GPL'd modules per-unit was a viable business model. If frankly don't think it is, and in the end it's self-defeating because someone will just replicate the functionality anyway as part of the community, everyone will use that, and you'll be stuck with a dead-end module. (It's happened to other developers before.) I just said that charging money for a module does not ipso facto violate the GPL. :-)

Crell, I understand completely. My comment was directed more at the author of the module. Personally I think that if you want to make money as a developer of Drupal or any other free open source software, it doesn't make a whole lot of sense to try and sell your work, even if it's legal; but there are other ways to make money at it. The context of my comment was based on the notion that the author had to charge money for the module to justify the time spent. There are other ways to make the time investment "worth it", including the sale of services and support. That is ultimately the point I was trying to make.

Hopefully the author will see the wisdom in this and offer the module to the public. There are apparently some great features in the module and good opportunities for enhancement as well, so it would be a shame to see this module suffer the "dead-end" fate or disappear completely.

I'm aware of the GPL license and how that works but do not think this breaks the rules in any way, support for multilple-domains is for support not a limit on the number of installations.

I'm happy to contribute this to drupal.org and change my services to be support and installation services only but this will take me a couple of weeks to implement, what it the best way forward with this because it seems to me the drupal project has reached a dead end?.

Looking at the guides for co-maintaining it says I have to have participated, which I have not:
http://drupal.org/node/363367

That's a guideline set by one particular group of developers, not a blanket required policy. Each module maintainer is at their discretion to decide how to handle co-maintainers. It looks like the maintainer of this module is at least somewhat active on d.o still, even if he's not focusing on this module.

If your module is sufficiently similar in architecture to the current one, you can post a patch from the current 5.x version to your version. You can also offer to come on board as a co-maintainer for the 6.x branch. He may or may not agree to do so. You will, of course, need a CVS account first.

If your version differs significantly, you can just post an issue with a tarball asking for permission to take over a 6.x branch.

How the maintainer will respond, I do not know. You could also try contacting him directly through his contact form, but the issue queue is generally preferred.

JustPHP:

It's great to hear that this module may become publicly available soon -- and just in time, I might add! Let me be the first to offer my support in testing, patching, and co-maintaining this module. I too am a relatively new Drupal developer (2 years as a site designer) and have only contributed a couple of patches so far, but I am an experienced programmer and very interested in increasing my experience with Drupal module development. So if you'd like another co-maintainer once you get going on this, please let me know.

Let me also add that if there are companies who wish to make use of the module they may be able to help fund your efforts by paying for the services. A lot of enhancement to Drupal modules seems to happen this way. A company or institution needs an enhancement so rather than "buy" a one-off solution or "contract" a module enhancement that never gets distributed outside their company, they "fund" the development of the module, which then gets released back into the open source community. If I am not mistaken, big chunks of the Drupal core itself got funded this way, deriving from the efforts of Howard Dean in creating grass-roots Web sites.

To apply for a CVS account, I believe the process is as follows:

1. Open a Support Request ticket in the Module Issue Queue, requesting to become a co-maintainer.
2. The current maintainer needs to approve your request
3. Submit a CVS account request application at http://drupal.org/node/59

Once you've got a CVS account, I believe the rest is pretty straightforward. I say "I believe" because I am currently in the middle of this process myself for a different module.

Another approach you may wish to consider, especially if this module is a big leap from the current 5.x branch, is to just submit your own separate module http://drupal.org/node/7765. You should figure out a plan with the current maintainer first, but in reading http://drupal.org/node/363367 it seems that it might be a bit more challenging to treat this as the same module, just from a process and procedure perspective. I've seen this happen before, off the top of my head I think it happened with TinyMCE and Workflow, where the original module was abandoned and picked up by a different maintainer as a new module.

He could spin it off as another module, true. It's best if he didn't, however. Just because that has happened in the past doesn't mean it's a good thing. :-) If we can keep a continual evolution within a single project that is better for all involved, *especially* if there's a continuous upgrade path. (Don't underestimate the importance of that!)

True. The Best Practices suggest, however, that every change to the existing module would need to be accompanied by an Issue to be documented, and this could be quite cumbersome. Also, a new working 6.x branch would need to be recreated (perhaps using the Deadwood version in #4, plus the code changes above.) Or are these, again, just "best practices" and could the new maintainer(s) instead just create an issue saying something like "Rebase the 6.x branch with code from new module" and call it a day?

I'll leave this to the experts. Just trying to do what I can to assist. Please let me know how I can help.

There's nothing preventing a module maintainer from starting from scratch for a new Drupal version. Although as we use CVS there is no such thing as "rebase". :-) Really, the only required procedures for module maintenance is what tags and branches get named, as those are tightly controlled. What is IN those branches and how they get there is governed by convention and recommendation, not strict policy.

At this point, though, the ball is in justphp's court to take it up with the current maintainer. They get to work out the details. The rest of us are just the peanut gallery.

Thanks for the info pauldawg and Crell, I've already submitted an issue to the modules issue queue and also emailed the maintainer directly so hopefully hear soon.

I would prefer to take over the existing project if the process is going to be relatively simple, looking through comments the current maintainer is not actively developing this anymore so I think it should be done that way rather than creating a new module.

pauldawg, I could certainly use your help writing docs and testing the module.

Thanks,
James

An update for drupal version 6 and the new Constant Contact REST API will be rolled out within the next 2 weeks.

+1 for the James Benson fan club! :)

Looking forward to this! Thanks for contributing this to the Drupal community!

Justphp, thanks for initiating.. i can help testing the module. Please let me know.