We've been wondering.
Do any of you developers out there using our API in PHP make use of the wrapper class we have in our samples?
If you do, do you find it comprehensive enough, or have you been using it mainly as a starting point?
More importantly, if you don't use it, why not? Is it too hard to understand? Does it make use of server components you don't have access to?
Any feedback on this is welcomed and sought after, but we'd especially like to know why you may not be using the wrapper if you are a PHP developer.
I modified the CampaignMonitor PHP example to use with the similar MailBuild API (which I notice aren't bundled in the MailBuild API examples yet).
My experience with both PHP sample sets was not great. The only relief was the full CampaignMonitor Class included in the CampaignMonitor examples.
Here is my rundown of the problems with the examples...
1. The samples are broken down into PHP4 and PHP5 directories, but the files contained within PHP5 are not logically ordered. Example code in the PHP5 folder is for PHP's optional SOAP client component, and not for the standalone class, this layout is confusing. Some sub-foldering is necessary in there or simply get rid of the native PHP SOAP examples in favour of the custom class and add better examples that use the custom class.
2. In the Mailbuild API at least the NuSOAP examples were horribly broken for me, and the NuSOAP libraries were outputting malformed requests.
3. PHP's optional SOAP components aren't installed in the standard MacOSX 10.5 PHP - which you may be surprised to learn is the preferred development environment for many PHP developers - so I could not test the "native" PHP methods.
Basically there are too many options in the examples you provide and they are mostly poorly documented or broken. The organisation of the files is also incoherent.
I got it working, but I have some skill in this area, others may give up sooner.
My advice is to try and create one recommended custom class for both PHP4 and PHP5, extended from the existing class. Then create a bunch of well documented examples based only on that class. The native SOAP stuff is always there for people who want it, but if they know enough to want it they should know enough to be able to implement it themselves. It might also be possible to roll in MailBuild API compatibility into this same class. The only stumbling block is that classes dependency on SimpleXML which if I remember correctly is PHP5 only, but there are ways around that. The resulting class and examples should probably be referred to as a "PHP API Client".
The standalone class has more potential to cover the many variables that exist in PHP environments.
Just taking a quick glance at the PHP API related topics in this forum I'm noticing a lot of people have had similar problems to the ones I had. The problem here is that you guys don't have much in-house PHP experience - so the difference between recognising something that seriously broken as opposed to user or configuration error is hard.
At the moment I believe that in a lot of cases, NuSOAP is fundamentally broken when used with your API and can't be relied upon.
Thanks for your input Sam, we really appreciate it.
We'd love to have a single wrapper class that abstracted away any complexities of calling the API, but from the support requests we are getting from PHP developers, many of them are using the NuSOAP example.
Is this just because of the way we are presenting the files on the site and in the zipped download? Or are people having problems with the wrapper class and are then working with the NuSOAP examples?
And is there the possibility of creating a single class that can be used from both PHP 4 and 5? We consider ourselves novices at PHP so we'd love to hear some input from you guys on if this is possible.
A single class would be possible, the only hiccup is the current dependancy on PHP5's SimpleXML module (not in PHP4). So a raw method would have to be used to interpret the returned data. Not impossible.
Further, a single class could potentially cover both CampaignMonitor and MailBuild APIs as MailBuild is mostly a subset of CampaignMonitor functionality.
The wrapper class is PHP5 only, and so are the Native SoapClient examples. NuSOAP is supposed to be functional on PHP4 or PHP5. The reason PHP5 people aren't using the wrapper class is because there are no clear examples for using the wrapper class except for some comments at the bottom of the file. The examples that sit next to it are only for the native SoapClient.
The problem is that the examples you have require too much knowledge of how these various methods work. People want to be able to copy the file containing the class into their application and copy/paste the example code into the spot where they want it and that's not possible at the moment.
We've been using the PHP4 code (from a year or so ago) in a variety of projects.
I recall having trouble getting mutli-option (select many) custom fields to work. There weren't any examples or instructions for this sort of thing and I remember having to email you guys to figure it out. You were most helpful over email, but perhaps more in-depth instructions would help others.
Also, I remember some hiccups getting NuSOAP running, but nothing too painful.
Keep up the great work.
Personally I'm not a PHP developer, more a tweaker!
That basically means that I'd love to use the API but when I opened the files, it didn't make much sense to me. I think it'd be great to have proper documentation with examples with any API solution you provide.
Then again, I'm not a developer so maybe I should just forget about it :-/
In the CM Subscribers Pepper
I wrote my own code to hit the API. I wanted it to be light and clean, and also didn't want to worry about XML dependencies in different hosting environments. The Pepper code just uses cURL to submit a POST, and parses the return XML by splitting arrays.
hey sam. i'm the original author of the CampaignMonitor class--i'm working on a personal project and just went back to the class today to reuse some code. i forgot that i'm depending on simplexml, and, given that my project is going to potentially involve releasing a client, i started to think on how i can make it accessible for php 4.x users.
so, i think i'm probably going to use the XML Parser functions and will rewrite the code in that case. i didn't actually like that i was using simplexml in the first place, but i was [and still am] on a time crunch. that was the easiest choice then.
i've been swimming in xml recently though, and have been pretty good at slapping together xml parsers as needed, so i'm pretty confident i can at least make that change in the near future.
i'll also try to work on some better examples. i probably went into too many specifics with the comments i had and less on usage, but i think they're actually necessary when trying to make sense of the data you're getting back. (i.e. when one instance of a method call might return a scalar while the same method call in another instance will return an array). so, will try to tighten up wording.
to be more php 4.x compatible though, that also means i need to remove any access declarations, eh? sad.
not familiar with MailBuild, unfortunately, otherwise i would chime in with that. maybe i'll look into that and see if the CampaignMonitor class can be more extensible. (if it's just a matter of new api methods, you can always call those manually instead of through the methods.)
There is a back port of the SimpleXML for people using PHP4. You could use this to help make a php4 compatable version of the PHP5 class.
Oh ya.. Yes I use the great PHP5 class by Kaiser Shahid. I have had to add to it a bit (added clientGetSegments and clientGetSegmentsDropdown functions).
Personally I mostly skipped past the samples and just started playing with the class.. Kaiser's comments are fairly clear, and to the point. I prefer to understand how it works than just use it because "Thats how the sample was" ;-)
I am still holding out for more API access to things like creating and sending Campaigns, but for now the PHP5 wrapper gives me access to the functions the API provides..
From Australia to Zimbabwe, and everywhere in between, companies count on Campaign Monitor for email campaigns that boost the bottom line.Get started for free