I want to perform my own parsing off-site using a third party, but PHPList is quite frankly bloated and confusing. I can’t find where it parses user attributes, and I’m also looking for where/how it stores the user attributes each message is going to use… if it even does that. I’m honestly lost, looking through a crazy amount of files with no clear documentation. Could someone here provide some insight?
@Syrsly Not sure what you mean by disabling the attributes. Apart from a couple of attributes which are setup by default, you have to add an attribute before it exists. So if you don’t add any, then you won’t have them. It may also be able to remove the default attributes if you try. Subscribers can only interact with attributes that you’ve already created, so you have control.
Regarding how they’re stored: it’s flexible, probably using a key+value schema. Therefore when you add a new attribute it will be added as a key+value to the corresponding table. Attributes are merely looked up at send time; there is no need for them to be stored again or separately.
Hope that helps.
That’s a start, thank you, Sam.
I’m trying to figure out how these attributes are sent through the application’s queue/send process, because I want to completely disable the parsing of these attributes and send them instead to the third party solution. I know I can just remove the attributes, but that would get rid of the attributes entirely. I still want the data, I just want to format the data output a different way (to improve performance when sending thousands of email addresses at once), as a combined array with a single subject value and a single message body value each with their placeholder tags still intact (instead of replacing them).
Hope that makes sense! I’m not looking for anyone to give me a fully working solution, mind you, but if something like this already exists, please, let me know. I’m mostly just hoping for a push in the right direction.
@Syrsly Is the primary objective of your project to improve phpList message processing speed? What kind of speed per hour are you looking to achieve? On phpList Hosted we have peaked at around 60-70k per hour per server; but that’s dispatched (generated and sent via SMTP), not just generated.
We get about 10-14k per hour right now with a smtp relay, but I’m trying to utilize multicurl methods and getting a similar speed. I want to combine these curl executions into larger arrays to be sent over to our third party sender, which is currently SendGrid (though that may change someday). We can use a sendgrid plugin for this, but it doesn’t do much more than a curl wrapper for each email sent, which is not very helpful for our needs.
You could use a different delimiter, e.g *NAME* instead of [NAME]. phplist will not do anything with the former, but your third-party can recognise that.
1 Like
Okay, I think I’m on my way to figuring this out thanks to defaultplugin.php being used as a reference. There’s a function called setFinalDestinationEmail that gets fed an array of user attributes, $uservalues, that I can leverage for what I need. I’ve broken my code somehow earlier on, so it’s only sending a single email per queue processed, but I’ll troubleshoot that and figure it out.
For now, if anyone is looking for a similar solution, here’s the override function (simplified for example purposes):
public function setFinalDestinationEmail($messageid, $uservalues, $email) {
$this->user_att_values = $uservalues;
logEvent(‘Email attrs:’.json_encode($this->user_att_values).‘’);
return $email;
}
I print out the user attributes so I can see what’s available (for debugging purposes), but the important part is that I store these attributes in the plugin class for use later in the code, when I need to send the information to my own array.
Now, I just need to figure out how to stop the parsing of these attributes’ placeholders so I can leverage the system’s values elsewhere.
1 Like
The reason why I’m not doing that is I would have to change every attribute mention in all of our vast supply of templates/campaigns to use a different style/syntax, and if we ever had to disable the plugin or switch to another method of delivery, we would have to switch all those placeholders back. It seems like it should be easier to just have a condition in the logic of the code that allows us to prevent parsing of placeholders.
I’d encourage you to add this as a Pull Request to phpList 3 so that it’s easy for you and others in future. It could be a config option in config.php.
I have nothing to add to phplist3 at this time. I was just sharing a bit of plugin code that could help others trying to do what I’m trying to do. I still haven’t figured out how to stop the default parsing functionality from within a plugin, so I may have to edit the core of phplist3 to make it do what I want. (I’m trying to avoid that.) I’m currently distracted by some bugs in the code preventing me from sending test emails. (No errors, it just doesn’t run the child script’s construct method.) I maybe should be starting another thread about that if I need help with it, though.