According to what I’ve read on the PHPList plugins page for the old REST API, 3.4.0+ comes with the new REST API. However, it doesn’t really. Here are the only contents of the /lists/admin/plugins directory from the default 3.4.0 install:
CKEditorPlugin Common fckphplist
CKEditorPlugin.php CommonPlugin fckphplist.php
COPYING.txt CommonPlugin.php inviteplugin.php
CaptchaPlugin SegmentPlugin subjectLinePlaceholdersPlugin.php
CaptchaPlugin.php SegmentPlugin.php
Any advice on why it doesn’t come with the REST API? Which REST API is currently the one I should be using? I also saw that the newer version of the REST API appears to be in alpha still, so it seems like either I’m missing something, or it’s a bit premature to mark the old one as deprecated.
@davewbtdc The new REST API comes in the lists/base directory - it’s not a plugin, unlike the previous one. It’s a separate application that shares the same database.
The separate application is phpList 4 - a rewrite of phpList using Symfony, Doctrine, and Composer. In time phpList 4 will take over other functionality of phpList 3 as well.
The previous API is marked depreciated not because of the release of the new one, but because it hasn’t been maintained in a long time (years). Therefore it may not be safe to use.
You should use the new REST API because that is under active development and will continue to grow in capability in future releases. Any contributions to that api would also be greatly appreciated. You should find it well documented and tested via CI which you can see on GitHub.
Thanks for the quick response. Can you point me to the up-to-date documentation and examples for the new REST API? I’d like to make sure I’m looking at the right info on its use.
First it was complaining about the SSL certificate in my dev environment because it was self-signed. I changed the form_params for the client request to look like this:
$reqParams = array(
‘form_params’ => array(
‘login_name’ => $this->username,
‘password’ => $this->password,
)
);
if ($ignoreSSL) {
$reqParams[‘verify’] = false;
}
Now when it posts the request to start the session, it gets the error:
[24-Mar-2019 19:29:35 UTC] API ERROR: 401: Client error: POST https://my-server.com/lists/base/public/api/v2/sessions resulted in a 401 Unauthorized response:
{“code”:401,“message”:“Unauthorized”}
However, I can use the username and password it’s using to log in directly. This is with the rest connection account I’m using “restApiAdmin” having all permission boxes checked but NOT being a super-admin.
If I change that account to super-admin, it gives me this error instead:
[24-Mar-2019 19:35:25 UTC] API ERROR: 500: Server error: POST https://my-server.com/lists/base/public/api/v2/sessions resulted in a 500 Internal Server Error response:
{“code”:500,“message”:“Internal Server Error”}
These errors are appearing in my WP error_log where I’m logging them. However, I can’t find your error logs anywhere in the file system and nothing of note is showing up in the GUI “Log of Events.”
I even changed to a password that would have no special characters in it, in case something was choking on certain special characters in the password. That didn’t seem to help.
Yes that’s correct. Either the API is enabled or disabled, and if you have login credentials for a super admin account then you can authenticate a new session and get a key for making requests.
Thanks for the replies, all. Sounds like this is another opportunity to make things more user-friendly.
Also, I’ve noticed twice now that the emails from the system say that you can reply to the email, but when you do, the email bounces. Here’s the error I just got from trying to reply by email:
Also, is it really required to have a super-admin account for REST API access? It seems to break the rule of least privilege to allow your REST API user to also create new admin accounts (or even to log in via the web interface at all, for that matter). I would think that just checking all the boxes and not making the account a super-admin would be better from a security perspective, but I’m not sure what else that would imply in terms of your codebase.
@davewbtdc The REST API is disabled by default for this release as it is beta, and should be used for testing only at the moment.
The changes to this file would be overwritten in the next release, but in future releases, it will be shipped enabled by default and therefore would require no changes.
I’m up to the part where I try to add a subscriber and it’s not working. Specifically, your RestAPIClient example here has no example on how to add a subscriber, or any other POST calls other than the first session creation:
Can you provide an example of how to add a subscriber? To make matters a bit more confusing, the documentation here uses CURL directly instead of Guzzle, which is what you use in the example above.
While I wait for your response I guess I will try it the CURL way instead of the Guzzle way in your other example. Thanks again, and sorry to keep bugging you! I really want to make it so I can use PHPList with WPMUDev’s Hustle Opt-in module, but it’s proving trickier than I imagined to integrate with your API so far…
OK, clearly I’m relatively new to Symphony. I realize you don’t have all the API endpoints documented yet and examples created yet. That’s fine. Is there a way I can poke around in the code to find the endpoints available?
I do see that the Subscriber model has a public function called setSubscribedLists, but I’m not sure how or where I would call that. I tried adding it to the initial post data when adding the subscriber like this and it didn’t work:
$dataToPost = [
‘email’ => $data[‘email’],
‘confirmed’ => true,
‘blacklisted’ => false,
‘html_email’ => true,
‘disabled’ => false,
‘subscribed_lists’ => array($list_id)
];
Instead of ‘subscribed_lists’ I also tried ‘subscribedlists’ and just ‘lists’. None of those worked either.