Bringing this thread back because I just tried to change transactional messages, saw no effect, and came to search the forum, which brought me here.
Thanks to your post, I was able to see where to make the changes I wanted. (I didn’t make them, for reasons discussed below.) You are correct in your assumption, I eventually found this explained in the manual… in the discussion of setting up subscribe pages.
You are also correct that it is confusing. At the very least, those messages in Settings should be broken out into their own section entitled “Default Transactional Messages” to imply, right from the start, that the actual transactional messages are defined elsewhere but will start from these defaults.
That’s not the real problem or solution, though. Architecturally it’s wrong to associate transactional messages with the subscribe page. The correct association is with the list. The unsubscription message is the clearest example of why this is true. When someone unsubscribes from a list, that is exactly what they are doing – unsubscribing from the list, not from the subscribe page.
There is potentially a many-to-many relationship between subscribe pages and lists, and subscribers can be imported without the use of a subscribe page. The only way to ensure the desired unsubscription response message is sent when a subscriber unsubscribes is to take that many-to-many complexity out of the situation and define that transactional message (and others, naturally) with the list the person is signing off from.
Consider Farmer Pat who has the lists Apricots, Bananas, and Carrots (A, B, C) for people who like locally-grown fruit, people who like imported fruit, and people who like vegetables, respectively. On Pat’s site there is a phpList subscribe page (S - site) that offers A, B, and C. Pat also hosts a forum for fruit importers and has a subscribe page there (F - forum) that only collects subscribers for B. When Pat has a stand at the local market, there’s a paper sign-up sheet (M - market), and Pat manually adds those subscribers to all three lists.
This illustrates a many-to-many scenario. Subscription methods M and S offer A, B, and C. And, lists A, B, and C can be subscribed to via (M, S), (F, M, S), and (M, S), respectively.
Now assume that Pat self-publishes a book offering guidance on importing rare fruit, and wants to add a plug for that book in the unsubscribe message for list B. Pat wants to make sure that anyone who signs off from B will see that message. Where should Pat make those changes, since there are three ways somebody could be on that list? And what happens when Kim, who provided an email address on the paper sheet at the market, signs off from list B, i.e., what unsubscribe message is sent to Kim?
Transactions are inherently about lists, not the mechanism used to subscribe. I’m assuming this would be a non-trivial change in phpList, but it is an important one to make.
Actually, as I write this, I’m pondering other system design issues related to unsubscribing. Time to do some more experimenting, when what I really wanted to do was work on trying to retain some customers that I will otherwise probably lose. I expect a large (for me) group of people to unsubscribe this weekend, for reasons not germane to this thread. They are all imported, so like “Kim” in the above example. 