Problem/Motivation

The integration with SendGrid's template system suddenly stopped working recently. This led me to review the SendGrid documentation and note that the PHP library has been updated to use v3 of the SendGrid API.

I have started work on updating the module to use this newer version of the API and PHP library.

I'm attaching my WIP patch that was made against the latest dev.

Ongoing working is in my github repo for now:
https://github.com/merauluka/sendgrid-integration

Remaining tasks

  1. Update documentation to reflect version 8 of core (instead of D7).
  2. User testing to verify functionality is working as expected.
  3. Update documentation to include how to incorporate custom arguments and work with SendGrid hosted templates.

User interface changes

Added debug mode to allow for additional logging during the mail sending process to aid in troubleshooting.

API changes

Update to the v3 API PHP library.

Data model changes

Updated handling of message data to match expectations of updated PHP library.

CommentFileSizeAuthor
#3 sendgrid_integration-3029884-api-v3-update.patch52.56 KBmerauluka
sendgrid_integration--api--v3.patch48.54 KBmerauluka

Comments

merauluka created an issue. See original summary.

merauluka’s picture

merauluka commented

I should note that with my current WIP I was able to send a test email via the SendGrid module's test form. This was with and without an attachment.

merauluka’s picture

merauluka commented
Status: Active » Needs review
StatusFileSize
new sendgrid_integration-3029884-api-v3-update.patch52.56 KB

After reading more through the documentation, the original reasoning behind maintaining a separate fork of the Sendgrid integration seems no longer to apply. The official Sendgrid PHP library now supports PHP v5.6 and up. It no longer appears to be attempting to maintain compatibility with PHP 5.3. While it's true that they're using a custom http client, since it's not conflicting with the version of Guzzle that ships with core, do we need to continue to maintain a forked repo? If we revert to using the official library we would gain the additional "hands" of all the Sendgrid devs and other devs contributing to that effort.

I hope I'm not stepping on any toes here. My original post here was with the hope to get this module onto the latest version of the Sendgrid API and to solve a problem on a non-profit that I help out.

I'm posting an updated version of my original patch here and marking this a Needs Review.

Status: Needs review » Needs work

The last submitted patch, 3: sendgrid_integration-3029884-api-v3-update.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

perignon’s picture

perignon commented

If you want to upgrade to V3 of the API, that work should be here: https://github.com/taz77/sendgrid-php-ng

We do not use the Sendgrid library for a reason. It does not use Guzzle but yet another REST client that they have developed (https://github.com/sendgrid/sendgrid-php/blob/8d8bfe0efac9b13f3e5657606c...). We choose to go the route of using Guzzle because it is included in Drupal 8 core. This cuts down on code of course and reuses what is already available in Drupal.

perignon’s picture

perignon commented

As a matter of fact, I already have a branch for V3. Feel free to help push it along. https://github.com/taz77/sendgrid-php-ng/tree/v3-api-upgrade

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

Perignon: it also increases the amount of effort for you to maintain it, and makes it so that customers have to wait for the module to be updated to adapt to library changes.

For what it's worth, I opened an issue for the sendgrid-php project requesting they leverage guzzle rather than use a custom library:
https://github.com/sendgrid/sendgrid-php/issues/802

perignon’s picture

perignon commented

DamienMcKenna, we will see if they change their tune. They moved away from Guzzle.

I was working on this more diligently till because of events I switched to Mandrill for transactional email.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

The library maintainers responded:

The custom HTTP client we wrote is just a thin layer on top of the native PHP HTTP client. We chose to discontinue support for Guzzle due to numerous incompatibility issues with various frameworks. Since we removed Guzzle support, those issues have gone away.

Oh well.

perignon’s picture

perignon commented

Yup! Same answer I got a few years ago. I would love to get help to update my wrapper to V3. There is a branch on Github for it and I have done some work on it. I was working through fixing unit tests.

merauluka’s picture

merauluka commented

Hey @perignon, I took a look at the github repo and it's not completely clear to me what needs to be done. As I think is evidenced by this ticket, I would love to pitch in to get V3 of the SendGrid API working with this module. But I still think that the wins to using the library provided by SendGrid outweigh the cons of their choice to use a wrapper written around the native PHP HTTP client. It doesn't appear to be much more code they've written and it would free up this module to build upon the work of the SendGrid team and community. I'm sure there are other libraries in use by modules on Drupal.org that perform HTTP requests without relying on Guzzle (Mandrill appears to be one of them).

Would you consider switching to use the official SendGrid PHP library in the interest of clearing the path for future updates? It would also free you up to do all the things you've been longing to do. Like parasailing and cliff jumping. ;-)

erbaker’s picture

erbaker commented

At the very least, some documentation specifically stating that this is built for V2 would go a long way.

perignon’s picture

perignon commented

Well it kinda is.... https://github.com/taz77/sendgrid-php-ng/blob/master/README.md

chris matthews’s picture

chris matthews commented

I'm considering switching from SMTP Authentication Support to SendGrid Integration. Can anyone advise re: the status of the update to v3 of the SendGrid API?

https://sendgrid.com/docs/API_Reference/api_v3.html
https://sendgrid.com/docs/API_Reference/Web_API_v3/index.html

perignon’s picture

perignon commented

The PHP wrapper is the key item for this, so track the Github project.

shrop’s picture

shrop commented
Issue summary: View changes
dpi’s picture

dpi
Location Perth, Australia
commented

I had a need to use V3 + the SendGrid lib, thus SendGrid API was born.

Open for collaboration. Or if you want to take the code, though I see this project is also looking for new maintainers.

I also created an experimental Guzzle shim, it seems to work with a handful of GET/PUTs. Opt-in for now via a checkbox.

perignon’s picture

perignon commented

The SendGrid libraries are very well done. But adding another HTML curl client when Drupal already has one in Core just goes against every fiber in my body (I hate requirements creep).

I am back to actively working on this module as I need it. That means I am devoting time to the API wrapper. Right now unit tests are all broken but it will send mail using the V3 API.

chris matthews’s picture

chris matthews commented

To avoid confusion in the D.O. community, once SendGrid Integration has a stable release utilizing the V3 API, it seems like it would be best if the SendGrid API module was marked as unsupported in favor of the this module. Then, site builders will not be confused as to which module to use.

dpi’s picture

dpi
Location Perth, Australia
commented

But adding another HTML curl client when Drupal already has one in Core just goes against every fiber in my body (I hate requirements creep).

Can’t tell if this is directed at my work, since this is not what it does at all.

The project simply does OO juggling to make the sendgrid/php-http-client client accept Drupals Guzzle client. No overriding, adding, or replacing.

I’m actually quite happy how it turned out. Id suggest borrowing some of it ;)

it seems like it would be best if the SendGrid API module was marked as unsupported in favor of the this module.

I probably won’t end up deprecating it, but it will be in maintenance mode for a while. The API is simple and low maintenance, and the integrated Key and Monitoring integration are absolute requirements for our projects.

perignon’s picture

perignon commented

@dpi Nothing directed. Just a statement about my motivations to not use the SendGrid libraries.

I will check out what you did. I have gotten my v3 code working, just all the unit tests are broken. I won't release it till the unit tests are updated.

I have a copied most of SendGrid's code to make the wrapper, just taking out the http client and using Guzzle instead.

chris matthews’s picture

chris matthews commented

If both the SendGrid Integration and SendGrid API modules are going to be active at the same time, then I think it's important for each project to reference the other one as well as detail the differences (however small) between the two modules.

perignon’s picture

perignon commented

For those following this issue. I have started upgrading the module. I finished the wrapper code to V3 a few weeks ago.

The 8.x-2.x branch is where the work is taking place. It does not work as of the writing of this message. I am actively updating the code for the new wrapper stuff.

perignon’s picture

perignon commented
Version: 8.x-1.x-dev » 8.x-2.x-dev
jsacksick’s picture

jsacksick commented

@Perignon: I thought the https://github.com/taz77/sendgrid-php-ng/ 2.0 branch was supposed to be using the Sendgrid v3 API, is that not the case? Or is that work simply not "done"?

What's the current status? Is there any work aside from the "library" that needs to happen?

perignon’s picture

perignon commented
Status: Needs work » Fixed

I never updated this issue. The work is done. The v2.x of the wrapper code is using API V3.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.