Retrieving All Attributes via REST API

Hello,

I’m writing an extension for WPMUDev’s Hustle plugin (opt-ins/pop-ups) to use PHPList. I’ve got a decent start, but I’m running into an issue that hopefully people can help with.

It looks like there’s no API call (that I can find) to query the configured Attributes in PHPList. It would be very helpful if you could query PHPList via the REST API to get a list of the attributes currently configured for subscribers.

Is there a way to do this that I’m missing?

If there’s not currently a way to do this, if I created a patch for this, would you be willing to incorporate it into the REST API so I could have smoother upgrades in the future? I would prefer not to edit your code, because then when you update the REST API I would have a hard time updating without manually applying my changes.

Also, is the new REST API V2 (for PHPList v4) ready for prime-time? It looks like it’s still in alpha, so I’m not using that one. I’m currently using PHPList 3.4.0 with the previous REST API.

Best,
Dave

1 Like

@davewbtdc Happy to hear you’re trying out the APIs. Neither the previous or the current API currently offers attribute management, but it’s a frequently requested feature set. Please see the rest API repo on GitHub and the related phpList 4 repos:



Context and links regarding phpList 4 and the api can be found in this post from last year: https://www.phplist.org/phplist-4-update/

The new API has been developed with large scale production use in mind by experienced PHP developers, however it is still fresh and beta quality. We are hoping to offer it to users of the hosted service at phpList.com within the next few months.

Your patches and feedback will be valuable.

Sorry for my continued confusion. Is PHPList 4 standalone yet? This part is slightly confusing:

“PhpList 4 has focused on the providing a REST API initially so it provides something immediately useful to existing installations. Over time, the expectation is that more functionality will be added to phpList 4, including a web interface, and in future it will come to replace phpList 3 entirely…”

I deleted my development copy of PHPList 3.4.0 and then installed the phpList/base-distribution via composer, as stated on this page:

Is this the right thing to do, or am I supposed to still have PHPList 3.4.0 installed with the base-distribution package?

Good points, yes the docs should be clearer.

phpList 4 can be used standalone, though it only usefully provides the new REST API at present. However phpList 3.4.0 comes with phpList 4 bundled with it (in order to provide the new REST API).

For development you should use phpList 4 standalone via the separate repositories) so you can commit to each repo individually). For running phpList 4 standalone you can use the base-distribution package (though there probably aren’t currently many use cases for this). To use the API in production without modification you can use phpList 3.4.0 for convenience (it will be automatically configured to use the same database as your phpList 3 Web interface).

Does that make sense? How could this be best communicated in the docs do you think?

Hello,

I have a question as to where the Attributes should be located in the code. Would you like me to include them in the Subscriber model, repository, and controller, or create a new Attributes model, repository, and controller?

I could imagine reasons for or against going either way, but I figured if I want my changes incorporated upstream then I would be better off to discuss your desired architecture first.

To begin with I’m only interested in making a REST API call to get the attributes list and associated data from phplist_user_attribute.

Also, architecturally speaking, what’s the difference between the phplist_admin_attribute data and the phplist_user_attribute data?

Best,
Dave

Pretty sure separate, but @oliverklee is the expert.

There’s a problem with the Integration tests. I’m getting this error:
PHP Fatal error: Trait ‘PHPUnit\DbUnit\TestCaseTrait’ not found in /Users/davetbo/git/base-distribution/vendor/phplist/core/src/TestingSupport/Traits/DatabaseTestTrait.php on line 27

It looks from your phpunit.xml.dist file like you’re using version 6.2 of the PHPUnit schema:
xsi:noNamespaceSchemaLocation=“http://schema.phpunit.de/6.2/phpunit.xsd

But according to this page:

DbUnit no longer comes bundled with phpunit since version 6. Which version of phpunit did you run these tests on? Should there be a composer requirement for DBUnit or something?

I added:
“phpunit/dbunit” : “*”,
to my composer.json and did composer update and it fixed this issue.

Thanks,
Dave

1 Like

Sorry to keep bugging you guys, but I’m having a very difficult time getting these tests going.

Specifically now, I’m running out of memory just trying to run your Controller tests without mine. I was originally just trying to run mine but when I started hitting “Allowed memory size of … bytes exhausted” I switched to just trying to get yours to run. Same thing.

If I go into the directory base-distribution/vendor/phplist/rest-api and run:
phpunit tests/Integration/Controller

I get these errors:
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 262144 bytes) in /Users/davetbo/git/base-distribution/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php on line 281
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 262144 bytes) in Unknown on line 0

Any ideas what’s going on? My own research so far sounds like there might be some sort of Symphony memory leaks going on. If that were the case you might have seen this happening as well. Also, in my own test when I started seeing this, I set:
set_time_limit (6000); ini_set ("memory_limit", "-1");
and that just led to php processes that went over 10GB of RAM and eventually timing out after 10 minutes, and that was just on a single test that didn’t include any of your info except a reference to the AbstractControllerTest. That’s when I decided to just try your tests.

Any advice would be greatly appreciated.

Thanks,
Dave

There are several places the attributes need to go:

  1. in the core package, we need an attribute model/entity (and repository) and an m:n association subscriber<->attribute
  2. in the rest-api package, we need REST actions to access the attributes

For development of the core and rest-api package, you’ll need to install both as (separate) Composer projects. Developing for the packages within the base-distribution package (or developing for the core package within the rest-api package) either won’t work, or will work with a lot off hassle. Particulary, running the unit tests most probably won’t work.

Hope this helps,

Oliver

1 Like

Don’t worry about any more responses for me. I think I’m switching to Mautic at this point. It’s already working with the Hustle plugin I’m using, it seems to be further along in development, and it also runs on shared hosting.

I do appreciate all of your help, but I don’t have time to reinvent the wheel.

Best,
Dave

1 Like