future direction
| Project: | phplist Integration Module |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Dear Paul,
First off, kudo's on how far this module has already come, but I would like to pick your brain on how you see the future direction.
I'm currently working on a (pretty much) full implementation of the backend of phplist, so our client never has to see a phplist page.
It's still in early stages and will probably be pretty specific to the client's needs, but I'm sure you will be able to pick up some of it's functionality.
One of my goals is to make it play nice with Drupal's multilingual abilities. I was thinking something along the lines of an option on the admin page to which attribute to map the languages and as what to map each language ("en" to "1", "nl" to "2", ...) so it can be adapted to pretty much every1's settings. And also sync this when syncing.
Now of course this would be rather useless if you couldn't queue up messages from within Drupal with conditionals for the language attribute, so I'm also planning to integrate the phplist create message form.
Also, I was thinking of using taxonomy terms for the subject, so they can easily be translated, numbered consistently over translations and you could tag nodes with the terms and map out a view with that term as argument, that way you can just set the message to [URL:http://www.example.com/view/4] where 4 would be the taxonomy term ID. That way you can put a link to the view with the tid as argument and keep an archive of the newsletter. Even better: you could add another argument for the date and keep an "upcoming" block on the archive page that doesn't update to the current date, but stays on the date of the time the newsletter was created.
But to make this all customizable to any1s needs and flexible to change to the phplist core, I think we need to move more towards an API with a UI on top. Moving as much as possible to theming functions, like the subject, body wrapper, ...
right now, all I've done is add an option for the attribute name of language and how to map each active language, it then maps it when synching and when subscribing anonymously, it will put the active language in the postdata, properly converted
so if you have phplist to take language in account when sending the confirmation mail, it will do so
| Attachment | Size |
|---|---|
| phplist.module.patch | 3.27 KB |
#1
hm, something went wrong with the indentation, I'll fix it tomorrow, rly need to get to bed
#2
Fixed indentation and converted all tabs into double spaces as per http://drupal.org/node/318
#3
added wrong one
#4
Started integrating the messages backend, preliminary version can be found at http://seutje.be/mine/phplistbackend.zip
Things will prolly split from this project now, as my setup is pretty specific, using taxonomy term to name the phplist message and then exposing a form where nodes can be tagged to be added to that message, then a view is constructed, taking that message's tid as an argument and only showing the tagges nodes.
#5
Hi seutje,
Your project sounds interestig, but wy beyond what I ever enisaged this module to be. My ethos has been to keep the coupling fairly loose between Drupal and PHPlist, although it would be nice to be able to send messages from Drupal too (à la Newsletters module).
I'm not clear on whether you are wanting to extend this existing module by adding functionality, or if you are starting something new from scratch, but if you want to roll up your development into this module I ma very happy to dicusss how we could do that.
I'm on holiday for a few days at the moment and won't have net access again until next week, so I'll look out for your replies when I get back.
Regards,
- Paul
#6
Don't worry, the integration of the backend (just messages for now, but maybe the majority of the backend in the future) is still very specific to my use-case at the moment
I'd first want to finish that before I turn it into a more generic solution. Reason I made the backend a separate module right now is because I can imagine that some people would like to keep the backend in phplist, but still be able to sync drupal users and stuff, so I figured, maybe it's best to keep it as a submodule to phplist
but: I would prefer the backend module to just be the UI that uses functions which are in the regular phplist module. Thinking of stuff like phplist_save_message($msg), which would work pretty much the same as node_save, pass a $msg->id and it'll assume ur editing one. Then of course, you would also need a phplist_load_message($id), so you could do the following easily:
<?php$msg = phplist_load_message(5);
$msg->status = 'submitted';
phplist_save_message($msg);
?>
and ur message would be queued
unfortunately, I think about 6/10 phplist installations is hacked beyond repair, so the functions should be as generic as possible. But that also makes me think to just integrate it all... like the way you currently handle anonymous users registering trough drupal is just (excuse my language) rubbish. If a language other than english is used or if the thank you message is changed, it simply pretends to break, when it really doesn't break, so there's definately room for improvement there, at least add an option to set the thank you message that's returned by phplist, and maybe even completely migrate the whole process of signup to drupal, up to the sending of the confirmation message
that would make it way easier to turn phplist into a mean, lean, multilingual machine :P
enjoy your vacation :)
#7
dev update:
- added 'add message' form
- added func to easily map (active) lists and associated messages
- using taxonomy as identifier for which nodes should be added to the message
- added dependency on date_popup (part of date_api) for the senddate
I don't think any1 will be able to use this version, as it is still way too specific for my use-case, but once I get it running properly and tested, I'll get working on a generic solution
Functions and workflow need some work so I can use 1 function for saving and editing
latest (11/05/09): http://seutje.be/mine/phplistbackend-6.x-1.x-dev.tar.gz
I'll attach it aswell
#8
getting a bit further in the development of this... but I was wondering if it wouldn't be more interesting to put my _message_load and _message_save functions in the base phplist module so the rest is just a ui on top
this is what I'm currently using to load up messages and their associated lists
<?php/**
* Returns an array of phplist messages as they are in the database, optionally filtered
*/
function phplistbackend_get_messages($msg = array()) {
// Grab the phplist prefix array
$prefix = _phplist_dbconn();
// Prefix will return false if the phplist settings were wrong
if ($prefix == FALSE) {
return FALSE;
}
// When the phplist settings are correct
else {
// Build the query
$query = "SELECT * FROM {%s}";
$placeholder = array ();
// get the phplist prefix and append messages to get the messages table
$placeholder[] = $prefix['prefix'].'message';
// if an array was passed
if (count($msg)) {
// append status filter to query
$query .= " WHERE";
$count = 0;
foreach ($msg as $key => $value) {
if ($count > 0) {
$query .= " AND";
}
if (!is_numeric($value)) {
$query .= " %s = '%s'";
}
else {
$query .= " %s = %d";
}
$placeholder[] = $key;
$placeholder[] = $value;
$count++;
}
// showing 20 results for filtered requests
// TODO: pager and maybe views-like exposed filters, perhaps use views for building this
$limit = 20;
}
else {
// if no status was passed, show only 10 results
$limit = 10;
}
// add order by modified date , showing last modified message on top
$query .= " ORDER BY modified DESC";
// use phplist database
db_set_active('phplist');
// run the query, keeping in mind we want to add a pager in the future
$results = pager_query($query, $limit, 0, NULL, $placeholder);
$messages = array();
while ($result = db_fetch_array($results)) {
// stuff results in messages array
$messages[] = $result;
}
// add the lists for each message
foreach ($messages as $id => $message) {
// check plain
foreach ($messages[$id] as $key => $value) {
$messages[$id][$key] = check_plain($value);
}
// building query
// get the name and id of the lists that belong to this message
$query = "SELECT list.name, list.id FROM {%s} as list, {%s} as lmsg WHERE lmsg.messageid = %d AND list.id = lmsg.listid";
$placeholder = array();
// populate placeholder with list table name
$placeholder[] = $prefix['prefix'].'list';
// populate placeholder with listmessage table name
$placeholder[] = $prefix['prefix'].'listmessage';
// populate placeholder with message id
$placeholder[] = $message['id'];
// execute query
$results = db_query($query, $placeholder);
while ($result = db_fetch_array($results)) {
// populate the message lists array with the results
$messages[$id]['lists'][$result['id']] = $result['name'];
}
}
// set active database back to default
db_set_active('default');
return $messages;
}
}
?>
this returns an numbered array of arrays with all values escaped, like this:
$messages = array(0 => array(
'id' => '22',
'subject' => 'foobar',
'fromfield' => 'Foobar <foo@bar.com>',
...
'lists' => array(
'22' => 'my awesome list',
),
),
1 => array(
...
),
)
I might throw in a module_invoke_all right before the return so we can use a hook_phplist_load_message or something so other modules can easily manipulate message on load
just keeping u posted :)
EDIT:
forgot to mention, to filter messages, simply pass in an array as parameter specifying anything (xcept lists for now), for instance:
<?phpphplistbackend_get_messages(array('id' => '27'));
?>
will get the message with id 27 (if found ofc)
or:
<?phpphplistbackend_get_messages(array('status' => 'draft'));
?>
will get all the messages marked as draft
or:
<?phpphplistbackend_get_messages(array('template' => '8'));
?>
will get all the messages that use template id 8
of course you can combine these:
<?php
phplistbackend_get_messages(array('status' => 'sent', 'owner' => '2'));
?>
will get all messages with status "sent" and owner "2"
#9
Seutje, thanks for keeping this development public. I'm keen to see a comparison between the present Phplist, what you're doing, and modules such as Simplenews. Drupal choices are overwhelming! :)
#10
actually, this a just an implementation of the phplist backend, since it depends on the phplist module, there's no comparing to be done :P
might even move some functions to the main phplist module, coz it has a better "position" to function as an API for other modules
simplenews on the other hand, is a totally independent module that doesn't require a 3rd party package and like the name suggests, is a lot less feature-rich in comparison to phplist
btw, currently finalizing the message handling for my specific use-case, then I'll form this into a generic module that can use regular messages, RSS feed lists and HTTP_Request style fetching based on a view of nodes tagged with taxonomy like I did
when I'm done with that, I might integrate the statistics reporting with a dependency on the graph module or something... we'll see :)