PHP implementation lacking a lot of functionality

[bcismariu]

I was stunned to discover that only the fields mentioned in the Transmission documentation are supported. It turns out that if a setting is not defined in SparkPost\Transmission::$parameterMappings then it will not be taken into consideration, as there is no fallback to it: APIResource.php#L65

This prevents users from using additional settings (even though they are valid and supported by the SparkPost API), like, for instance options.ip_pool. On top of that, there is no easy way around it. The only option would be to wait for a future release in the hope that the new option would be supported by the official release.

My suggestion would be to allow for an easy fallback if the $mapKey is not defined in the $parameterMappings. As the name suggests, mappings should only map different settings to their corresponding official parameter: `'from' => 'content.from' and not filter through additional options that the user could use.
#67, #87

[richleland]

We're going to be starting work on the 2.x refactor next week. As a part of this we'll be getting rid of parameterMappings entirely in lieu of just being a transparent thin client to the API. We'll add in some sugar methods for cc and bcc, but those will just effectively modify the payload that will ultimately be sent.

In the meantime check out this example of using the unwrapped functionality with the transmissions API:
https://github.com/SparkPost/php-sparkpost/blob/master/examples/unwrapped/create_transmission.php

[richleland]

Handled in 2.x branch via #121 and #122.

[richleland]

2.0 has been released: https://packagist.org/packages/sparkpost/sparkpost