new development version, 2.11.5

7 July 2010

We are delighted to announce the release of a new development version of phpList.This version is not yet ready for general use, but is for the courageous amongst you to try out and play with.

Before we are able to consider this version stable, quite some testing will need to be done. For example, we haven't really tested upgrade to this version from the latest stable. If you want to help out, please play with it, and report your findings in mantis , marking the issue for version 2.11.5

This version has quite a large amount of changes. Below we are giving a summary of what has changed, but in fact loads more changes have been made. The most important change to keep in mind that phpList will no longer work with PHP4.

Main changes headlines

  • More capabilities for plugins to manipulate elements of the system
  • Removed RSS functionality in order to move it to a plugin
  • Admin Passwords encrypted
  • Removed attribute selection for outgoing mails, move to plugin
  • Add requeue option, to automatically add messages back in the queue
  • update to phpMailer 5.1
  • auto blacklist emails on too many bounces
  • click track handles large amounts
  • suspend messages and allow "mark as sent"
  • disallow deletion of messages that have gone out
  • send embedded images
  • HTML Footer
  • switching tabs in the "send a message" page will save it to the DB
  • List categorisation -> Organise lists in groups
  • Allow config for defaulting on send start and finish alerts
  • Automatically add Google tracking code to all links
  • Interface updates and improvements
  • Before sending a mailout, stats will be cleared
  • Download of statistics data
  • always append string to URL

Main changes details

The main focus of development currently is simplification. phpList is extremely powerful and able to do many things, but often it is not very clear how to make it do them and at the same time it is hard to use and understand by novice users. Some efforts have gone into simplifying the interface, although quite a lot of work still needs to be done on this. We welcome feedback and suggestions.

Part of the revamp of the interface has been to be a bit more clear about terminology, and to use more standard terms for certain things. For example, the terms "message" and "user" can be rather obscure, and terms like "campaign" and "subscriber" are more sensible in many places. However, not only will these changes need to propagate to the translations, even in the english version, this is not all consistent yet. 

For simplification of the code, we have worked towards a "plugin" system, which should become a more customised way to extend the capabilities of phpList. We have therefore removed certain functionality, with the plan to add it again at a later stage using plugins.

For now, the features that have been removed from phpList are the RSS fetching and sending, and the attribute selection on mailouts. We've made a good start in providing that functionality using plugins, but for now, the core application will not provide this any longer. If you use it, there's no choice but to stay with the latest stable version.

Some highlights and explanation

In many places in the code, calls to plugins have been added. We will continue work on this, particularly when we work towards building those plugins, and for now, this is still fairly experimental. Do not rely too much on the way it works now, as it may still change quite a bit.

You can now configure phpList to encrypt admin passwords. If you do this, the "forgot password" system will send a link which has a token that can be used once within 24 hours after the request to change the password. 

You can schedule a message to be "requeued" (as opposed to the already "repeated") which will cause the message to be placed back in the queue automatically. Using this, it will be quite straightforward to build your own way to have "auto responder" functionality in phpList, although a proper auto responder would also take some other details into account, like some date related to the subscriber.

Clicktracking has been heavily redone in order to handle large amounts of messages, links and subscribers. If you use clicktracking in version 2.10 you will probably have been struggling with a very large database that grew out of proportion. The 2.11 versions have completely changed the way this works, with great results. The direct clients of Tincan, who have been using this for several years now (2.11.3 came out in February 2007 already had this change). Some clients send in the range of 150.000 emails per week and all click tracking works without problems. When enabled, phpList will track every single link in the messages, except when the text for the link is a URL.

We have updated the phpMailer version included in phpList to the latest stable. But there is now a configuration that you can set to choose your own, which will be useful to use when you want to include the standard distribution of phpMailer, instead of the one included in phpList. Unfortunately, like before, we've had to make a few changes to phpMailer to make it work well with phpList. Particularly when you want to use embedded images in your emails, the standard phpMailer class did not allow us to do that. For the more technical amongst you, there's a diff file in the phpMailer directory, which shows the changes.

We've changed a few things in the way mailouts are managed. For example, once you've set it to go out, you cannot delete it any longer. If you were to delete it, it would break all kinds of things, particularly when click tracking is used. 

Also, when you create a mailout and change tabs from one to another, phpList will automatically save the contents you were editing. This should be a major improvement to usability, particularly for novice users.

A new system has been added to allow "list categories". This is particularly useful when you have large amounts of lists. You will need to setup your categories and go through a one-time process to categorise all your lists, but from then on, quite a few places will be much easier to handle.

The message footer can now also contain HTML code. In previous versions, the footer had to be plain text, because it is used in both the text and HTML version of the mailouts. Now, if you use HTML it will display fine in the HTML versions, and it will be converted to plain text automatically for the plain text version.

phpList will also automatically generate Google Campaign Tracking code, if you tell it to. You can set this in the configuration to be always done, or you can switch it on or off per campaign you send out. It will even work with click tracking. This is great for anyone who uses Google Analytics on their site, as it will provide more statistics on the effects of your mailings.

On many of the statistics pages, you can now download the statistics, so you can deal with it in a spreadsheet, and make nice graphs for presentations.

There is now a config to set a value to always append to a URL that is used when sending a newsletter generated on a remote site. Tincan Webbler clients should check the Webbler documentation for the correct value to enter here. This allows you to simply enter the web site URL you want to send, without the need to remember the additional parameters to add when sending. 

URL cache, when sending a webpage, will also be cleared when testing, and just before activating the mailout, so ensure the content is always the latest version of the page. 

How to upgrade

As always, we work towards making upgrade a smooth as possible. However, in this case we haven't tested it really thoroughly yet. But in principle the normal upgrade instructions should work. In practice, it might be useful to do a dry-run, before applying it to your live system.

In this case you will probably want to re-edit your config file. We haven't put everything in there yet, but a few things are different. So the instructions to keep your old one won't apply, just yet. 

phpList will detect as usual that you need to upgrade. So, choose the upgrade link. But once you've done that, make sure to run the "database structure check" to see that all is ok. If there are tables missing, the best thing to do is to load "initialise" and the missing tables will be created. If there are columns missing, you will need to add them by hand. If any of these things happen, please make sure to report it to mantis, so that we can make sure that upgrade works fine for everyone else. If you have no idea what I'm talking about, be sure not to do any of this, and wait with version 2.10 until these kinds of issues have been sorted out.

Once you managed to work your way through an upgrade, there's a way to convert the old click track statistics to the new structure. This will be quite helpful to reduce the size of your database, and to ensure that links clicked in mailouts that have gone out continue to work.

Once you have the new version running, it will be useful to go through a few configuration options. Create some "List Categories" and then load the page to categorise your lists, to improve the interface in many places.